Berechnungen in der GPU -> Realtime Raytracing
-
Hallo!
Wie kann ich Berechnungen in der GPU, statt in der CPU, ausführen?
Dadurch sollte Raytracing echtzeitfähig sein, da eine moderne GPU 100x mehr Leistung als der Saarcor Prototyp hat.
Mfg,
Alex
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Gast996611 schrieb:
Dadurch sollte Raytracing echtzeitfähig sein, da eine moderne GPU 100x mehr Leistung als der Saarcor Prototyp hat.
Nein. SaarCOR implementiert das Raytracing in Hardware. Da kommst du mit ner normalen GPU nicht ran. Wenn du sagst, dass eine moderne GPU die 100 fache Leistung hat, dann hat sie diese vielleicht in einem anderen Bereich, aber sicherlich nicht im Bereich des Raytracings.
-
ein guter raytracing-algorithm auf der cpu ist sehr viel schneller als das raytracing auf der gpu, das meißt mittels bruteforce durchläuft.
rapso->greets();
-
Auf der Saarcor Seite selbst steht, dass wenn entsprechende Software zur Verfügung stünde hätte man mit einer aktuellen GPU die 100 fache Leistung deren Chips hätte.
Warum sollte es auf einer CPU schneller als auf einer GPU laufen?
-
weil eine gpu keine logik verarbeiten kann (jedenfalls nicht ohne eine menge overhead), nur arithmetische operation.
wenn du also z.b. x-kugeln hast die getraced werden sollen, dann wird auf der gpu kugel für kugel für jeden pixel durchgegangen und es wird getestet welche von denen zu sehen ist.
mit der cpu testet man rekursiv in einem tree welche kugel zu sehen ist, gegenüber einem bruteforce algorithmus findest du zig mal schneller raus welche diejenige ist. zudem traced man auf der cpu nur 1 von 16 oder 64 pixeln und nur falls sich die nebeneinanderliegenden 'traces' im resultat unterscheiden, traced man dazwischen. ansonsten weiß man welche kugel dazwischen immer die zu sehende ist und interpoliert nur die werte (also nochmals durchaus 64fache performance), das ist auf der gpu nicht möglich.
Auf der Saarcor Seite selbst steht, dass wenn entsprechende Software zur Verfügung stünde hätte man mit einer aktuellen GPU die 100 fache Leistung deren Chips hätte.
das kann man auch leicht anders sagen, wenn man entsprechende cpus hätte, würde das mit heutiger software die 100fache leistung bringen.
das problem ist leider dass die gpus nicht so flexibel sind wie die cpus. deswegen können die auch so fix sein. dort laufen alleine auf dem pixelshader leicht 128 prozesse gleichzeitig ab. weil sie völlig unabhängig voneinander sind. da muss keine instruction auf das resultat von der vorherigen instruction warten um abhängig von einem jump abzulaufen (falls man doch mittels PS3.0 einen jump hat, kostet das bis zu 5 takte, also nur noch 20fache performance).
das ist halt so wie mit assembler und basic. ein guter quicksort in basic schlägt bei gewisser länge des zu sortierenden arrays jede bubblesort-assembler-routine.
rapso->greets();
-
Verdammt. Danke trotzdem.
Kann man nicht zb. Pro Pixelzeile einen Thread machen und die werden dann parallel berechnet (Dual Opteron)? Welche Auflösung könnte ich mit einem Dual Opteron 246 (2.0Ghz) flüssig hinbekommen?
-
Das hängt von der Komplexität der Szene ab. Aber die Auflösung wird bei einem Raytracer wohl noch die kleinste Performancebremse sein. Jedenfalls hab ich gehört das einige simple Szenen mit einfachen Geometrischen Objekten auf leistungsstarken Home-PCs animiert lauffähig sind bzw sein sollen.
Weiß nicht ob ich das glauben soll, denn ich hab auch mal versucht einige elementare Raytracing Algorithmen für Schatten zu implementieren, und das Lief nur flüssig als die Gesamtzahl an darzustellenden Pixeln 1/6 der Auflösung waren.
-
Hier ist mal ein Beispiel für realtime-raytracing:
-
Ich hab mich vielleicht falsch ausgedrückt. Ich möchte Realtime Raytracing ohne den Saarcor Chip, auf normalen Rechnern.
Da ich gerade ohnehin an einer Engine, oder besser einem Development Kit, welches verschiedene Engines beeinhaltet (Grafik, Physik, Audio, ...), werde ich einen Modus einbauen, mit dem Szenen mittels Raytracing gerendert werden, und das Ganze auf seine Realtimefähigkeit auf halbwegs "normalen" Rechnern (Dual Opteron 246) testen.
Ich weis ein Dual Opteron ist keineswegs ein "normaler" Rechner, aber immerhin normaler als ein 48fach Cluster.Mfg,
Alex
-
http://www.realstorm.com/
da gibt's nen realtime raytracer für die cpu.wenn du wissen möchtest wie schnell sowas auf der cpu ist, mußt du selber rechnen :), das hängt dann aber noch von weiteren optimierungen ab. in bezug auf meinen raytracer braucht man bei 30k triangles und 256*256 rays ca 6sekunden pro bild.
eine doom3 level wird aber wohl sehr viel fixer zu tracen sein, aber da arbeite ich noch dran und kann keine zahlen nennen *hehe*
rapso->greets();
-
Danke für den Link, seh ihn mir gleich an.
Da ich noch nicht so viel mit Game Rendering gearbeitet hab, kann ich nicht beurteilen wie viel 30k Triangles sind. Aber ich schätze das Reicht für eine Ansicht, oder?
Sind deine Schätzungen (oder Benchmarkergebnisse) auf 1 Thread bezogen, oder kann man noch ein bisschen Leistung rausholen, indem man zb. pro Bildschirm Zeile einen Thread macht? Auf welche CPU Leistung beziehst du dich?
Warum ist ein Doom3 Level schneller zu berechnen??? Oder wird die einmalige Grafik (Die Grafik ist ein Wahnsinn und die Zombies, und ...!) nur durch Tricks und nicht durch Poly's erreicht?
Danke für eure Postings!
Mfg,
Alex
-
Ich hab gerade auf der Seite gelesen, dass man für's Echtzeitrendern einer Szene mit 512*384 einen Athlon 1300 Mhz braucht. Dann müsste man doch mit einem Athlon64 oder einem aktuellen P4 doch auf 1024x768 flüssig spielen können, oder?
Und: In dem Benchmark kann man Bilineares Filtering, Schatten, ... An und aus schalten. Aber: Wozu brauche ich Filtering bei Raytracing? Das ist doch nur für die Tiefenschärfe zuständig. Und Schatten, das ist doch kein Feature in dem Sinn, sondern eine "Folge" vom Raytracing. Und Radiocity, die Beleuchtung. Das ist doch auch etwas, was sich aus der Technik ergibt und nicht extra programmiert werden muss. Oder hab ich Raytracing komplett missverstanden?
-
ich hab bisher nur auf einem p4 mit 2ghz gebencht (auf nem athlonXP 1700+ dauert es ca 8sek)
eine ganze multiplayer level von doom3 hat manchmal weniger als die 30k polys, pro raum sind es dementsprechend wenig polys. Beim tracen würde ich natürlich erst nur den einen raum tracen und falls dort mal ein pixel nicht getraced werden konnte, erst dann die nachbarräume tracen. das ist dann unglaublich fix!doom3 schaut so gut aus, weil es sehr lowpoly ist dafür aber viele detailinformationen in normalmaps abgespeichert hat. das performanceproblem dass doom3 hat besteht durch den massigen overdraw der gebraucht wird um die schatten zu 'errechnen'. das kann mit raytracen vielleicht sehr viel effizienter rausgefunden werden.
das raytracen bei mir kann auf beliebig viele threads aufgeteilt werden. wobei das wichtigste ist, dass die cpus auf denen das läuft 1MB cache mindestens haben um die ganzen 30k polys mit scenengraphen dort zu halten. denn wenn man aufs ram warten müßte wegen zu kleinem cache (z.b. auf einem celeron), dann kann man die sache gleich vergessen.
Beim aufteilen der threads wird dabei quadweise z.b. 8x8 pixel, aufgeteilt (wobei ich mir nun erstmal wieder ein MP system besorgen muss, meine altes dual P3 kann ich da wirklich nicht für performance nutzen *Hehe*... ein dual p4 mit HT wird wohl 4 threads und geschätzt 210% der performance eines single p4 bringen.)rapso->greets();
-
Ich könnte deinen Raytracer nächste oder in 3 Wochen (übernächste Woche bin ich auf LAN Party)auf einem Dual Opteron (jeweils 2Ghz) mit Linux drauf testen, wenn du willst.
Noch eine Frage hätte ich: Die benötigte Leistung des Raytracings steigt doch mit den Polygonen, oder? Nun kann ich doch eine Szene mit einem Cube auf 320x200 rendern und die gleiche auf 1600x1200. Auf 1600x1200 muss ich ja mehr Strahlen verfolgen -> verbraucht mehr Leistung als 320x200. Oder irre ich mich da?
Wenn die geilheit der Doom3 Level nur auf diesem "Trick" mit den Normal Maps basiert und da nicht wirklich Polygonen sind, dann muss das Level doch ziemlich hässlich sein, wenns getraced ist, oder?
Achja, wenn jetzt ein Lichtstrahl vom Betrachter weggeht und auf einer Wand auftrifft, woher weis ich jetzt wohin der gebrochen wird? Dann müsst ich ja für jeden Pixel viele Strahlen jeweils in verschiedenen Winkeln aussenden.
Kennst du ein gutes (vielleicht sogar deutsches) Tutorial für das Programmieren einer Raytracing Engine?PS. Hab mir grad deine Seite angesehen und deine Engine: RESPEKT!
-
klingt scho sehr verlockend das opteron system :), hab es gerade noch ein klein wenig optimiert und auf meinem athlonXP(1.466GHz) getestet (dort schein SSE, im gegensatz zum p4, wirklich performance zu bringen) und es läuft in 4.1 sek durch. optimistisch gesehen könnte es auf dem dual Amd vielleicht in 1sek durchlaufen. :D... ich müßte es dann aber erstma portieren.
bei 1600*1200 würde es gegenüber 320*200 etwa 30 mal langsammer laufen, wenn man also bei 320*200 flüssig spielen könnte, würde es bei 1600*1200 zur diashow. wobei aufgrund der speichermenge noch der cache zerschossen werden könnte und sich das noch schlechter auf die performance auswirken könnte.
rapso->greets();
-
Kein Wunder, dass SSE auf Athlons schneller läuft, sie haben mehr SSE Piplines als Intel's.
Aber eins versteh ich immer noch nicht: Wenn ich jetzt einen Strahl pro Pixel gerade aus von der Kamera lossende und er auf eine Mauer, parallel zur Kamera schicke, dann weis ich ja nicht wohin er reflektiert werden soll.
Kennst du vielleicht ein gutes, deutsches? Tutorial zum Raytracing?
-
-
Danke für den Link, werde ihn mir mal zu Gemüte ziehen.