Bericht Raytracing in Spielen VI: So werden Strahlen von GPUs beschleunigt

Christoph Riedel schrieb:
Das Problem mit Grafikkarten ist allerdings, dass sie für die Rasterisierung darauf optimiert wurden, vielfach exakt die gleichen Instruktionen auf verschiedene Daten anzuwenden. In der Informatik spricht man von „Single-Instruction, Multiple-Data“ (SIMD). Beim Raytracing verhalten die Strahlen sich allerdings jeweils unterschiedlich, wenn sie auf spiegelnde, diffuse bzw. beschattete Oberflächen treffen, weswegen sich die Instruktionen pro Strahl unterscheiden. Das bedeutet, dass sich für unterschiedliche Strahlen mit hoher Wahrscheinlichkeit auch verschiedene Rechenwege ergeben.

Das Raytracing für SIMD nicht ganz einfach ist, liegt nicht an dem Weg der Strahlen oder Art der selbigen. Nach jeder "Kollision" packt man einfach einen neuen Raycasting-Task in die Queue und schon hat man dieses Problem nicht mehr. Es folgt also nicht eine SIMD-Unit dem Strahl bis zum "bitteren Ende" sondern nur bis zum ersten Hit. Das Problem liegt tiefer. BVHs oder Octrees sind unerlässlich um die Anzahl der Dreiecke für die Schnittberechnung zu reduzieren, die Traversierung solcher Datenstrukturen kommt aber leider nicht ohne Sprünge aus und Sprünge sind wenn sie nicht identisch sind sehr ungünstig für SIMD. Die Schnittberechnung selbst hingegen ist recht ideal für SIMD wenn die Datenstruktur gut partitioniert hat. Gegen solche Sprungproblem kann man die Strahlen aber auch clever clustern, das lässt das Problem, dass allen Codepfaden gefolgt werden muss, zwar nicht ganz verschwinden, aber kann es deutlich mindern.

Schlussendlich ist der große Vorteil der RT-Cores einfach, dass die Traversierung sowie der Zugriff auf die Datenstruktur(hier BVH) in Hardware gegossen und zusätzlich auch noch der für eine Hardware-Implementierung bestmögliche Ray-Triangle-Intersection-Algorithmus fest verdrahtet wurde (wie zum Beispiel "Fast, Minimum Storage Ray Triangle Intersection" von Möller und Trumbore).

*Die Sprünge beim Sortieren kann man auch vermeiden in dem man Sortiernetze nutzt (Bitonic Sort zum Beispiel) und Suchen kann man häufig durch Sortieren ersetzen. Solche Maßnahmen kommen aber immer mit leicht schlechterer Laufzeit, können sich aber trotzdem lohnen: n log n (Merge-Sort) vs n log n² (Bitonic Sort) kann sich bei der passenden Datenmenge und Kernanzahl durchaus rechnen, auch gegen parallele nicht sprungfreie Merge-Sort Varianten.
 
Ich bin mir nicht ganz sicher, wo deine Erläuterungen von meinen stark abweichen. Es klingt in der Summe sehr ähnlich. Eine Sortierung ist ja nichts anderes, als was die Beschleunigungsstruktur macht. Und die Aussage, dass SIMD zuviel unterschiedliche Instruktionen können müsste um sinnvoll ausgelastet zu werden, deckt sich doch mit deiner Formulierung, dass es zu Sprüngen kommt. Nicht umsonst sind die enstprechenden Rechenschritte nicht teil der Shader.
ix.tank schrieb:
Die Schnittberechnung selbst hingegen ist recht ideal für SIMD wenn die Datenstruktur gut partitioniert hat.
Aber sowohl Nvidia als auch AMD stellen dafür eigene Recheneinheiten bereit. Das klingt für mich nicht logisch.
 
Colindo schrieb:
Beim Raytracing verhalten die Strahlen sich allerdings jeweils unterschiedlich, wenn sie auf spiegelnde, diffuse bzw. beschattete Oberflächen treffen, weswegen sich die Instruktionen pro Strahl unterscheiden.

Diese Begründung (warum es nicht geeignet sein soll) stimmt halt nicht. Es liegt nicht an der Art der Oberfläche, der Art des Strahls oder dem Weg des Strahls. Sondern an der Traversierung der Datenstruktur. Du suggerierst, dass es direkt etwas mit der Topologie der Szene zutun hat, hat es aber nicht. Es liegt im Allgemeinen daran, dass man für jeden Strahl einen Baum durch gehen muss und dessen Verzweigungen sind das Problem.

