PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Neuer Realstorm Benchmark/Demo: Die Technologie

RLZ
2006-02-27, 17:44:55
http://realstorm.com/
Diesmal mit GlobIllum.
BlackBirdSR
2006-02-27, 18:38:24
Kann ich irren, aber der Pentium-4 scheint etwas aufgeholt zu haben in dieser Version.
Mal ein paar Fragen stellen ;)
Gast
2006-02-27, 20:31:24
warum wird denn die graka nicht benutzt, es hat ja schon mal eine raytracing-demo gegeben die die SM3-funktionen der graka benutzt hat.
RLZ
2006-02-27, 22:26:58
warum wird denn die graka nicht benutzt, es hat ja schon mal eine raytracing-demo gegeben die die SM3-funktionen der graka benutzt hat.
Es ist nicht sonderlich schnell für komplexe Szenen, da meistens ein einfaches Grid als BSP herhalten muss.

Realstorm hat zumindest mich mal wieder mit zu einfachen Szenen enttäuscht. Was nutzt mir Raytracing, wenn ich damit nur ein paar hundert Polygone rendere?
Die Performance finde ich im Vergleich auch etwas durchwachsen, wenn man sich die ganzen Hacks anschaut, die bei hohen Auflösungen unschöne Artefakte verursachen.
Für eine Hobbyprojekt haben sie aber mal wieder schöne Arbeit abgeliefert.
tombman
2006-02-28, 06:10:51
Ziemlicher Crap....

Seit dem letzten benchmark wurden sie bombardiert das ganze doch endlich multithreaded zu machen und haben es auch in diesem schon wieder ned geschafft. Ich habs überprüft, auch der 06er nutzt nur eine cpu :rolleyes:
Coda
2006-02-28, 12:05:38
Einen Raytracer multithread-fähig zu machen ist eigentlich ziemlich einfach - versteh ich auch nicht.
Raff
2006-02-28, 12:18:15
Ziemlich unspannendes Teil. Optisch fand ich den Vorgänger besser ... der lief zudem (deutlich) schneller.

Kann ich irren, aber der Pentium-4 scheint etwas aufgeholt zu haben in dieser Version.
Mal ein paar Fragen stellen ;)

Gleichermaßen scheinen die Mobiles etwas verloren zu haben. Ein Dothan ist nicht mehr schneller als ein gleichgetakteter A64.

MfG,
Raff
Coda
2006-02-28, 12:20:50
Vielleicht haben sie einen packet-tracer implementiert (also SSE-fähig), das würde den Vorteil vom Pentium 4 erklären.

Woa, der Texturfilter ist ja mal verdammt fies X-D
RLZ
2006-02-28, 13:00:03
Ziemlich unspannendes Teil. Optisch fand ich den Vorgänger besser ... der lief zudem (deutlich) schneller.
Die Geschwindigkeit wird wohl am GlobIllum liegen.
Irgendwo steht etwas von 35000 Lichtquellen für eine Szene.
Imo haben sie also für die Szene 35000 Lichtquellen vorberechnet und überprüfen dann den relevanten Teil davon(ich hoffe ja nicht alle).
Für komplexerer Szenen hätten sie wohl deutlich mehr Lichtquellen benötigt. Dazu gabs auch glaub ich mal ein Paper von Johannes in der Richtung.

Ich würde mal gerne die Hausszene gerne im Vergleich mit PRT sehen. X-D

Woa, der Texturfilter ist ja mal verdammt fies
Texturfilter kosten bei CPU-Rendering massiv Leistung.
Da versucht man natürlich daran zu sparen. :D
micki
2006-02-28, 14:54:16
Einen Raytracer multithread-fähig zu machen ist eigentlich ziemlich einfach - versteh ich auch nicht.
das kommt auf den tracer an. sobald mal einer was am tree modifiziert, ist es nicht mehr so leicht es Multithread zu machen.
Raff
2006-02-28, 14:59:40
Texturfilter kosten bei CPU-Rendering massiv Leistung.
Da versucht man natürlich daran zu sparen. :D

Der Swiftshader kann das aber schneller. :D

MfG,
Raff
Coda
2006-02-28, 16:13:10
das kommt auf den tracer an. sobald mal einer was am tree modifiziert, ist es nicht mehr so leicht es Multithread zu machen.Hm das ist wohl wahr, aber das eigentliche Tracing ist auf jedenfall parallelisierbar.

Ich hab aber auch nicht den Eindruck, dass da der Tree dynamisch verändert wird.

Der Swiftshader kann das aber schneller. :DRasterizer<-> Raytracer - Apfel<->Birne
micki
2006-02-28, 16:32:56
Hm das ist wohl wahr, aber das eigentliche Tracing ist auf jedenfall parallelisierbar.

