Az AMD korábban is számos dologgal próbálta segíteni az olyan explicit API-k használatát, mint például a DirectX 12-re és a Vulkan. A cég jó ideje biztosítja már a VMA (Vulkan Memory Allocator) és a D3D12MA (DirectX 12 Memory Allocator) nevű függvénykönyvtárakat, amelyek által a programozók egy előre megírt, általánosnak mondható implementációt kapnak a memória menedzsmentjéhez. Ráadásul ezeket manapság nagyon sok játék használja már, hiszen könnyebb hozzájuk nyúlni, és a nyílt forráskódnak hála esetleg célirányosan optimalizálni, mint a nulláról felépíteni egy saját megoldást.
Van azonban az explicit API-knak egy másik tipikus gondja is, ugyanis nem csak a memóriamenedzsment került a programozók kezébe, hanem a különböző függőségek követése, illetve a szinkronizálás is. Ez egyrészt jó, főleg a közvetlenebbül elérhető hardver miatt olyan gyors a DirectX 12 és a Vulkan API, de komoly feladatot ró a rendszer működése a programozókra, ugyanis ilyen formában a teljesítményt is nagymértékben meghatározza megírt a programkód.
[+]
Az már az elején kiderült, hogy nem egy egyszerűen kezelhető problémáról van szó, így született is egy jellemzően használt megoldás a különböző erőforrás-kezelési, függőségkezelési, illetve erőforrás-korlátozással kapcsolatos munkafolyamatok hatékonyabb menedzseléséhez, amely leképezőgráfok néven volt emlegetve. A lényege ennek annyi, hogy a teljes képkocka, illetve az egyes átmenetek, konkrétabban node-ok közötti függőségek áttekintésével hatékonyabban lehet menedzselni magát a problémát a videojáték-motor oldaláról. Ez eddig rendben is van, de egy ilyen konstrukciót nem egyszerű a nulláról felépíteni, az optimális teljesítmény elérése viszonylag sok munkaórát igényel, illetve az esetlegesen eltérő leképezőgráf-rendszerek között is portolni kell az alkalmazott effekteket és eljárásokat. Mindez sok kisebb stúdiót tarthat távol az explicit API-któl, de még a nagyobb cégek is komoly anyagi és humánerőforrásokat ölhetnek bele a megfelel rendszer kialakításába.
Bár nem mindig szerencsés emlegetni, de az egyik legjobb mérőszáma a bonyolultságnak az első háromszögig vezető kódsorok száma, ami azt prezentálja, hogy mennyi kódot kell beírni ahhoz, hogy az adott API megjelenítsen egy háromszöget. Ebből a szempontból a DirectX 12 és a Vulkan jelentős hátrányban van a korábbi, nem explicit API-khoz viszonyítva, ugyanis pusztán a működéshez szükséges programoldali konfiguráció jelentős mennyiségű kódsor meglétét igényli, elvégre az explicit API-k esetében már nincs grafikus kernel meghajtó, ami a programozó számára láthatatlanul végezné a dolgát. És ezt nem szabad rossz értelemben felfogni, mert pont az volt a fejlesztések célja, hogy ez a tényező ne is legyen többet, mert itt veszett oda a sebesség, illetve a skálázhatóság, de a grafikus kernel meghajtó feladata az új API-kkal a programozóra hárul, ami több ezer sornyi konfigurációs kódot eredményezhet.
A helyzet tehát az, hogy a DirectX 12 és a Vulkan megoldotta a teljesítménnyel kapcsolatos gondokat, de annak az árán, hogy az említett explicit API-k használata bonyolultabb lett, és ezzel nagyon nehéz megbirkózni. Ráadásul nem is a programkód nyers mennyisége a gond, hanem az, hogy ha beír valaki például több ezer sornyi konfigurációs kódot, akkor biztos jól fog-e működni? Meddig kell azt optimalizálni, hogy elérhető legyen a kitűzött sebesség?
[+]
Az AMD most hozott egy garantáltan jó teljesítményt biztosító, költségkímélő megoldást a problémára. Konkrétan az RPS, azaz Render Pipeline Shaders fejlesztőkörnyezetükről van szó, ami pont a leképezőgráf-rendszerek egyszerűbb kialakítását teszi lehetővé. A cél az, hogy a videojáték-motorok programozói magukra a leképező futószalagokra koncentráljanak, és az explicit API-kkal járó konfigurálási feladatokat pedig nagyrészt elvégzi az AMD keretrendszere, amely teljesen dinamikus leképezőgráfokat alakít ki az alkalmazás által megadott változókból. Ennek a módszernek ugyanakkor van némi extra többletterhelése a processzorra nézve, de a cég szerint ez elhanyagolható, illetve végeredményben többet ér, ha magán a GPU-n jobban fut az RPS-sel kialakított kód, mintha egy manuálisan nem jól konfigurált rendszer kevésbé hatékonyan működne.
A fentiekkel azért felmerülhet az a kérdés, hogy egy ilyen lépéssel nem megyünk-e vissza a hagyományos API-k limitációi felé, amelyekről pont elmenekültünk az explicit API-kkal. Az AMD szerint nem, mert az RPS keretrendszert alkalmazva maga a kontrollálhatóság megmarad, tehát az explicit API-k értelme nem veszik el, csak a fejlesztőnek sokkal kevesebb kódsort kell beírni, miközben nem kell aggódnia azon, hogy nem jön a teljesítmény.
Az AMD számos már elérhető, explicit API-t használó játék alapján a gyakorlati hatást is lemérte. Bár azt lehetne gondolni, hogy az RPS keretrendszer általánosabb jellege miatt általánosan némi sebességvesztés lesz az ára az alkalmazásának, meglepő módon nem ez történik. A vállalat 50 darab játékban ellenőrizte a működést, és az eredeti kód mindig több erőforrás-korlátozást alkalmazott, mint az RPS keretrendszerrel dolgozó, úgynevezett MinBarrier stratégia. Ez azért lényeges adat, mert az explicit API-k nyers teljesítménye nagyrészt attól függ, hogy a kiadott API hívásoknak minél kevesebb része legyen erőforrás-korlátozás, vagyis elméletben minél kevesebb van az utóbbi API hívásból, annál kevesebbszer alakulnak ki olyan üresjárati munkafolyamatok, amelyek akadályozzák a feldolgozás sebességét.
[+]
Mindez ráadásul a gyakorlati oldalon is lefordítható előnyre, ugyanis a vállalat 58 darab, explicit API-n futó játékot lemért egy Radeon RX 7900 XTX VGA-val, és mindössze négy címben volt gyorsabb az eredeti, manuális konfiguráció. Ez az AMD szerint több tényezővel magyarázható, és a felmerült jelenségek egy részén dolgoznak, így az RPS keretrendszer egy későbbi verziója ezekben a szituációkban jobban működhet majd. Fontos ugyanakkor, hogy 54 alkalmazásban a RPS-sel támogatott működés volt a gyorsabb, ráadásul hét esetben 5%-nál nagyobb volt az előrelépés, egy esetben pedig meghaladta a 25%-ot is. Utóbbi rávilágít arra, hogy maga a manuális konfiguráció lehet igencsak rossz hatékonyságú is, és ez jelentős teljesítményvesztést okoz az adott alkalmazáson belül. Ergo, ha az érintett játékba implementálnák az RPS-t, akkor az hozzávetőleg negyedével gyorsabban futna szinte minden hardveren.
[+]
A memóriahalmazokkal kapcsolatos töredezettség szempontjából is lényeges előnyöket biztosíthat az RPS keretrendszer, ráadásul a MinBarrier mellett van egy opcionálisan kérhető MinMemory stratégiája is a rendszernek, ami kifejezetten a VRAM terhelésének csökkentését célozza. Ezzel a problémával egyébként viszonylag sok, explicit API-t használó játék nem is nagyon törődik, mivel maga az optimális konfiguráció kialakítása olyan elképesztően bonyolult, hogy jellemzően nem fér bele a fejlesztési időbe. Az RPS keretrendszer viszont ezt a képességet is egyszerűen lehívható módon kínálja, és garantáltan csökkenti a memóriafelhasználást, miközben ennek a többletterhelése a processzor oldalán elhanyagolható.
Ki kell még emelni azt is, hogy az egész csomag gyártófüggetlen, tehát a kódok teljesen szabványosak, így minden olyan hardveren futnak, amelyhez van DirectX 12, illetve Vulkan implementáció. Maga az RPS, azaz Render Pipeline Shaders fejlesztőkörnyezet az alábbi GitHub oldalon érhető el, és a konstrukció egyelőre nyílt béta fázisban van. Az AMD a rendszerrel kapcsolatban várja a fejlesztői visszajelzéseket.
