A GeForce RTX sorozat bemutatása óta viszonylag sokat írtunk a DirectX Raytracingról, a DirectX 12-nek annak a kiegészítőjéről, ami ezt az egész sugárkövetést biztosítja a szoftveres oldalról. Az RTX-ről viszont semmit, amire két jó okunk volt: egyrészt keveset lehetett tudni róla a bemutató alkalmával, másrészt gyakorlatilag sikerült egy jó erős káoszt okozni a fejekben, hiszen senki sem tudja már, hogy mi is az az RTX, illetve hogyan kapcsolódik a DirectX Raytracinghez. Emiatt, két nappal a bemutató után, pont eljött az idő, hogy az RTX-ről is essen szó, helyrerakva a dolgokat, valamint beszélve egy kicsit a hardveres oldalról.
Az RTX, amellett, hogy az NVIDIA ezt egy jelölésnek használja, gyakorlatilag a DirectX Raytracinghez írt implementáció neve. Bizonyos értelemben maga a driver, de ezt azért nem szokás így említeni, mert a DirectX Raytracing a DirectX 12, ezen belül is a DirectCompute API futtatási környezetét használja, tehát az RTX inkább a már meglévő meghajtót egészíti ki olyan részekkel, amelyek segítségével elérhető a DirectX Raytracing futószalagján belül az egyes lépcsők gyorsítása. A Microsoft úgy specifikálta a fejlesztését, hogy ilyet bármelyik gyártó írhasson, a redmondi óriáscéget csak a végeredmény érdekli, hogy a futószalagból ki milyen részeket gyorsít az nagyrészt mellékes. A Redstone 5-ös Windows 10-ben érkező specifikációval a natív hardverelérés mindig az API alatt történik meg, így garantálva az API-ra írt, egységes kód kompatibilitását. Ha pedig hiányzik ez a natív implementáció, akkor a fallback layer átveszi a munkát, ami tulajdonképpen felfogható a Microsoft saját, univerzális implementációjának, és ez garantálja, hogy azokon a hardvereken is fusson a kód, amelyek nem kaptak natív támogatást.
Hirdetés
Kicsit bonyolultnak tűnik ez, de végeredményben arról van szó, hogy a fejlesztő ír egy kódot a DirectX Raytracingre, ami azt vagy lefuttatja a fallback layeren, vagy talál a hardverhez egy natív implementációt, és akkor átadja annak a munkát. Mivel szabványról van szó, bizonyos specifikációkat be kell tartani, tehát a kompatibilitás garantált, de azt a Microsoft nem szabja meg, hogy a hardver a gyorsítható lépcsők közül melyekre tartalmazzon valami natív megoldást, és azt sem, hogy ez mi lehet.
Most, hogy ezeket a fontos dolgokat átrágtuk, és rendet tettünk a fejekben, át is térhetünk az NVIDIA implementációjára, amiről említettük, hogy az RTX nevet viseli. Ugye a fentiekből következik, hogy a nem gyorsítható lépcsők, vagyis effektíve a sugarak generálása, illetve az árnyalásra vonatkozó elemek a hagyományos, szimpla pontosságú lebegőpontos feldolgozókon fognak működni. Ezekre igazából nem is kell natív implementáció, a DirectCompute API új, Redstone 5-ös Windows 10-ben érkező verziója fel fogja ismerni az úgynevezett DXR shadereket, azok nagyjából egy tucat új függvényét, és a DirectX 12-höz írt meghajtón ez futni is fog. Nagyon leegyszerűsítve a fallback layerben, illetve a gyártói, natív implementációkban gyakorlatilag minden olyan elem lesz benne, ami nem ehhez köthető. Itt a fallback layert gyorsan lerendezzük azzal, hogy a Microsoft a futószalag maradék lépcsőjére írt egy általános implementációt a DirectCompute API-ra, értelemszerűen ez nem gyorsított megoldás, és már ismert, hogy az Intel Gen8 és Gen9, illetve az NVIDIA Kepler, Maxwell és Pascal architektúra biztosan így fog dolgozni. Az NVIDIA Fermi és az Intel Gen7.5 még támogatja ugyan a DirectX 12-t, de ezeket a Microsoft nem tekinti úgynevezett DirectX 12 osztályú hardvereknek, így a DirectX Raytracing sehogy sem működik rajtuk. Az AMD csak az év végi, nagy meghajtófrissítéskor közli, hogy milyen megoldással állnak elő, így velük még nem tudunk foglalkozni.
Az NVIDIA oldalán az RTX implementáció a Volta és a Turing architektúrához tartalmaz majd natív elérést. Előbbi esetben ez kimerül az úgynevezett denoising feladatban, amit zömében a tensor magok fognak végezni. Ez azért lényeges, mert a hardverek teljesítménye nem elég arra, hogy megfelelő mennyiségű sugarat használjunk, jórészt pixelenként egy sugárnál megáll a tudomány, de leginkább ez is sok lesz, így a sugárkövetés rendkívül zavaros eredményt ad, amit a denoising fog minimálisan értékelhető formába önteni. Ez nem jelenti rögtön azt, hogy az eredmény így használható lesz, de legalább lehet vele kezdeni valamit további utófeldolgozás mellett.
A Turing architektúra újdonsága az úgynevezett RT mag, ami igazából nem is mag. Említettük már, hogy ez a shader multiprocesszorokon belül található, és egy nagy ütemező vezérli. Technikailag tehát egy, a lapkán belül igencsak szerteágazó egységről van szó. Ennek az áramkörnek a célja, hogy a sugár-háromszög metszést felgyorsítsa. A sugárkövetés szempontjából eléggé egyszerű, hogy ha sugarakat indítunk a pixelekből, akkor a jelenet geometriai vázában valamit metszeni fognak. Persze itt bejöhet a képbe olyan tényező is, hogy a sugár nem megy elég távolra, hogy ütközzön egy háromszöggel, de értékelhető paraméterezés mellett viszonylag sok sugár útját keresztezi majd valami. Arról ugye nyilván visszaverődik a megfelelő szögben, és amíg el nem éri a programon belül beállított maximális hosszt, addig még további háromszögekkel ütközhet, illetve esetlegesen eltalálhat egy fényforrást.
Ezt eddig egyszerű elképzelni, de ahhoz, hogy ez működjön, szükség van egy adatstruktúrára, ami a DirectX Raytracing esetében a Bounding Volume Hierarchy (BVH). Ebbe nagyon részletesen bele lehetne menni, de ezúttal érdemes az egyszerűséget választani, így felelevenítjük a raszterizálást, ahol a mélységpuffer (Z-buffer) alapján lehet eldönteni, hogy a pixelekből kilőtt sugár melyik minta színét veszi fel. A Bounding Volume Hierarchy gyakorlatilag olyan a sugárkövetésnek, mint a Z-buffer (akár hierarchikus) a raszterizálásnak. Ebből viszonylag egyszerűen érthető a szerepe.
A Bounding Volume Hierarchy viszont problémaforrás is, hiszen nehezen párhuzamosítható struktúráról van szó. Az RT mag itt jön képbe, hiszen egy olyan, fixfunkciós futószalagról van szó, amely lerövidíti az adatstruktúra adott node-jának, illetve a feldolgozandó háromszögnek az elérési idejét. Alapvetően maga a hardver nagyrészt vezérlőegység, illetve gyorsítótár, tehát nem egy hihetetlenül bonyolult ASIC (alkalmazásspecifikus integrált áramkör), de végeredménybe képes elérni, hogy az utasítás kiadásához tartozó feladat az eredménye bekerüljön a multiprocesszor célzott regiszterébe.
Az RT maghoz tartozik az új mérőszám, ami a Gigarays/s. Persze van itt TeraRTX-OPS is, de ezt hagyjuk, mert az a legnagyobb probléma vele, hogy szinte minden jelenetben más lesz az elméleti maximuma. Ez amiatt van, mert a Gigarays/s ugyan a hardvertől függ, ha nyersen csak az elméletet tekintjük, de a sugárkövetés nem csak abból áll, hogy sugarakat lövöldözünk, annak vannak más, igen megterhelő szakaszai, amelyek jelentősen befolyásolhatják a teljesítményt. Tehát az RT mag tudhat 6, 8, 10 Gigarays/s-ot, de ezt azért ki is kell szolgálni. Többek között egy háromszög három vertexből áll, ami 32 bites lebegőpontos formátumban tárolva 48 bájtnyi terhelés. Ha 10 Gigarays/s az RT mag teljesítménye, akkor csak a háromszögek feldolgozása 480 GB/s-ot vinne el, vagyis nagyjából 13 bájt marad az adatstruktúrára. Ez itt a nyers elmélet, a gyakorlatban azért a háromszögek egymáshoz kapcsolódnak, tehát a vertexeket is megosztják, így egy háromszögtömb esetében inkább számolhatunk átlagosan úgy egy vertexszel. Ez így már "csak" (nagyon idézőjelben) 160 GB/s. Átlagosan marad 45 bájt az adatstruktúrára, ami még mindig kevéske, mert a mai játékokhoz, főleg a tesszelláció megjelenése óta, elég mély struktúra szükséges, ami akár 80 bájtnyi terhelést is jelenthet, és ehhez nincs meg a memória-sávszélesség. Ez a vezető oka annak, hogy a sugárkövetés teljesítménye annyira jó, ha a geometriai komplexitás alacsony, vagy fal mellett történik a játék, és annyira visszaesik, ha jön egy nagyobb és geometriailag komplexebb tér. Persze bizonyos mélységű BVH struktúrát bele lehet préselni az L1 gyorsítótárakba, amelynek az adatátviteli teljesítménye igen nagy, de a mai programok geometriai komplexitását nem igazán, így az RT mag teljesítményét leginkább a memória-sávszélesség korlátozza. Emiatt kritikus fontosságú, hogy amíg a múltban a geometriai részletesség növelése volt a cél, addig ez megtorpanhat, mivel igen káros a sugárkövetés aktuális állapotának, még akkor is, ha a sugarakat koherensé tudja rendezni a rendszer, ami egyébként eleve nagyon fontos, hiszen a nem koherens sugarak teleszemetelik a gyorsítótárakat, vagyis jól legyilkolják az általános teljesítményt is.
A 6, 8, 10 Gigarays/s tehát egy nagyon elméleti érték, amit rendkívül ideális körülmények között talán el lehet érni, de a gyakorlatban a memória-sávszélesség mindenképpen limitál. Ez egyébként megmagyarázza, hogy miért ebben a paraméterben ugrott nagyot a Turing a korábbi, Pascal generációhoz képest, de nagyon az elején járunk a dolgoknak. Viszont maga az alapprobléma a régi hardvereket is érinti, tehát még ha a gyakorlatban a 6, 8, 10 Gigarays/s megközelíthetetlen is, az előny egy jelentős része, a korábbi generációhoz képest megmarad, az elméleti paraméterekkel viszont nem érdemes számolni.
A fentiek arra is rávilágítanak, hogy van ebben tartalék. Az a teljesítményigény tehát, ami ijesztőnek tűnik ma, holnap (jelen esetben ez inkább következő évet jelenti) már nem lesz az. Javítani pedig viszonylag egyszerű lesz, ugrani kell a TB/s-os szintre a memória-sávszélesség szempontjából. Még ha a hardver ugyanaz is marad a GPU-n belül, ez a lépcső már önmagában sokat gyorsítana a sugárkövetés teljesítményén, a mai játékokhoz hasonló, komplex geometriai részletesség mellett. De miért is marad a GPU ugyanaz, elvégre 7 nm-es node-on jelentősen növelhető lenne mondjuk az első szintű gyorsítótárak összesített kapacitása, ami szintén nagyon sokat segítene a sugárkövetésnek, még akkor is, ha a feldolgozók száma nem változik a jelenlegi dizájnhoz képest. Ez érdekessé teheti az NVIDIA számára a történetet, hiszen ezen a területen alapvetően nem a több shader magból tudnak nagy teljesítményt nyerni, hanem a több gyorsítótárból, illetve a szélesebb memóriabuszból.
