Az AMD még az elmúlt év nyarán beszélt a Vega architektúra egyik lényeges újításáról, ami az NGG, vagyis a next-generation geometry mód. Ennek egy új shader lépcső, a primitive shader képzi az alapját, a lényegéről pedig már a Radeon RX Vega 64-et bemutató cikkünkben beszámoltunk, így ezt nem ismételnénk meg újra. Arra azonban kitérnénk, hogy eredetileg a vállalat az az NGG módot a meghajtóból akarta kényszeríteni a játékokra, így a fejlesztők által írt szabványos vertex, domain és geometry shadereket a shader fordító szimplán a primitive shader lépcsőbe fordította volna. Ezzel elméletben radikálisan növelhető a nem látható primitívek kivágásának hatékonysága, mivel primitive shader lépcső igen korai szakaszban megmondta volna ezekről, hogy nem látszanak, így felesleges rájuk erőforrást pazarolni a futószalag további pontjain. Főleg akkor ha eljutnak a raszterizálásig, ami a hardverre nagy terhelést ró, miközben látható eredménye a készülő képen nem lesz.
A pazarlás sajnos ma általánosan a rendszer része, mivel a vertex shader lépcső alapvetően az előző évtized problémáinak megoldására készült, míg a domain, valamint a geometry shader csak kiegészítette a mára elavult futószalagot. A hardverek tehát az erőforrásaik egy jelentősnek mondható részét nem látható dolgot számítására költik, ami egyértelműen egy probléma, a primitive shader pedig megpróbálná ezt egyszerű módon felszámolni.
A meghajtóoldali, amolyan kényszerített implementáció viszont úgy néz ki, hogy nem igazán fog működni. Erre vonatkozóan több utalás is volt az elmúlt időszakban. Többek között az is, hogy az NGG mód teljes egészében nem került aktiválásra a legutóbbi meghajtókban. Egyedül az IWD (intelligent workload distributor) működik belőle, viszont ez már a kezdetekben is be volt kapcsolva, persze az újabb eszközillesztőkkel kapott optimalizálásokat is, így javult a hatékonysága.
A CES-en az AMD egy zárt előadáson állítólag részletezte, hogy milyen képességei aktívak a Vega meghajtónak. Ezen sajnos csak nagyon kevesen vehettek részt, de úgy tudjuk, hogy előkerült a DSBR mód, ami már számos játékra működik. Az összesre nem lesz aktiválva, mert a mozaikos feldolgozás ronthatja a shaderek feldolgozásának hatékonyságát, így csak akkor éri meg alkalmazni, ha az adott program teljesítményét a memória-sávszélesség limitálja, vagy már magát az alkalmazást úgy optimalizálták, hogy az erősen mozaikos leképezésre építő hardveres módokhoz igazodjon, elkerülve ezzel a számítási teljesítmény visszaesését.
Ami igazán lényeges adat, hogy az előadáson biztosan nem volt szó a primitive shader hackelt, driverben erőltetett implementálásáról. Ennek a negatív oldala, hogy a vállalat eredetileg nem is gondolkodott alternatív megközelítésen, vagyis gyakorlatilag egy fejlesztők számára transzparenst megoldást akartak biztosítani. Persze okkal, mivel dedikált, vagyis direkten kihasználható megoldást eléggé nehéz az elterjedt szabványos API-kba beépíteni, elvégre a primitive shader megváltoztatja a szabványban rögzített grafikus futószalagot. Ez nem lehetetlen feladat, de nagyon komoly megkötéseket fogalmaz meg a Microsoft és a Khronos Group is, ugyanis maga az API működése változna meg jelentősen.
Manapság persze az AMD nagyon erőlteti a nem szabványos shadereket a DirectX 11 és 12, illetve a Vulkan API-kban. Erre utóbbi esetben kiterjesztéseket használnak már magához a SPIR-V-hez is, az előbbi két platformon pedig az AGS szervizkönyvtár új verziói biztosítják a különböző kiegészítéseket, ezzel pedig a hozzáférést az intrinsics függvényekhez. Ezekre a lehetőségekre manapság viszonylag sok játék épít, kiemelve az újabb Frostbite, id tech 6 és 6.5, Asura, Dawn Engine, RE Engine és Glacier 2 videojáték-motorokat használó címeket. Tehát önmagában a fejlesztőknek nincs bajuk a kiterjesztésekkel, leszállítják a nem szabványos kódokból fordított szintén nem szabványos IR-t az AMD hardvereire. Viszont intrinsics függvényekkel sokkal egyszerűbb kiegészíteni az API-kat, mert ez nem változtat a futószalagon.
Technikailag persze a primitive shaderre vonatkozó kiegészítések sem lehetetlenek, hiszen az AMD-nek ott van a Mantle API, abban akármilyen futószalagot kialakíthatnak, majd API interoperabilitással ezt meg is hívhatják, tehát végeredményben kreálható egy megfelelő szervizkönyvtár. Az interoperabilitás pedig az elterjedt API-kra (DirectX 11 és 12, illetve Vulkan) eleve ki van építve, hiszen a LiquidVR latest data latch funkciója egy olyan egyedi képesség, ami nem üzemképes a Mantle nélkül. Mégis kedvezőbb lehet megvizsgálni azokat a lehetőségeket, amelyek az AMD saját API-ja nélkül is lehetővé tennék az új lehetőségeket. A Vulkan valószínűleg ezt megengedi, de számos kiterjesztés kell hozzá. A Microsoft egy kicsit erősebben fogja a gyeplőt, így a DirectX 11 és 12 alatt nem biztos, hogy a Mantle megkerülhető.
Jó hír egyébként, hogy az iparág erősen megy a primitívek GPGPU-s kivágása felé, ez például opcionálisan bekapcsolható a Wolfenstein 2: The New Colossus című játékban, ami a hatásfokát tekintve valószínűleg felér a teljes értékű NGG módhoz. Rapid packet math és aszinkron compute alkalmazása mellett talán jobb is nála, és az NGG móddal ellentétben szabványos. Persze kétségtelen tény, hogy számos compute shadert kell hozzá megírni, ami nem kevés munka. A szabványosság viszont megér ennyit, főleg úgy, hogy a konzolokon is működik.
Az új játékok tehát elkezdték kezelni magát az alapproblémát. Persze a megoldás nem olyan elegáns, mint a primitive shader, elvégre a rossz hatásfokot biztosító futószalaglépcsők megmaradnak, de ezek előtt már dolgozik a compute shader, hogy lehetőleg csak olyan primitíveket kapjanak, amelyeknek biztos lesz látható eredménye. Ez is számíthatott a meghajtóba tervezet hack leállításánál, elvégre ennek csak a régi játékokban lett volna hatása, de mondjuk egy Wolfenstein 2: The New Colossus esetében már nem ért volna szinte semmit. Talán nem árulunk el nagy titkot azzal sem, hogy a következő nagy PC-s címnek számító Far Cry 5, új verziójú Dunia motorja is hasonló rendszert használ, bár erről az AMD és az Ubisoft nem beszél nyíltan, legalábbis az idei GDC előtt.
A fentiek alapján felmerülhet az a kérdés, hogy ha egy szabványos compute megvalósítással is hozható a teljes NGG mód hatásfoka, akkor mi szükség van a primitive shaderre. Erre viszont egyszerű válaszolni. Az NGG mód azért kapott kiemelt figyelmet a Vega esetében, mert ezt lehetett volna egy driverbe épített hackkel megoldani. Maga a primitive shader azonban többre is képes, olyan dolgokra, amelyeket normális sebességgel csak ezzel az új shader lépcsővel lehet megoldani. Ilyen például a teljes jelenetre vonatkozó gráffeldolgozás és -bejárás, illetve az egyéb jelenetszinten magukkal az objektumokkal dolgozó eljárások. Ehhez azonban eleve nem lett volna jó a meghajtóba épített hack, mivel a primitive shadernek ilyen egyedi módon történő használata mindenképpen direkt elérést igényel. A fenti döntéssel a szükséges szervizkönyvtár vagy kiterjesztés biztosítása felgyorsulhat, ami megindíthatja ezeket az egyedi felhasználásra vonatkozó kutatásokat is. Sőt, a PlayStation 4 Pro konzolban elérhető, superstencilt használó effektek is átmenthetők lehetnek.
