A Microsoft még március közepén mutatta be a DirectX Raytracinget, amely egyelőre tesztelési céllal bekerült a Windows 10 April 2018 frissítésébe, de csak fejlesztői módból hívható elő, ami tökéletes a lehetőségek próbálgatására, de nyilván nem lehet rá programot szállítani. Az idei SIGGRAPH-on azonban több információ is kiderült, hogy miképp fogja a technika megtenni az első szárnypróbálgatásait.

Bár az érintettek – gondolva itt elsődlegesen a Microsoftra – nem garantáltak még semmit, azért jelen formában igen nagy az esélye, hogy a DirectX 12 API, fentebb linkelt kiegészítése elérhető lesz az év végén érkező, Redstone 5 kódnevű Windows 10 frissítésben. A végleges specifikáció nem biztos, hogy lezárásra kerül ebben az évben, de a rendszer működése legalább nem lesz a fejlesztői módhoz kötve, ami már lehetőséget ad arra, hogy programot is lehessen szállítani rá.

Ami biztos, hogy a DirectX Raytracing aktuális specifikációja megváltozik, így a Redstone 5-ös Windows 10 frissítésben érkező verzió más lesz. Ennek az oka, hogy a DirectX Raytracing jelen pillanatban más kódot igényelhet a fallback layerhez, illetve a meghajtókon keresztüli implementációkhoz. Ugyanakkor ezt már az elején lehetett tudni, hogy nem túl optimális, mert ilyen formában a fejlesztők gyakorlatilag implementációnként külön kód megírására kényszerültek volna. Emiatt a specifikációkat a Microsoft megváltoztatta, méghozzá úgy, hogy egyetlen kódbázisból támogatható legyen az összes, DirectX 12 osztályú hardver. Nem számít tehát, hogy az adott GPU-hoz a gyártó biztosít-e drivert, vagy sem, és az sem lényeges, hogy a gyártói implementáció milyen, csak annyi a fontos, hogy ha a hardver támogassa az alapfeltételeket, amivel a DirectX Raytracing kiegészítés is futni fog valahogy rajta. Ezt ugye eredetileg is így ígérte a Microsoft, csak az aktuális, fejlesztői implementáció nem ilyen, de a Redstone 5-be kerülő már ilyen lesz. Ezt csak azért érdemes kiemelni, mert a változások miatt a most írt kódok nem feltétlenül kompatibilisek az érkező Windows 10 frissítés futtatási környezetével.

A Microsoft alapvetően a fallback layert saját maga fogja írni, és ez egy olyan felület, amely a feladatokat compute shaderben futtatja. Itt fontos, hogy fentebb nem DirectX 12-t támogató, hanem DirectX 12 osztályú hardvert írtunk. Ez azért lényeges, mert a DirectX Raytracing minimum igénye a shader modell 6.0. Amelyik hardver tehát támogatja a DirectX 12-t, illetve rendelkezik a meghajtóimplementáció egy olyan fordítóval, ami kezeli a DXIL-t, az képes majd futtatni a fallback layeren keresztül a DirectX Raytracinget. A gyártóknak azonban lehetőségük van továbbmenni, és a futószalag egyes lépcsőin belül, azok bizonyos részeit gyorsítani. Az úgynevezett DXR shaderek nyilván nem gyorsíthatók, ezek igazából nem sokban különböznek a compute shaderektől, csupán pár extra függvény lesz elérhető. A futtatásukat így is a DirectCompute API végzi majd, és fallback layer esetében aszinkron compute módban tölthetők be, a hagyományos grafikai számításokkal párhuzamosan, míg gyártói implementációnál az aszinkron compute ugyan megkerülhető, de ez nem igazán ajánlott.

