Ray tracing – djupdykning i tekniken och betydelsen för framtidens spel

Trädvy Permalänk
Medlem
Registrerad
Apr 2006
Skrivet av sKRUVARN:

Personligen hade jag faktiskt nog velat se först och främst lite indiespel, eller rättare sagt enklare spel där man kan använda sig av tekniken för att förhöja spelmekaniker. Alltså spel mer i stil med kanske portal eller andra pusselspel där man kan bygga en upplevelse med hjälp av reflektioner och ljus som idag är omöjligt med nuvarande teknik. Känns betydligt mer spännande än lite snyggare reflektioner imo.

Fast det är ju det som kommer hända. Först ut nu kommer ju UE med stöd för raytraing, och förhoppnings Unity strax efter, och då kommer ju indie-utvecklarna hoppa på det. Indieutvecklarna är ju de enda idag som vågar prova på nya saker då de stora drakarna endast är intresserade av positiva kvartalsrapporter och inte ny teknik eller spelglädje, så vi kommer nog se många intressanta koncept och idéer kring hur man kan använda raytracying i spel, både för att förhöja den grafiska kvaliteten men även där raytracingen i sig blir en del av spelmekaniken. Blir klart spännande!

Trädvy Permalänk
Medlem
Registrerad
Dec 2001

Tack för en trevlig artikel, och inte minst för en väldigt intressant diskussion här!
@Yoshman, en liten liten detalj, men saknar inte den här uträkningen en * fps, med tanke på S:et i TFLOPS?

2 miljoner strålar * 1000 flyttalsoperationer per stråle = 2 miljarder = 2 TFLOPS

Och borde inte 2 miljarder operationer per sekund bli 2 GFLOPS, eller 0,002 TFLOPS..? Eller har jag druckit för lite kaffe bara?

Trust me, I'm an engineer!

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av jaqob:

Tack för en trevlig artikel, och inte minst för en väldigt intressant diskussion här!
@Yoshman, en liten liten detalj, men saknar inte den här uträkningen en * fps, med tanke på S:et i TFLOPS?

2 miljoner strålar * 1000 flyttalsoperationer per stråle = 2 miljarder = 2 TFLOPS

Och borde inte 2 miljarder operationer per sekund bli 2 GFLOPS, eller 0,002 TFLOPS..? Eller har jag druckit för lite kaffe bara?

Det låter helt korrekt, ska korrigeras. Reagerade inte på siffran då 2 TFLOPS ändå kändes rimlig, är att 1000 FLOPS per stråle är absolut best-case som nog ställer till den delen, blir klart mer i "verkligheten". Får köra strut <:)

Huvudpoängen jag var ute efter var att sett till rå kapacitet borde dagens GPUer utan problem fixa ray tracing, men det fallerar på att dagens GPUer är optimerade för en annan typ av parallellism och de är inte i närheten lika effektiva på det som behövs för ray tracing.

Men som man kan se i Blender blir de allt bättre på mer generella fall, det gäller aktuella GPUer från alla tillverkare! Turing är ju rejält mycket snabbare än Pascal med samma teoretiska flyttalskapacitet.

Edit: hittade missen här. Tyckte ändå jag hade referenser som nämnde låga TFLOPS vilket gjorde att 2 TFLOPS "känndes" rätt
Missen är att jag räknade bara på en enda scen, ska ju multipliceras med FPS!

Då exakta siffror kanske förvirrar mer än hjälper här då det inte är siffran som sådan som är viktig utan nivån, d.v.s. är det hundratals miljoner, långa miljarder eller tiotals miljarder, gjorde jag det hela ännu mer "handviftande".

Siffran man får fram ska ju ställas mot AMDs/Nvidias toppkort som har >10 TFLOPS.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Dec 2016

Bra artikel, mycket nytt för mig om bitarna av ray tracing jag är dåligt påläst på. Mitt favoritområde är just maskininlärning och det skippade du nästan helt.

Jag har dock förstått det lite annorlunda och undrar nu om jag haft fel. Som jag förstått det är tensor core kärnorna gjorde för att hantera vektor multiplikationen som är resultatet av neuronätets vikter. Och som jag förstod det behövdes dessa eftersom enbart en liten andel av strålarna räknas fram och resten är sedan neuronätet som förstår var resten ska placeras, och man tar då genvägen och helt enkelt placerar strålarna så som neuronätet säger

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av necris:

Bra artikel, mycket nytt för mig om bitarna av ray tracing jag är dåligt påläst på. Mitt favoritområde är just maskininlärning och det skippade du nästan helt.

Jag har dock förstått det lite annorlunda och undrar nu om jag haft fel. Som jag förstått det är tensor core kärnorna gjorde för att hantera vektor multiplikationen som är resultatet av neuronätets vikter. Och som jag förstod det behövdes dessa eftersom enbart en liten andel av strålarna räknas fram och resten är sedan neuronätet som förstår var resten ska placeras, och man tar då genvägen och helt enkelt placerar strålarna så som neuronätet säger

Det "tensor-cores" exakt gör är detta:

A = B * C + D

Där A och D är en 4x4 matris med 16/32-bitars flyttal medan B och C alltid måste vara en 4x4 matris med 16-bitars flyttal.

Vid maskininlärning får man ju enorma matriser som ska multipliceras. Finns effektiva algoritmer för att bryta ned stora matriser i mindre delproblem, med tensor-cores får man ju enorm acceleration för detta då de är brutal-snabba på 4x4 matriser (i teorin x8 snabbare jämfört med att köra på CUDA-kärnor utan tensor-cores).

Det du beskriver är nog vad du läst om Nvidias DLSS (Deep Learning Super Sampling).
Edit: folk verkar inte jätteimponerade av DLSS så här långt, SweC har några artiklar publicerade i ämnet

Har sett att Nvidia även jobbar på "denoise" av ray tracing bilder m.h.a. tensor-cores. Men är inget jag läst på om.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Dec 2001
Skrivet av Yoshman:

Edit: hittade missen här. Tyckte ändå jag hade referenser som nämnde låga TFLOPS vilket gjorde att 2 TFLOPS "känndes" rätt
Missen är att jag räknade bara på en enda scen, ska ju multipliceras med FPS!

Inte för att vara sådan, men det var lite det jag menade med "men saknar inte den här uträkningen en * fps, med tanke på S:et i TFLOPS?"

Trust me, I'm an engineer!

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Nov 2001

Skönt att du skriver ray tracing och inte strålspårning.

Jag har alldrig sett någon använda 'strålspårning' förren RTX serien kom. Usch alltså.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av jaqob:

Inte för att vara sådan, men det var lite det jag menade med "men saknar inte den här uträkningen en * fps, med tanke på S:et i TFLOPS?"

Såg det nu, ber om ursäkt att jag missade att du så tydligt pekade ut exakt vad problemet var. Tror du mig att jag missade din helt korrekta rättelse då jag svarade på språng då det var tre hundar som ville gå ut (faktiskt sant, tro det eller ej)

Men för att åter gå till huvudpunkten här: ville bara belysa att även med relativ "elak" beräkning av hur många operationer som behövs hamnar man i att kort som GTX1080Ti och Vega 64 har ju i rå TFLOPS mer än nog med kraft. Så anledning till att man måste ta till saker som RT-cores ligger i någon annan dimension.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007

Jag tror att denna generation av RTX kan klara DXR utmärkt, så länge man inte överdriver effekterna.
Säg ett något snyggare spel för 30% prestanda, det är något jag tror många är beredda att betala.
DLSS tror jag inte alls på, på tok för komplicerat och inget märkvärdigt.

Priset för korten tycker jag är för högt, såg att RTX1070 och GTX1080 har ungefär lika många transistorer, RTX funktionen har nog inte kostat så farligt mycket kretsyta, man har gjort om kärnorna på ett fiffigt sätt.
Men det klart, de sätter ju så högt pris de kan ta ut.

AMD Ryzen 7 1700 | Vega RX 64 | https://valid.x86.fr/fgqnte | Stockkylaren | Bitfenix Whisper M 750W | Corsair 600T Graphite vit.
AMD FX8350 | Polaris RX 460 4 GB | https://valid.x86.fr/0q5pkm | Cooler Master V 700W | 32 GB ECC-Minnen.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Medlem
Registrerad
Dec 2001
Skrivet av Yoshman:

Såg det nu, ber om ursäkt att jag missade att du så tydligt pekade ut exakt vad problemet var. Tror du mig att jag missade din helt korrekta rättelse då jag svarade på språng då det var tre hundar som ville gå ut (faktiskt sant, tro det eller ej)

Men för att åter gå till huvudpunkten här: ville bara belysa att även med relativ "elak" beräkning av hur många operationer som behövs hamnar man i att kort som GTX1080Ti och Vega 64 har ju i rå TFLOPS mer än nog med kraft. Så anledning till att man måste ta till saker som RT-cores ligger i någon annan dimension.