Ich hab aber auch nicht den Eindruck, dass da der Tree dynamisch verändert wird.
das kann man von außen eigentlich garnicht beurteilen. manche implementierungen sortieren z.b. tris doppelt ein, aber um sie nicht doppelt gegen nen ray testen zu müssen, legen sie die rayid ab. schon ist die ganze parallelisierung im ar... (bzw sehr viel schwerer), hängt wie gesagt, von der laune des implementierers ab.
Coda
2006-02-28, 16:58:09
Hm? Das ist doch egal, ein Ray läuft ja stets nur auf einer CPU.
Raff
2006-02-28, 17:01:09
Rasterizer<-> Raytracer - Apfel<->Birne

Hrhr, schon klar. Seine Aussage klang aber so allgemein. ;)

MfG,
Raff
micki
2006-02-28, 19:53:53
Hm? Das ist doch egal, ein Ray läuft ja stets nur auf einer CPU.
wenn zwei rays auf zwei cpus laufen, zerschiessen sie sich den tree
RLZ
2006-02-28, 19:59:11
wenn zwei rays auf zwei cpus laufen, zerschiessen sie sich den tree
Wenn der Zugriff abgesichert ist, zerschiessen sie sich in dem Fall höchstens die Optimierung.
Neomi
2006-02-28, 20:36:47
wenn zwei rays auf zwei cpus laufen, zerschiessen sie sich den tree

Dann spiegelt man eben die dynamischen Teile des Baums oder im Extremfall sogar den ganzen Baum einmal pro Thread. Das sollte kein großes Thema sein.
Coda
2006-02-28, 21:13:45
Man kann sogar 32 Threads in einen int reinwürgen wenns nur ein Flag sein soll...
RLZ
2006-02-28, 21:49:05
Man kann sogar 32 Threads in einen int reinwürgen wenns nur ein Flag sein soll...
Es geht aber nicht um eine Flag, sondern um eine ID.
Ein Flag wäre ziemlich unpraktisch, da man es wieder löschen müsste.
Pro Ray die letzten DreiecksIDs zu speichern ist wesentlich einfacher und erfüllt auch seinen Zweck.
Wenn man mal eine Intersection zuviel macht, ists ja auch nicht so schlimm.
Ganze Unterbäume zu kopieren um ne Intersection zu sparen ist auch leicht übertrieben. ;)
Neomi
2006-02-28, 21:53:54
Man kann sogar 32 Threads in einen int reinwürgen wenns nur ein Flag sein soll...

Gehen tut das sicherlich, aber dann kommt wieder der Overhead für die Synchronisierung dazu. Wenn die Daten schon logisch für jeden Thread getrennt sind, dann sollten sie auch so abgelegt sein, daß sie sich auch ohne Abgleich nicht in die Quere kommen.
Coda
2006-02-28, 21:55:16
Sorry, brainfart. Ich bin grad nicht so auf meinem geistigen Level...
Neomi
2006-02-28, 22:00:59
Es geht aber nicht um eine Flag, sondern um eine ID.
Ein Flag wäre ziemlich unpraktisch, da man es wieder löschen müsste.
Pro Ray die letzten DreiecksIDs zu speichern ist wesentlich einfacher und erfüllt auch seinen Zweck.
Wenn man mal eine Intersection zuviel macht, ists ja auch nicht so schlimm.
Ganze Unterbäume zu kopieren um ne Intersection zu sparen ist auch leicht übertrieben. ;)

So einen Raytraycer würde ich dann in etwa so aufbauen...

1x Baum mit Dreieckindices, statisch (pro Frame)
1x Liste mit Geometrie, statisch (pro Frame)
pro Thread: lineare Liste mit letzter RayID pro Dreieck

Ein speicherschonenderer Ansatz wäre wohl, pro Ray die letzten x getesteten Dreiecke zu vermerken, aber dann müßte man darin wieder suchen. Wie immer spart man entweder Rechenzeit oder Speicherplatz, aber nicht beides.
RLZ
2006-02-28, 22:05:14
Ein speicherschonenderer Ansatz wäre wohl, pro Ray die letzten x getesteten Dreiecke zu vermerken, aber dann müßte man darin wieder suchen. Wie immer spart man entweder Rechenzeit oder Speicherplatz, aber nicht beides.
Wenn du die letzten 4/8 DreiecksIDs speicherst erwischt du fast 100% dieser Fälle, wenn der BSP entsprechend aufgebaut ist.
Dazu nimmt man 1/2 SSE Register und nutzt die als RingBuffer.
Speicherplatz und Rechenzeit gespart. :biggrin: