Aránylag sok tetszetős dolog történik most PC-s szinten a sugárkövetés tekintetében, hiszen a Vulkan API nemrég kapott szabványos rendszert, amit ráadásul minden gyártó támogatni fog. Ezzel gyakorlatilag a domináns explicit grafikus API-k tekintetében van több, teljesen szabványos alternatíva a sugárkövetést használó effektek implementálására. Hogy milyen lehetőségeket választ a fejlesztő az döntés kérdése, a lényeg az, hogy a megírt kódok gyártófüggetlenül futhatnak.
Ez a DirectX 12 esetében mindig is így volt, míg a Khronos Group később kezdte el a sugárkövetésre vonatkozó fejlesztéseit, így megjelent pár Vulkan API-n futó játék, ami az NVIDIA saját kiterjesztését használja, ez viszont a jövőben már nem lesz így, a zöldek is bejelentették, hogy áttérnek a szabványos konstrukcióra. Ehhez persze még szükséges egy új grafikus meghajtó kiadása, de ez csak formalitás.
Korai azonban a nagy örömködés ugyanis megtudtuk, hogy az AMD dolgozik egy kerülőúton a Vulkan API szempontjából is. Egy korábbi írásunkban már felvázoltuk, hogy a DirectX 12 DXR 1.1-es felületéhez két, AMD-specifikus alternatíva is van, és ugyanezek elérhetők lesznek a Khronos Group által fejlesztett grafikus API-ra. Az implementáció tekintetében annyiban kedvezőbb a helyzet, hogy a sugárkövetésre szabott shader intrinsics függvények megoldhatók SPIR-V kiterjesztésekkel, ami esélyt adhat a gyártófüggetlen támogatásra, de valószínűleg annyira a Radeonokra lesz szabva a működés, hogy reálisan csak egy későbbi szabványosításban bízhatunk.
A fő cél egyébként az lehet, hogy a PC közelebb kerüljön a konzolokhoz. A Microsoft és a Sony új generációs rendszere ugyanis támogat egy igen fontos képességet a jövő tekintetében, méghozzá a programozható bejárást. Ez azonban – szabványos formában – se a DirectX 12, se a Vulkan API-n belül nem érhető el.
A programozhatóság leginkább azért lenne hasznos, mert lehetőséget ad számos olyan algoritmus implementálására, amellyel a sugárkövetéses effektek memóriaigénye drámai mértékben visszaszorítható. Ilyen például a LOD szintek sokkal célszerűbb kezelhetősége. A sugárkövetés jelenlegi működése a DirectX 12 és a Vulkan API-n belül eléggé korlátozott a LOD menedzselése szempontjából, gyakorlatilag a LOD szintet a sugár kilövésekor meg kell határozni. Ez addig nem gond, amíg a sugarak a jelenetet csak a kamerához nagyon közel pásztázzák, mert egyszerűen nem jutnak annyira messzire, hogy jelentősen nőjön a VRAM-használat. Ez azonban egy mesterséges korlátozás, amit nem igazán a hardverek teljesítőképessége szab meg, hanem az, hogy van-e elég fedélzeti tár a GPU mellett. Nagyon hosszan kilőtt sugarak esetében is ugyanis bőven előfordulhat, hogy egy kamerától messze található objektumot találnak el. Mivel a LOD szintet a sugár kilövésekor kell meghatározni, keletkezik egy kvázi megoldhatatlan probléma. Ha egy közeli objektumon lesz találat, akkor az a jó, ha a maximális LOD szint van betöltve, de ilyenkor ez érvényes a távoli objektumokra is. Utóbbi esetben inkább valami alacsony LOD szint lenne az ideális, de akkor meg a közeli objektumok lesznek nagyon rondák például egy visszaverődés effektnél. A jelenlegi szabványos rendszerben tehát távolra kilőtt sugarak mellett egy effekt vagy ronda lesz, vagy nagyon memóriazabáló. Köztes alternatívát egyszerűen még nem tud kezelni egyik API sem, és ez az oka annak, amiért a mai játékok döntő többsége nagyon korlátozott távolságig számolja a sugárkövetést.
Vannak azonban szituációk, ahol a korlátok elfogadása nem alternatíva. Ilyen cím például a PlayStation 5-re megjelent Spider-Man: Miles Morales, amelynél bizony nagyon fontos, hogy igen távoli objektumok is visszatükröződjenek az épületek üvegfelületein. Persze lehet mondani, hogy nem minden játékban mászik meg felhőkarcolókat a főhős, de létezik olyan helyzet, ahol a távolra kilőtt sugaraktól szép eredmény kellene alacsony memóriaigény mellett. Itt jön képbe a programozható bejárás, amit a Sony konzolján alkalmaznak, és ennek segítségével a LOD szint nem kötött, vagyis a sugár kilövése után is megváltoztatható. Ennek az előnye, hogy a távoli objektumok részletessége visszavehető, azok a visszatükröződés során is nagyon kevés pixelt fognak lefedni, tehát szükségtelen a sok memóriát igénylő, teljes részletességű modellt betölteni. Ilyen formában a kecske is jóllakik, és káposzta is megmarad, vagyis effektíve alacsony memóriahasználattal is megvalósítható a jó minőség.
Kérdés az, hogy ez miért nem szabványos már a DirectX 12 és a Vulkan API-n belül. Gondolni lehet arra, hogy kevés hardver támogatja, de valójában ez nem igaz. Akármelyik ma elérhető, sugárkövetést hardveresen biztosító GPU kompatibilis a programozható bejárással, vagyis az NVIDIA Turing és Ampere, illetve az AMD RDNA 2 architektúrák megfelelnek az elméleti követelményeknek. A gyakorlatban is csak annyi történik, hogy a bejárás a multiprocesszorokon lesz végrehajtva, ehhez egyszerűen csak a meghajtókat kellene módosítani, vagyis egy teljesen szoftveres tényezőről van szó. A problémát az adhatja, hogy programozható bejárás mellett az NVIDIA hardvereibe épített, bejárásra szabott fixfunkciós blokk semmit sem fog érni, olyan mintha ott se lenne, mert nem tudja elvégezni a feladatát a bedrótozott kód hiányában. Az AMD például ezt a feldolgozót alapból kihagyta az RDNA 2-ből, mert a Microsoft és a Sony alapvető igénye volt a programozhatóság, azt pedig fixfunkciós blokkal nem lehet megoldani.
Emiatt állhat úgy a helyzet, hogy PC-n egyelőre szabványos formában nincs programozható bejárás, és ez lehet a vezető oka annak is, amiért az AMD-t nem érdekli a szabvány, megcsinálják maguknak a specifikus támogatást. Ez DirectX 12-re már elérhető, Vulkan API-ra pedig jön.
Sajnos pont ez a széthúzás fog majd eléggé betenni a PC-n a sugárkövetésnek, mert addig jó a helyzet, amíg szabványos van megoldva az effekt a játék PC-s portján belül, de mi van akkor, ha nem? Van is erre példa, hiszen a Godfall első körben csak gyártóspecifikus módon implementálta a sugárkövetést, pont a fentebb már említett, extrém memóriaigényből eredő probléma miatt, hiszen a legtöbb játéktól eltérő módon nagyon messzire lövi a sugarakat.
A megoldás az lenne, ha a Microsoft és a Khronos Group a lehető leggyorsabban biztosítaná a programozható bejárást a szabványos specifikáció részeként. Magát a problémát nem nehéz megoldani, mert lényegében csak arról van szó, hogy egy compute shader kezelésére felkészítik a bejárási lépcsőt. Ehhez minden megvan már most is a DirectX 12 és a Vulkan API-ban, nem véletlenül tudja az AMD olyan könnyedén kiegészíteni a szabványos futószalagot. Semmi varázslatot nem csinálnak, ez lényegében ugyanilyen könnyen menne a Microsoft és a Khronos Group számára is, és onnantól kezdve gyártófüggetlenül meglenne ez a képesség. Mindez a játékosok oldalán is sok bizonytalanságot kezelne, hiszen szabványos rendszer mellett nem kellene attól félni, hogy esetleg pont pár jobban várt címben lesz AMD-specifikus sugárkövetést, amely tényező azért egyáltalán nem tesz jót a piacnak. PC-s szinte a legfontosabb a szabványosság, és ha pont programozható bejárásra van igény, akkor azt kell szabványosítani, pláne úgy, hogy új hardvereket ez egyáltalán nem igényel.