Colindo schrieb:
Aber sowohl Nvidia als auch AMD stellen dafür eigene Recheneinheiten bereit. Das klingt für mich nicht logisch.

Warum denn nicht? Ich habe doch geschrieben, dass die Instruktionen in Hardware gegossen immer besser sind. Und gerade bei der Schnittberechnung ist es ja immer exakt das Gleiche. Eingabe Strahl[Vertex,Vektor], Dreieck[3x Vertex,Normale], Ausgabe Ja/Nein/Vertex/(Vektoren). Dazwischen immer exakt der gleiche Rechenweg. Das ist der Inbegriff einer SIMD-Operation, allerdings gibt es halt auch keinen Grund diese zu variieren (Also das Programm zu verändern), daher lohnt sich die Hardware-Einheit.
 
  • Gefällt mir
Reaktionen: KlaraElfer und .Sentinel.
Alles klar, so kann ich das nachvollziehen. Es geht dir im ersten Punkt also darum, wie ich die Argumentation formuliere. Denn jede Richtung, in die der Strahl fliegt, macht bereits einen Unterschied.
Ich wollte einfach eine besonders anschauliche Begründung haben, auch wenn das Problem grundlegender ist.

Deinen zweiten Punkt verstehe ich so, dass die Berechnung der Schnittstelle sehr gut in SIMD geht, aber eben nicht in einem klassischen Shader. Deswegen die neue Hardware. Auch da gebe ich dir Recht.
 
Colindo schrieb:
Deinen zweiten Punkt verstehe ich so, dass die Berechnung der Schnittstelle sehr gut in SIMD geht, aber eben nicht in einem klassischen Shader.
Es geht auch in einem klassischen Shader nicht wirklich "schlecht", aber spezialisierte Einheiten sind halt doch im Normalfall noch eine ganz andere Nummer ;)

LG
Zero
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: KlaraElfer, ix.tank und Colindo
Danke für den umfassenden Bericht. Ich würde mich freuen, erstens mehr Artikel diesen Typs zu lesen und zweitens, wenn diese länger auf der Startseite präsent wären und nicht so schnell durch kurzfristige News verdrängt würden
 
  • Gefällt mir
Reaktionen: KlaraElfer und Colindo
Freut mich, dass er dir gefallen hat. Der Artikel war immerhin 24h auf der Startseite (durch den ruhigen Ostermontag), das ist schon recht viel. Ansonsten kann man da nicht viel machen, außer regelmäßig auf CB zu schauen ;)

Eine Sache, die CB macht, ist den Artikel bei relevanten News zu verlinken, so bleibt er im Fokus.

mehr Artikel diesen Typs zu lesen
Wenn du ein Thema hast, über das du gerne die wissenschaftlichen Hintergründe wissen würdest, immer her damit. Momentan habe ich noch kein neues Thema für einen nächsten Artikel.
 
An dieser Stelle möchte auch ich mich für diesen unglaublich interessanten Artikel bedanken! :) Ich habe ihn direkt nach seiner Veröffentlichung vor ein paar Tagen verschlungen und wollte eigentlich direkt drauf antworten, hatte da aber zu wenig Zeit, um eine Antwort zu formulieren, die dem Artikel gerecht wird :D

Es ist wirklich unglaublich, wie sehr ihr hier ins (technische) Detail geht, und wie diese "Technologie" funktioniert. Insbesondere die Unterschiede zwischen AMD und Nvidia finde ich extrem interessant und bin vor allem schon gespannt, ob AMDs Ansatz mit dem von Nvidia mithalten kann!

Ich denke, RT wird in dieser Dekade nie sein ganzes Potential entfalten können, da es nun ja erstmal darum geht, gute Hybride für Rasterization und RT zu schaffen. Wahrscheinlich stecken wir jetzt daher erst einmal in der Experimentierphase, bei der die optimale Architektur gefunden werden muss, die beides kann, und die somit auch weiterhin relativ komplex aufgebaut ist. Auch muss softwareseitig natürlich erst einmal geschaut werden, welche Verfahren denn auf Dauer die besten sind, damit in Zukunft nicht jeder Hersteller sein eigenes Süppchen kocht.