Var mest småaktigt av mig att ens påpeka det! Så du behöver inte på något sätt ursäkta dig

Skickades från m.sweclockers.com

Trust me, I'm an engineer!

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Aug 2007

Mysig och bra artikel

Men minns Geforce 256 som enormt mycket högre prestanda jämfört med TNT2 m.fl.

Spel: Ryzen 7 1800x, R9 270, 16GB DDR4 Flare X
Har haft dessa GPUer: Tseng ET6000, Matrox M3D, 3DFX Voodoo 1-3, nVidia Riva 128, TNT, TNT2, Geforce 256 SDR+DDR, Geforce 2mx, 3, GT 8600m, GTX460 SLI, GTX580, GTX670 SLI, 1080 ti AMD Radeon 9200, 4850 CF, 6950@70, 6870 CF, 7850 CF, R9 390, Vega 64
Lista beg. priser GPUer ESD for dummies

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

Vissa kanske undrar hur mycket resurser som lagts på att reda ut om det vore möjligt att hantera ray tracing på ett väldigt effektivt sätt m.h.a. av existerande GPU-HW.

Nvidia hävdade vid lansering av RTX-korten att de jobbat med tekniken i ca 10 år. Finns en hel del som pekar på att det ligger en del sanning i påståendet, går att hitta massor med forskningspapper åren mellan 2000-2010 som presenterar olika idéer kring hur man effektivt skulle kunna hantera ray tracing med SIMD/SIMT paradigmen (den som GPU primärt utnyttjar för sin parallellism).

Det man i slutändan konstaterade var att primärstrålarna kan typiskt hanteras relativt effektivt strålar i närliggande pixels ofta träffar samma eller i alla fall närliggande trianglar.

Problemet är att redan SSE/AVX är en utmaning så fort man ger sig på sekundärstrålar. För att förstå problematiken på GPUer är det viktigt att ha i bakhuvudet att SSE är rätt mycket som en GPU med en "warp" bredd på 4 medan AVX har en bredd på 8 "CUDA-kärnor". Nvidias GPUer har en bredd på 32 "CUDA-kärnor" och AMDs GCN har en bredd på 64 "CUDA-kärnor" (om vi håller oss till Nvidias nomenklatur, AMD kallar en "warp" för en "wave-front" men är samma sak).

Vad är då exakt problemet här?

Har man denna kod

