Sugárkövetés jobban

A sugárkövetést az előző oldalakon szándékosan hagytuk ki, ugyanis kicsit bővebb magyarázatot érdemel, hogy mi változott. Az NVIDIA úgynevezett RT magként jelzi az eljárásért felelő egységeket, és ezekből egy-egy feldolgozó található multiprocesszoronként, azaz a GA102 lapkára nézve 84. A valóságban azért ez bonyolultabb, hiszen ezeknek az RT magoknak van vezérlőjük, és a működésük is teljes lapkára levetítve értelmezhető igazán. Emiatt fontosnak tartjuk leírni, hogy amikor egy RT magról beszélünk, akkor valójában a sugárkövetés feladatának egy részét tárgyaljuk, méghozzá a metszésvizsgálatot, illetve a bejárást.

De nem csak a hardverről van szó, ugyanis a Microsoft szoftveres szempontból is jelentős változásokat eszközöl. Az első DirectX Raytracing a bemutatásakor – nevezzük DXR 1.0-nak, mert már az érintettek is ezt teszik – egy úgynevezett dynamic shader based raytracinget kínált fel. Ez leginkább annyit tudott, hogy működött, de egyáltalán nem a teljesítményre volt optimalizálva. A rendszer alapvetően annyit tett, hogy kilőtte a sugarakat, a hardver megkereste, hogy hol talál el például egy háromszöget, ha egyáltalán lesz találat, és ennek megfelelően jöhetett egy hit (találat esetén) vagy miss (találat nélkül) shader. Bármelyiket is hívta meg a program, az be lett linkelve az erre vonatkozó bekötési táblába, és ez alapján tudta a rendszer megosztani a hit vagy miss shaderrel a szükséges adatokat, vagyis ilyen formában volt végigkövetve egy sugár útja.

Az új DirectX Raytracing, rövidebb nevén DXR 1.1 a fentiekkel szemben bevezeti az úgynevezett inline raytracinget. Ez alapvető váltás a korábbi módszerhez képest, mivel megszűnik a bekötési tábla, illetve nem lesz több elszeparált dinamikus shader. Ehelyett már az eredeti shader tartalmazza a kontextus struktúráját, és utasítja a hardvert, hogy kezdje meg a bejárási lépcsőt. Ha egy sugárnak lesz találata, akkor a függvény visszatér, és már eleve ott van a kontextus struktúrája a shaderben, amivel rögtön megkezdődhet a munka, nem kell már semmiféle adatmozgás, illetve elszeparált dinamikus shader indítása ehhez.

Szoftveres szinten ez igen jelentős különbség, és például az inline raytracing azért feltételezi, hogy a hardver ütemezője képes végigkövetni a sugár útját. Ha nem, akkor erre valamiféle emulációt kell írni, ami a program oldalán láthatatlan formában ugyan, de annak ellenére is visszahozza a bekötési táblát, hogy maga a friss futószalag kivonta azt.

Az NVIDIA ennek a hardveres implementációjáról olyan sokat nem árul el. Az világos, hogy a Turing a dynamic shader based raytracingre volt tervezve, hiszen akkor még úgy tűnt, hogy ez lesz a jó irány, csak azóta a Microsoft meggondolta magát, és hoztak egy alternatív megoldást. Arról nincs pontos adat, hogy az Ampere erre mennyire van felkészítve, valószínű ugyanakkor, hogy az ütemezés fejlődött annyira, hogy az inline raytracingre optimális legyen a hardver.

Ha az ütemezést figyelmen kívül hagyjuk, akkor bármilyen sugárkövetést biztosító megoldást is veszünk, az adatmozgás tekintetében a hardveres megvalósítások egy kaptafára épülnek. Effektíve az adatok biztosítása során kvázi ugyanaz történik. Részletesebben leírva, a geometriára vonatkozó árnyalási fázisokat követően egy jelenet hierarchiáját generáló részegység készít egy BVH (bounding volume hierarchy) gyorsítóstruktúrát. Ennek egy része statikus, vagyis újrahasznosítható, de az animációk miatt szükség van dinamikus, azaz jelenetenként frissülő adatokra is. Tulajdonképpen ez az alap, az egész működés kiindulási pontja, ugyanis eléggé fontos, hogy a hardver az egyes sugarak tesztelésekor ne menjen végig az jelenetben található összes háromszögön, mivel az eléggé lassú lenne. Ezeket inkább csúnyán fogalmazva bedobozolja, és a sugárnál így elég azt tesztelni, hogy eltalálja-e az adott dobozt. Valamelyiket el fogja, és ilyenkor elég csak azokra a háromszögekre koncentrálni, amelyek az adott dobozon belül vannak. Persze részletes geometria mellett nem árt többszintű struktúrát alkalmazni, ami – ismét csúnyán fogalmazva – dobozokat jelent majd a dobozban. A végeredmény szempontjából az a lényeg, hogy kellően mély legyen az adott BVH gyorsítóstruktúra, aminek hála ugyan hat-hét dobozon talán át kell menni, de végül csupán pár vagy pár tucat háromszögre kell tesztelni az adott sugarat. Ez pedig még mindig gyorsabb, mintha erőből csinálnánk mindent.

Az RT magokon belül a fenti folyamat gyorsítására való, metszésvizsgálatra, illetve bejárásra vonatkozó részegységek tanyáznak. Nagyon leegyszerűsítve utóbbi azt segíti, hogy a kamerából koherensen kilőtt sugarak a meghatározott távolságig teljesen bejárják a jelenetet, előbbinek hála pedig vizsgálva lesz, hogy mibe ütköznek bele.

A Turing és az Ampere RT magja [+]

Az NVIDIA az Ampere esetében két változással élt a szóban forgó RT magok kapcsán. Többek között a háromszögekre vonatkozó metszésvizsgálat kétszer gyorsabb lett, ami jó hír, mert a Turing itt nem volt valami combos, továbbá van egy új részegység, ami képes az idő függvényében interpolálni az adott háromszög pozícióját. Utóbbival a mozgás irányú elmosás (motion blur) effektet lehet hardveresen gyorsítani.

Van még egy újítás, de az nem tartozik szorosan az RT magokhoz. Ahogy korábban már leírtuk, ez az egység csak a teljes eljárás egy részéért felel, de még a sugárkövetés is igényli az általános feldolgozókat (nagyon is), tehát vannak olyan feladatrészek, amelyek multiprocesszorok compute blokkjainak futnak le. Ezek a Turing esetében elvették a szabad számítási kapacitást a grafikai munkától, de az Ampere-nél, az első oldalon már részletezett, másodlagos, INT32-es feldolgozótömb FP32-es támogatásának hála nem fogják túráztatni az alapértelmezett feldolgozókat. Ez a konkurens végrehajtási forma némileg gyorsítani tud egy-egy sugárkövetéssel számolt effekt futtatásán. Ez a funkció azonban nem igazán működik automatikusan, az alkalmazásokat fel kell készíteni rá, hasonló módon, ahogy például az aszinkron compute-ot szokás alkalmazni.

A cikk még nem ért véget, kérlek, lapozz!