Laufzeiten Sequentiell & Parallelisiert

[Jörg B]

rand_r() wirkt echt wunder.

von 14.4s nochmal auf 9.1s gekommen.

Das Bauen des Baumes ist jetzt eigentlich das aufwändigste. Vielleicht sollte man hier das SAH Plane Splitting mit einem normalen Medianverfahren mischen.

[Ronny]

Das Bauen des Baumes ist jetzt eigentlich das aufwändigste. Vielleicht sollte man hier das SAH Plane Splitting mit einem normalen Medianverfahren mischen.

Durch Mischung mit einem Medianverfahren verringert sich die Qualitaet der BVH. Das hat ein laengeres Raytraversal zur Folge.
Die BVH Konstruktion laesst sich aber auch gut parallelisieren.

[Thomas Huxhorn]

9sec? verrate mir doch bitte einer mal was das Geheimniss ist. Habt ihr schnellere Intersect Funktionen verwendet oder den Baum umgebaut oder was?

[Jörg B]

Eigentlich benutze ich nur das ganz normale Framework. Es werden am Anfang zwar noch alle Dreiecke gefiltert die garnicht in der Kamera liegen können, d.h. die Scene Bounding Box kleiner gesetzt. Aber das macht in der parallelen Version nur sehr wenig bis gar nichts aus wenn überhaupt. In der sequentiellen Version ist das aber ca. eine Minute Gewinn.

Ansonsten einfach nur schauen das man mit den Threads möglichst wenig im globalen und soviel wie möglich im privaten Speicher macht, sie immer was zu tuen haben (gleichmäßig aufteilen) und keiner alleine am Ende noch rum rechnet

[Thomas Huxhorn]

Ja, ist bei mir so. Bei htop werden alle 24Threads bei 100.0% angzeigt. Mit valgrind hab ich alle blockierenden Funktionen entfernt. Es muss im Prinzip einfach nur noch pur gerechnet werden.

[Ronny]

Es werden am Anfang zwar noch alle Dreiecke gefiltert die garnicht in der Kamera liegen können, d.h. die Scene Bounding Box kleiner gesetzt.

Wie meinen Sie das? Sie haben die Dreiecke komplett aus der Szene genommen?
Die sind aber fuer das AO-Sampling wichtig.

[Jörg B]

Natürlich wird die neue Box noch in alle Richtungen erweitert um die maximale Weite der AO-Sampling Strahlen =)