Da RT aber in Zukunft immer größere Stellenwerte einnehmen wird, könnte ich mir vorstellen, dass zumindest einzelne (dedizierte) "Cores" in Zukunft weitaus einfacher aufgebaut sein werden, damit umso mehr davon auf einen Chip passen. So würde zwar ggf. die "klassische" Leistung (für Rasterization) etwas sinken (zumindest im Verhältnis zur Anzahl der Transistoren), dafür aber die RT-Leistung deutlich ansteigen. Aber das ist alles nur Theorie. Letztendlich ist es bei RTX ja schon jetzt so, dass der Flächenbedarf gegenüber GTX überproportional angestiegen ist, was die Leistung bei Rasterization betrifft. Ich bin sehr gespannt, wie es weitergeht!

Colindo schrieb:
Wenn du ein Thema hast, über das du gerne die wissenschaftlichen Hintergründe wissen würdest, immer her damit. Momentan habe ich noch kein neues Thema für einen nächsten Artikel.
Da fällt mir doch direkt was ein, worauf ich euch sowieso noch hinweisen wollte :)
Momentan ist durch die Corona-Krise ja Folding@Home in aller Munde, ihr habt ja auch schon mehrfach über die kürzlichen Erfolge berichtet. Gestern gab es einen weiteren, und zwar ist die Leistung nun auf über 2,5 ExaFLOPs angestiegen, wodurch das Netzwerk jetzt schneller ist als alle Top-500-Supercomputer zusammen!

Falls ihr noch ein "Großprojekt" für einen Artikel sucht, wäre mal ein Artikel interessant, was genau bei Folding@Home überhaupt passiert, also was für Eiweiße dort berechnet werden, wie solche Algorithmen aussehen, was überhaupt die "Faltung" von Eiweißen ist, warum es so viel Rechenleistung erfordert, usw.

Mir ist natürlich bewusst, dass man da schon enorme Fachkenntnisse benötigt und ein solcher Artikel unfassbar viel Zeit kostet, aber vielleicht hat ja einer von euch selbst Spaß daran, da mal etwas nachzuforschen. Ich persönlich fände es unfassbar interessant, da man ja kaum eine Größenvorstellung davon hat, wie komplex so etwas eigentlich ist!
 
  • Gefällt mir
Reaktionen: pietcux
Hallo @SashaHa,
freut mich, dass dir der Artikel so gefallen hat. Ich habe bei der Erstellung keine Kosten und Mühen gescheut (war alles frei verfügbar :D), damit ich so in die Tiefe gehen konnte. Die Idee bei meinen Artikeln ist ja, die Details so wissenschaftlich wie möglich zu betrachten, aber so einfach wie möglich zu erklären. Finde ich daher echt schön, dass es bei dir so angekommen ist :)

Was die Hardware, die dieses Jahr vorgestellt wird, angeht, bin ich auch extrem gespannt. Am hybriden Ansatz lässt sich sicher viel optimieren, und wer wieviel RT-Leistung bereitstellt und sie wie nutzt, wird sehr interessant.

Folding@Home ist ein tolles Thema, danke dafür. Ich habe eben mal geschaut: die meisten Übersichts-Paper sind von 2010-2012, seitdem ist der wissenschaftliche Teil des Themas wohl durch, aber angesichts der Aktualität des Themas kann man da sicher etwas draus machen. Für mich notwendig ist lediglich, dass ich ein Paper finde, das wirklich viel zu dem Thema enthält, also typischerweise ein Review-Artikel. Eine echte Literaturrecherche wäre zuviel. Aber abgesehen vom Alter der Artikel spricht erstmal nichts dagegen!
 
  • Gefällt mir
Reaktionen: SaschaHa
Wenn man für jede TMU dann eine RT-Einheit bei den RDNA2-Karten einbaut (Platz brauchts ja nicht so viel), dann hätte man 50-60 Gigarays bei kopotierten 80 CUs (also 320TMU und 320 RT-Einheiten)... dann wäre der PS5-SoC (mit 144 TMU/RT-Einheiten ~25GRays) schon mehr als doppelt so leistungsfähig wie eine 2080Ti. Ich denke, in solchen Größenordnungen muss man auch denken. Turing ist nur ein Erstlingswerk einer Technologie, brauchbar war das noch nie wirklich.
 
@HOT wie kommst du auf die Zahl 144? Die Playstation 5 hat 36 Compute-Units, also auch 36 Textur-Einheiten. Entweder habe ich gerade beim Nachschauen einen Zahlendreher drin, oder du nimmst den Faktor 4 falsch.

Edit: Ah, auf dem Bild werden jeweils vier Einheiten dargestellt. So gesehen könntest du Recht haben.
1587216823071.png
 