A programok szempontjából két dolog van amire figyelni kell. Mivel a DirectX Raytracing a Redstone 5 kódnevű Windows 10 frissítéshez van kötve, illetve megköveteli a DXIL támogatását, így egy erre írt program nyilván az érkező Windows 10 verzióhoz van láncolva. Ez logikus, de az már nem, hogy a DXIL miatt nem feltétlenül szükséges más köztes nyelven szállítani az alkalmazást, vagyis ha a fejlesztő minden shaderjét csak DXIL-re fordította le, akkor gyakorlatilag a Windows 10 áprilisi frissítése lesz a minimum igény, még akkor is, ha a DirectX Raytracing effekteket a felhasználó kikapcsolja. Ahhoz, hogy a korábbi Windows 10 verziókkal, vagy akár Windows 8.1, 8 és 7 operációs rendszeren is fusson a program, szükséges a megírt shaderek átkonvertálása egy korábbi HLSL specifikációkba, majd ezek lefordítása D3BC köztes nyelvre, amit a korábbi Windows rendszerre kiadott meghajtók is képesek értelmezni. Ennek igazából az a nagy hátránya, hogy jelentősen megnöveli a költségeket a terméktámogatás oldalán, hiszen gyakorlatilag dupla akkora kódbázist kell karbantartani a shaderek szempontjából. Erre vonatkozóan az egyetlen költségcsökkentő ajánlat a Redstone 5 előtti Windows 10 rendszerek támogatásának elfelejtése. Ezzel kétségtelenül visszafoghatók a költségek, de a Windows 7 piaci részesedését figyelembe véve nem túl realista elgondolás.

A SIGGRAPH alkalmával lényeges elem volt, hogy a DirectX Raytracing valójában többre képes, mint amit majd az első körben látni fogunk belőle. Az érintettek szerint a sugárkövetés viszonylag egyszerűen beépíthető egy mai videojáték-motorba, ha csupán árnyékokra, ambient occlusionre, visszaverődésre, vagy temporális élsimításra van használva. Ezeket az effekteket ugye nem kell túlzottan szorosan integrálni, így a hagyományos raszterizálás mellett is jól működnek. Az egyetlen igazi követelmény egy kifejezetten gyors DirectX 12-es leképező, ami jól bánik a videomemória menedzselésével. Emiatt egyébként nagyon ajánlott, hogy senki se ugorjon bele a DirectX Raytracingbe, ha az előbbi feltételnek nem tesz eleget – csak a saját életét fogja megkeseríteni. A Microsoft szerint amúgy is időszerű átcsoportosítani az erőforrásokat a DirectX 12-re, és a DirectX 11-et elfelejteni, mert ezek az új eljárások a régi API-val nem lesznek üzemképesek.

A DirectX Raytracing pár effekten túli alkalmazása már nagyobb áldozatokat igényel, és itt már az aktuális leképezőket is jelentősen át kell szabni, ami jóval több időbe kerül. IDő viszont van, mert pár effektnél tovább amúgy sem lehet tovább jutni a mai hardverekkel. Bár nehéz meghatározni, hogy egy új lehetőségek szerint megírt hibrid leképező mikor kezd igazán optimálisan működni, elvégre ez függ a munkafolyamattól, de a jelenlegi tippek alapján, szimpla pontosság mellett úgy 50-60 TFLOPS elégnek tűnik. Ez lesz az a pont, amikor a DirectX API új kiegészítése igazán meg fogja mutatni az előnyeit, és nem csak pár effektre lesz jó ez az egész. Amire ma érdemes figyelni, hogy az effektek minőségét jól kell kalibrálni. A probléma az, hogy 4K-s felbontáson még igen kevés sugár mellett is sokat eshet a sebesség, akár a legerősebb hardveren is. Ha ez bekövetkezik, akkor az általános javaslat inkább a sugárkövetést alkalmazó effekt minőségének visszavétele, mintsem a geometriai részletesség csökkentése. Összhatásban ugyanis lényegesen kedvezőbb, ha a sugárkövetés történik meg a felbontás negyedével, mintha a teljes játék általános minősége romlana egyetlen effekt érdekében. Érdemes még játszani a sugár távolságával, ez is jelentősen javíthat a teljesítményen, illetve a játékteret lehetőség szerint annyira szűkre szabni, amennyire csak lehet, hogy az eljárás optimálisan működjön a rövid távolságra lőtt sugarakkal.