Ray Tracing har utan tvekan blivit framtiden för realtidsåtergivning, särskilt när rasterisering inte kan lösa vissa visuella problem och inte ger mer än sig själv. Men dess implementering är inte lätt och prestandan är inte perfekt även med de mest avancerade GPU: erna. Det är här nästa steg kommer in, Coherent Ray Tracing. Vad bidrar det med, varför är det nödvändigt och vad består det av?
Ray Tracing som används i spel idag är vad vi kallar hybridåtergivning där den sammanhängande delen av scenen återges med hjälp av rasteriseringsalgoritmen och den osammanhängande delen av scenen återges genom strålspårning, så trots vad marknadsföringen för de olika företagen säger, eran där spel återges rent genom strålspårning har inte kommit.
För att göra detta uttalande mer förståeligt, låt oss säga att scenen återges med hjälp av rasterisering och helt ignorerar indirekt belysning, som produceras när en ljuskälla faller på ett objekt och det reflekterar ljuset i nya riktningar.
Ray Tracing gör osammanhängande delar av scenen mer exakt, snabbt och effektivt än rasterisering, men det finns ett relaterat prestandaproblem när man gör den osammanhängande delen av scenen som gör beräkningskostnaden mycket hög vid När det gäller att applicera strålespårning och det är just nästa stora utmaning för företag som NVIDIA och AMD, optimera prestanda för den osammanhängande delen av scenen i strålspårning.
Konsekvent strålespårning och inkonsekvent strålespårning
Låt oss lägga undan den hybridåtergivning som används i spel för tillfället och rikta vår uppmärksamhet mot ren Ray Tracing, där strålar kan göras på två olika sätt.
- I ren strålespårning, sammanhängande strålar betraktas som de som kommer ut ur kameran och följer vägen till scenens frustumvy, dessa strålar kallas sammanhängande men de används inte i hybridåtergivning.
- Osammanhängande strålar är de som produceras genom att en ljusstråle påverkar ett objekt.
- Sammanhängande strålar är de som kommer från en primär ljuskälla, det vill säga de har inte genererats av inverkan av en tidigare stråle på objektet.
På en visuell nivå om vi bara talar om direktbelysning är det ingen skillnad i visuell kvalitet när det gäller att återge en scen med endast direkt belysning mellan rasterisering och strålspårning, lägg till detta till det faktum att alla spelmotorer fungerar via raster och du kommer att förstå orsaken varför vilken strålspårning inte används vid återgivning av den sammanhängande delen av scenen.
Prestandan för den icke-sammanhängande delen av Ray Tracing på en GPU
Problemet är att även om strålspårning är mycket bättre för att återge den osammanhängande delen av en scen än rasterisering, så finns det problemet att osammanhängande strålar har mycket lägre prestanda än att beräkna scenens sammanhängande strålar.
Anledningen till denna skillnad i prestanda beror på att inte all information från scenen inte finns i GPU cache, vilket är vad strålkorsningsenheterna får tillgång till, med icke-koherenta strålar påverkar de inte samma område av scenen och påverkar därför inte samma skuggning, vilket orsakar stopp i ett stort antal trådar i GPU, vilket orsakar sjunker i prestanda.
Detta är ett problem som de i filmindustrin löser genom algoritmer för omläggning av strålar, men de kan göra det enkelt för att de känner till kamerans position i förväg och därför kan omvandla alla scenens osammanhängande strålar till strålar. konsekvent genom en beställningsalgoritm.
Men när det gäller att rendera en film som de har hela tiden i världen, behöver de inte visa en bild några millisekunder och sorteringsalgoritmerna är mer för att spara tid och därmed kostnaden för deras kraftfulla rendering gårdar, men , Situationen i videospel är annorlunda.
Men i ett videospel där varje bild är unik kan det inte göras, det skulle dessutom krävas mycket kraftfull hårdvara så att beställning av scenens strålar inte skulle påverka dess höga bildhastighet, så det är just nu nästa stora utmaning att lösas av GPU-tillverkare och det är en avgörande faktor om Ray Tracing inte ska vara stillastående när det gäller prestanda.
Nuvarande GPU: er är inte avsedda för inkonsekvent strålspårning
Grafikprocessorerna som vi använder i våra datorer var utformade för rasterisering, vilket är en utnyttjad renderingsalgoritm som har mycket god nytta av den rumsliga och temporala platsen för minnesåtkomst.
Det mesta av arbetet som GPU: n måste utföra under rasterisering har den egenskapen att när man använder ett skuggprogram, särskilt under Pixel Shader, att data för pixlar och trianglar som den bearbetar delas med sina närmaste grannar. I scenen.
Så det finns många möjligheter att om GPU: n får åtkomst till data för en grupp trianglar och pixlar och samlar alla närliggande i minnet i cacherna så kommer den redan att ha data för närliggande pixlar och trianglar. Så ändringarna måste gå för att kunna utnyttja den gemensamma egenskapen hos alla GPU: er.
Rumsdatastrukturen
För att påskynda strålspårningen är vad som görs att bygga en rumslig datastruktur, nämnda struktur är inget annat än kartan över objekten i scenen på ett ordnat sätt.
Scenen omvandlas till ett slags kub med flera underavdelningar som indikerar var objekten är, varav det finns två typer:
- Scenen är uppdelad i vanliga block efter rymden.
- Scenen är uppdelad i de delar där det finns geometri eller element.
I spel har den andra typen valts genom att anta BVH, särskilt på grund av det faktum att NVIDIA har dedikerad hårdvara i sina GPU: er för att snabbt navigera i denna trädatastruktur, men det finns två typer av BVH:
- Statiska BVH: er måste byggas om igen efter att vi har modifierat något objekt i scenen, men när de väl har byggts snabbar de upp scenens återgivningstid.
- Med dynamiska BVH: er kan objekten uppdateras individuellt, på ett sådant sätt att tiden för att göra det är mycket lägre vid återuppbyggnad av BVH, men i gengäld ökar den efterföljande renderingstiden.
Och hur viktigt är det? Om vi vill ordna strålarna enligt deras bana i scenen måste vi först kunna ha en karta över samma scen som gör att vi kan lagra strålarnas bana.
Kartläggning av strålarnas väg
En lösning är att få strålarna att förkorsa scenen utan att ändra den, bara för att veta vilka objekt som kommer att påverka de olika strålarna och vilka är de strålar som kommer att korsa scenen. När förrundan är klar lagras de olika strålarna som särskilt påverkar en del av scenen i en minnesbuffert, även om de inte är relaterade till varandra.
Även om det inte finns något direkt samband mellan de olika strålarna på samma plats, finns det ett rumsligt förhållande, vilket hjälper till att utnyttja den gemensamma arkitekturen för alla GPU: er när man gör en scen med icke-sammanhängande strålar. Tanken är att pre-rendera scenen men utan att beräkna skuggorna som varierar färgvärdena för de olika objekten när de återges scenen, är vi helt enkelt intresserade av att veta vilka delar av scenen var och en av strålarna kommer att påverka.
Strålar som kör scenen
Strålarna som passerar scenen kommer bara att utföra en skuggning, Ray Generation Shader, vilket indikerar att detta objekt i scenen har förmågan att generera en indirekt ljusstråle, eftersom de för själva strålarna har en serie med sig parametrar för att förhindra att de studsar för alltid som bordtennisbollar över hela scenen.
För detta är det nödvändigt att placera en serie parametrar associerade med strålarna och objekten som skulle vara följande:
- En konstant som är antalet studsar som en stråle kan göra i scenen, när denna mängd studsar har gjorts oavsett de andra förhållandena, slutar strålen studsa.
- En konstant i varje material som är brytningskonstanten, som går från 0 till 1, vid varje korsning multipliceras strålens energivärde med brytningskonstanten, när en stråle når en energinivå tillräckligt låg, kastas den bort.
Med detta kan vi redan få strålarna att studsa igenom scenen på ett preliminärt sätt, vilket hjälper till att beställa data, eftersom vi med detta kan veta i vilka delar av scenen de olika strålarna kommer att påverka. Vilket kommer att påskynda prestandan kraftigt, men detta kräver två maskinvaruändringar.
Inbäddat minne för att lagra rumslig datastruktur
Det som återstår nu är att kunna lagra hela den geografiska datastrukturen i ett minne så nära processorn som möjligt, liksom pre-tour-data, men den här datastrukturen kan inte lagras i de begränsade cacherna på några megabyte. , varken Infinity Caché trots 128 MB skulle kunna lagra en sådan mängd data.
Vad som behövs är att hitta ett sätt att placera så mycket minne som möjligt nära GPU: n, som tjänar till att lagra hela den geografiska datastrukturen, nämnda minne skulle inte vara en cache och skulle inte vara en del av processorns minneshierarki, det skulle helt enkelt tjäna att lagra hela rumslig datastruktur inuti.
Ett sätt att uppnå detta skulle vara att använda SRAM-minne vertikalt anslutet till GPU, men implementeringen av detta minne kan komma med några ytterligare tillägg som utnyttjar dess framtida implementering i GPU: erna. Även om det finns andra sätt att göra detta kan de till och med göra det i form av en ny cache med hög densitet på sista nivån.
Nästa fasta funktionsenheter
Det kommer att finnas två, som kommer att vara avgörande för att öka prestanda:
- Den första kommer att ha ansvaret för att generera den rumsliga datastrukturen genom geometriens position i scenen.
- Det andra du kommer att göra är att notera var varje stråle träffar under turnén innan du använder Ray Tracing.
Båda enheterna kommer att dra nytta av det enorma inbäddade minnet som GPU: erna kommer att inkludera för att lagra scenens rumsliga datastruktur. Tack vare dem kommer vi att se en stor prestationsökning vad gäller Ray Tracing.
Dessa enheter finns redan i hårdvarulösningar som Wizard's PowerVR i form av Scene Hierarchy Generator and Coherency Engine, deras användbarhet har varit mer än demonstrerat men inte i extremt komplexa miljöer där implementering av inbäddat minne kommer att vara nödvändigt.