Ich denke Turing wurde vorgezogen, weil man dem Thema den Stepel RTX aufdrücken wollte, bevor AMD die Konsolen und Big Navi bringen konnte. Das ist auch der Grund warum weder die ersten Raytracing Implementierungen noch DLSS fertig waren. Also es war notwendig um als Technologieführer dazustehen und nicht durch die neuen Konsolen aufs Abstellgleis zu geraten. Es bleibt spannend.
 
Colindo schrieb:
@pietcux Da waren sie aber hektisch, wenn sie de facto noch zwei Jahre Zeit hatten. Wer weiß, jedenfalls gilt Nvidia jetzt als Vorreiter in Sachen Raytracing.
Sie gelten auch als Vorreiter für G-/Free-Sync, SLI, PhysX, CUDA, DLSS, 3D Vision, HairWorks, etc. Manche der Technologien gab's auch schon vorher in ähnlicher Form und andere wurden aufgekauft: Eine Art Variable Refresh Rate gab's schon vor vielen Jahren in Notebooks - damals aber um Akku zu sparen. SLI kam von 3dfx, wurde aber erst unter Nvidia wirklich massentauglich. PhysX wurde auch gekauft, und auch das hat erst durch Nvidia seine große Verbreitung gefunden. CUDA gab's 2 Jahre vor OpenCL. 3D Vision und HairWorks sind inzwischen wohl tot? Oder zumindest habe ich seit vielen Jahren nichts mehr davon gehört.
Schade, dass es noch keine Open Source Bemühungen zu DLSS gibt. Vor allem DLSS 2.0 scheint extrem großes Potenzial zu haben. Aber solang AMD keine Hardware Beschleunigung für Neuronale Netze anbietet, wird das wohl noch dauern.

Nvidia ist doch dafür bekannt, dass sie mit neuen proprietären Sachen auf den Markt preschen. Und dann 1-2 Jahre später zieht der Rest nach - in diesem Fall waren das Microsoft mit DXR und demnächst dann AMD mit ihrer eigenen RayTracing Hardware Beschleunigung.
Nvidia hat halt die Marktmacht und die finanziellen Mittel um sich das zu erlauben. Und vor allem müssen sie dabei nicht in einem Konsortium mit 10 Parteien sitzen, wo es allein erst mal ein halbes Jahr dauert bis sich alle auf einen Namen für die neue Technologie geeinigt haben.
Nvidia kann sowas einfach auf den Markt bringen und schaut dann wie's läuft. Aber das ist natürlich auch von Vorteil für alle anderen Beteiligten: Wenn's wirklich innovativ ist und von den Konsumenten gut angenommen wird, muss man es einfach nur noch "kopieren". Eigentlich eine Win-Win-Situation für alle: Nvidia kriegt seinen Fame und weil's keine Alternativen gibt, können sie jeden Preis verlangen den sie wollen. Und die anderen sparen sich die Zeit und Kosten für Entwicklung eines Features, das womöglich überhaupt nicht vom Markt angenommen wird.
 
  • Gefällt mir
Reaktionen: pietcux
Artikel-Update: Der Artikel wurde um die seit seiner Erstveröffentlichung im April 2020 neu hinzugekommenen Erkenntnisse zu Hardware-Raytracing bei AMD und Intel, aber auch bei den Next-Gen-Konsolen und neuen Architekturen bei Nvidia ergänzt. Damals noch aktuelle, inzwischen aber überholte Textpassagen wurden angepasst.
 
  • Gefällt mir
Reaktionen: Quidproquo77, Goatman, xexex und 15 andere
Danke für das Update. RT kam schneller, als die 10GHz Pentium 6 :D
 
  • Gefällt mir
Reaktionen: DriveByFM, PietVanOwl, Jan und eine weitere Person
Danke! Bin vorbereitet 🤪 aber es muss auch gut implementiert sein nur dann ist es ein Mehrwert.
 
  • Gefällt mir
Reaktionen: fox40phil und Colindo
Schöner Artikel, sehr informativ und auch so geschrieben dass man kein RT Professor sein muss um was zu verstehen. :D
MFG Piet
 
  • Gefällt mir
Reaktionen: autopilot und Colindo
Raytracing ist hammer. Wer Raytracing für als nicht wichtig erachtet, sollte seine Augen putzen :D
 
  • Gefällt mir
Reaktionen: shy-Denise, KlaasKersting und thuering
Zurück
Oben