void foo(float *a, float *b) { int simdLane = threadId.x; // threadId.x ger CUDA-kärnan för detta anrop if (a[simdLane] > 0) { bar(a, b); } else { baz(a, b); } }

GPUer har sedan de fick "programmera shaders" för över tio år sedan varit kapabla att hantera att olika CUDA-kärnor tar lite olika väg genom programkoden.

Men då det bara finns en enda programräknare för alla trådar som tillhör samma "warp" finns två viktiga egenskaper som måste uppfyllas för att en GPU ska hantera koden effektivt:

  • I de flesta fall måste alla trådar i samma warp ta samma väg vid villkorad körning, d.v.s. endera "if" eller "else" delen

  • om vissa trådar tar en annan väg måste mängden kod som skiljer sig vara så kort som möjligt

Om vi antar att funktionerna bar() och baz() är relativt dyra (som mycket väl kan vara fallet för sekundärtrådar om de får studsa många gånger) blir ju effekten av att minst en tråd tar en annan väg att effektiviteten minskar rejält.

Som exempel, antag att kostnaden för bar() och baz() är ungefär densamma, i det läget kapas effektiv prestanda i hälften då en GPU (eller CPU som använder SIMD) måste göra beräkningen på följande sätt

  • först körs bar(), alla trådar som inte tar den vägen markeras sin inaktiva -> inget händer med data för de inaktiva trådarna

  • sedan körs baz(), nu med de trådar som körde bar() inaktiva

Om alla trådar tar samma väg kommer den funktion ingen anropade naturligt vis inte heller köras, då det fallet är effektivt.

ray tracing är rekursiv (följ primärstrålarna, för de strålar som träffar en yta generera sekundärstrålar och följ dessa etc.) är det tyvärr rätt sannolikt att CUDA-trådar som väl divergerat inte kommer ta samma väg förrän alla sekundär, tertiär etc trådar för en viss primärstråle är färdighanterad.

För en bredd på 4 som för SSE verkar man ändå hittat varianter av ray tracing där SIMD ger ett klart mervärde. Men redan vid en bredd på 8 (AVX) börjar man se en rätt stor variation mellan olika scentyper. GPUer har som sagt 32/64 trådar, det går inte att utnyttja på ett bra sätt för ray tracing vilket är orsaken att trots enorm beräkningskapacitet (typiskt >x10 över HEDT CPU) blir det inte jätteeffektivt, behövs något som inte är SIMD/SIMT för hantering av strålarna.

Några axplock av olika försök att använda SIMD/SIMT för ray tracing

Detta sammanfattar problematiken bra

Nu blir ändå GPUer allt bättre på att hantera villkorad körning, GPUer är numera snabbar eoch mer energieffektiva på ray tracing jämfört med CPUer även utan RT-kärnor. Men RTX-serien ger ändå en vink om att dedicerat kisel för att hantera stråle/triangel träffar ger 4-6 heltalsfaktorer till över Turing-kärnorna (som i sin tur ger 30-50 % bättre GPGPU prestanda jämfört med Pascal).

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Dec 2016
Skrivet av Yoshman:

Det "tensor-cores" exakt gör är detta:

A = B * C + D

Där A och D är en 4x4 matris med 16/32-bitars flyttal medan B och C alltid måste vara en 4x4 matris med 16-bitars flyttal.

Vid maskininlärning får man ju enorma matriser som ska multipliceras. Finns effektiva algoritmer för att bryta ned stora matriser i mindre delproblem, med tensor-cores får man ju enorm acceleration för detta då de är brutal-snabba på 4x4 matriser (i teorin x8 snabbare jämfört med att köra på CUDA-kärnor utan tensor-cores).

Det du beskriver är nog vad du läst om Nvidias DLSS (Deep Learning Super Sampling).
Edit: folk verkar inte jätteimponerade av DLSS så här långt, SweC har några artiklar publicerade i ämnet

Har sett att Nvidia även jobbar på "denoise" av ray tracing bilder m.h.a. tensor-cores. Men är inget jag läst på om.

Kollat lite under helgen angående detta och det verkar som om själva avsikten är just att använda tensor-cores till att denoisa suddiga ray-tracing bilder. Man ska alltså enbart beräkna en liten andel strålar ( => suddig bild ) och sedan ska man göra denoise för att få bilder i real-time.

Har även sett lite kommentarer att det var själva planen men att utvecklare inte verkar använda det så mycket än.

Ledsen, men har inga källor då jag mest läste för eget nöjes skull.

Trädvy Permalänk
Medlem
Plats
Digital medborgare
Registrerad
Aug 2004
Skrivet av mrpijey:

Indieutvecklarna är ju de enda idag som vågar prova på nya saker då de stora drakarna endast är intresserade av positiva kvartalsrapporter och inte ny teknik eller spelglädje

Räknar du DICE och 4A Games som indies?

gfårs 1070. 3570K. 16 Gigabong RAM. Server, NAS, pi, steamlink, casts, nätverkssladdar, sega master system, massor av faptops, mus med 17 knappar, öronproppar, strumpor av ren bomull med elastiskt band för att hålla dem uppe. 2 barn, 1 fru, 99 problem.

Trädvy Permalänk
Medlem
Registrerad
Apr 2006

@kelthar: Du vet väl vad indie betyder? Indie = Independent. DICE är ägt av Electronic Arts, så de är verkligen inte independent då det är EA som bestämmer allt. RTX i BF var ju ett marknadsföringstrick och se hur bra det gick (då BF:V anses vara en flopp enligt dem). 4A Games är däremot väldigt independent så de har friheten att testa vad de vill, vilket de gjort. De är inte ägda av något stort pengaroffande bolag heller som bara tittar på hur stor deras aktieinnehav är värt. Samma sak med t.ex Projekt Red.

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Jun 2007
Skrivet av necris:

Kollat lite under helgen angående detta och det verkar som om själva avsikten är just att använda tensor-cores till att denoisa suddiga ray-tracing bilder. Man ska alltså enbart beräkna en liten andel strålar ( => suddig bild ) och sedan ska man göra denoise för att få bilder i real-time.

Det är så Quake 2 med ray tracing fungerar, som skapades just för att demonstrera den avancerade brusreduceringen (eng. denoise) som används i spelet. Längre ner på den länkade sidan finns exempel där man kan jämföra hur spelet ser ut före och efter brusreduseringen. Just det spelet använder dock inte tensor-kärnorna för brusreduceringen.