ix.tank
Lieutenant
- Registriert
- Sep. 2010
- Beiträge
- 908
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.