Skrivet av Galadhnen:
Vi skulle, troligen hyfsat tryggt, kunna anta att RT-kärnor gör arbetet mer effektivt (operationer per Giga Ray) än om man hade exakt samma beräkningskraft tillgänglig via en massa SM utan RT-kärnor, men med tanke på att t.ex. begrepp som "CUDA cores" används kanske mer för marknadsföring än något annat (Gamers Nexus ft. David Kanter) så tänker jag inte helt och hållet nöja mig med det. Jag vill ha konkret, teknisk fakta.
Så när Nvidia säger att Pascal spenderar 10 TFLOPS per Giga Ray, men sen inte nämner något om hur faktiskt effektivt deras nya RT-kärnor hanterar samma operationer... då undrar jag om de undanhåller information av en anledning. För de jämför äpplen och päron när de säger "Pascal: 10 TFLOPS = 1 Giga Ray" ||| "Turing: 68 RT cores = 10 Giga Rays".
Har någon här en källa som har någon teknisk information om hur RT-cores gör BVH-sökningen mer effektivt, gärna beskrivet i operationer per Giga Ray eller beräkningskraft per RT-core.
Enda Nvidia egentligen säger här är att om man kör BVH-beräkningarna på CUDA-kärnor skulle det behövas ~10 TFLOPS (och för att vara exakt, 10 TFLOPS på Pascal, det blir en mindre siffra på Turing då CUDA-kärnorna där är bättre på att hantera "generella" beräkningar).
På hög nivå händer detta vid BVH-beräkning: man skickar en stråle från öga/kamera genom varje pixel på skärmen. För varje sådan stråle behöver man sedan hitta vad den först kolliderar med. Så här långt fungerar det riktigt bra på CUDA-kärnor!
Sedan börjar problemen. Beroende på om strålen inte träffar något, träffar en yta som är blank/ej blank, slät/skrovlig samt genomskinlig/ej genomskinlig händer lite olika saker.
CUDA-kärnor har 32 st "kärnor" som delar på samma exekveringstillstånd, SIMD (Nvidia föredrar att kalla det SIMT för single instruction multiple threads). En sådan design är väldigt effektiv så länge som alla trådar på dessa kärnor till största del kör samma väga genom programmet, något som ofta är fallet för rastrering.
CUDA-kärnor kan hantera fall som ser ut så här
if (predicate) {
do_a();
} else {
do_b();
}
Men då 32 st kärnor delar exekveringstillstånd och några evaluerar predicate till sant medan andra evaluerar det till falsk implementerar man det så att både do_a() och do_b() körs och dessa måste köras i sekvens (de kan inte köras parallellt då det bara finns ett exekveringstillstånd).
När man kör do_a() blir koden i praktiken en trave "gör ingenting" instruktioner för alla trådar där predicate evaluerades till falskt.
Ray tracing är i grunden en rekursiv algoritm, så en splitt mellan do_a()/do_b() betyder att trådarna som tar olika vägar i praktiken konvergerar först när hela beräkningen är klar.
Så 10 TFLOPS är teoretisk kapacitet som krävs i Pascal CUDA-kärnor behöver, men är långt mindre som används då en stor andel av CUDA-kärnorna kommer köra "gör inget" så fort man passerat en punkt där strålarna divergerat. T.ex. en stråla träffar en blank yta som genererar en reflektionsstråle medan en annan träffar en skrovlig yta som måste skicka ut flera reflektionsstrålar i olika riktningar.
"Magin" hos RT-kärnorna är att de har ett exekveringstillstånd per kärna, de implementerar MIMD ungefär som en multi-core CPU. För att hålla antalet transistorer på en vettig nivå gör RT-kärnorna bara en väldigt specifik uppgift.
Så hade man bara kunna fläskat på med fler CUDA-kärnor? Absolut, men för just BVH-beräkningar hade det tagit långt fler transistorer och ström än att stoppa in ett gäng RT-kärnor. Problemet med RT-kärnorna är att hitta rätt balans mellan dessa och CUDA-kärnor, samt att RT-kärnorna inte har speciellt stor användning utanför BVH-beräkningar.
Fast att mängden s.k. "dark silicon" ökar är ingen nyhet, det är faktiskt ett krav för att kunna göra något vettigt med allt mindre transistorer då Dennard scaling inte längre finns. Utan viss mängd "dark silicon" skulle effekten på riktigt täta kretsar bli totalt ohållbar idag, tricket är att stoppa in "rätt" mix av funktioner så en lagom mängd kisel är aktivt vid varje relevant arbetslast.