A memóriapánik közepette egyre világosabb, hogy a VGA-piac idén mindenképpen változik, ugyanis egyre több hír szól arról, hogy a 8 GB-os VGA-k kerülhetnek többségbe. Emiatt felmerül a kérdés, hogy reálisan bele lehet-e férni ebbe a tárkapacitásba, amit röviden elemezni is lehet, így most meg is tesszük.
Ha leszámítjuk a grafikus megjelenítéshez mindenképpen szükséges számításokat, akkor valójában három dolog számít kifejezetten memóriagyilkosnak. Az egyik a sugárkövetés, a másik bármilyen neurális eljárás, a harmadik pedig a compute-alapú tartalomdekódolás.
Technikailag persze raszterizálás mellett is lehet olyan tartalmakat használni, aminek kevés a 8 GB-nyi VRAM, és ez főleg a textúrák minőségét határozza meg, de megfelelő streaminggel, optimálisan belőtt textúrarészletességet feltételezve mindig elérhető az a szint, aminek elég a 8 GB-nyi VRAM. És ez nagyon fontos tényező, mert amíg a sugárkövetésnek, a neurális eljárásoknak, illetve a compute-alapú tartalomdekódolásnak van egy fix, mondhatni nagyobb memóriaigénye, függetlenül a kapott minőségtől, a textúrarészletesség és a kapcsolódó streaming nagyon jól skálázható a memóriára vonatkozó terhelés szempontjából.
Erre nagyon jó példa a Battlefield 6, amely Full HD-ben, minimális grafikai részletesség mellett nagyjából 5,5 GB-nyi VRAM-ot igényel, maximumra tekert paraméterezéssel pedig 13 GB-ot. És ezt nagyrészt a textúrarészletesség befolyásolja, tehát pusztán ennek az egy tényezőnek az optimalizálásával könnyen célozható a 8 GB-os határ. Ezzel szemben, ha lenne sugárkövetéses effekt a játékban, akkor az fixen igényelne úgy 1,5-2 GB-nyi extra helyet, méghozzá az elérhető minőségi szinttől függetlenül.
A neurális eljárások, gondolva itt az FSR, DLSS és XeSS trióra, az említett címben úgy 0,5 GB-ot kérnek modulonként, tehát ha egyszerre aktív a felskálázó és a képgeneráló, akkor az azokhoz tartozó neuronháló összesen közel 1 GB-ot foglal le a VRAM-ból.
A DirectStorage, mint compute-alapú tartalomdekódolás már kellemesebb ügy, mivel egy játék úgy is használhatja az említett technikát, hogy a tartalomdekódolást a processzormagokra kényszeríti. Ilyen formában nagyon sok cím alkalmazza már, és ebben a módban nem terheli a VRAM-ot a működése, mivel a munkamenet főleg a rendszermemóriára van negatív hatással. Ha viszont ténylegesen compute-alapú tartalomdekódolás mellett futna egy program, akkor a DirectStorage tipikus VRAM-terhelése 1-2 GB közötti szokott lenni.
Összességében elmondható, hogy ha a manapság tipikus új dolgokat kivesszük a képletből (értjük ezalatt a DirectX Ray Tracinget, a felskálázókat, a képgenerálókat, illetve a DirectStorage GPU-s dekódolását), akkor ezek nélkül minimum 3 GB-ot lehet spórolni úgy, hogy olyan dolgokról mondunk le, amelyek nem szükségesek az alapvető képszámításhoz.
Na de mi van akkor, ha ezekről nem szeretnénk lemondani? Nos, az már egy kényelmetlenebb helyzet, de nem lehetetlen valami megoldást találni. A DirectStorage GPU-s dekódolása például önmagában nem egy vagy-vagy technika. Lehet azt csinálni, hogy bizonyos tartalmakat a CPU, másokat pedig a GPU kódoljon ki. A szabály az, hogy erről a fejlesztőnek előre döntenie kell, tehát fontos ismerni, hogy az adott játékhoz mi az optimális választás. Mi lehet itt egy értékelhető középút? A nagyobb méretű, nem azonnal szükséges tartalmaktól érdemes tehermentesíteni a rendszert, így ezeket hasznosabb a GPU-ra küldeni a dekódolás szempontjából, míg a kisebb és többször vagy gyorsabban igényelt tartalmakat a CPU-magok is megoldhatják. Ez persze nem univerzális minta, de jó kiindulási pont, hogy végeredményben a lehető legjobban, a VRAM kímélését figyelembe véve legyen kihasználva a DirectStorage.
A felskálázás és a képgenerálás tekintetében nem sokat lehet tenni, hacsak nem számítjuk bele a képletbe azt, hogy ezekhez nem szükséges neuronháló, azaz analitikai módszerrel is megoldható a két technika, amelyek sokkal jobban kímélik a VRAM-ot.
A sötét ló a sugárkövetés, és ezzel gyakorlatilag a DirectX 12 és a Vulkan API-kon belül nehéz mit kezdeni, mert a fejlesztők nem férnek hozzá az alkalmazott BVH adatstruktúra-formátumhoz. Éppen ezért semmilyen valós optimalizálásra nincs lehetőségük, azon kívül, hogy meghatározhatják a sugarak mennyiségét és hosszát. Ez egy tipikus feketedoboz kívülről nézve, ami elvégzi a dolgát, de hogy hol lehetne rajta úgy javítani, hogy csökkentse a VRAM-igényt, vagy javítsa a sebességet, az el van rejtve a fejlesztők szemei elől.
Ezt a stúdiók vagy elfogadják, vagy nem, viszont fontos, hogy utóbbi esetben kétféle módon kezelhetik. Az egyik a Battlefield 6 rendkívül innovatív módszere: ha nem lehet optimalizálni, akkor nem is hasznos a sugárkövetés. Ez helyből megoldja a gondot, mivel többet nem terheli a VRAM-ot. A másik módszer kevésbé drasztikus, és megpróbálja megkerülni az alapvető problémát a technika szoftveres irányból való megközelítésével. Utóbbi esetben a fejlesztők szándékosan nem nyúlnak hozzá a zárt BVH adatstruktúra-formátumhoz, és helyette alkalmaznak egy olyan alternatívát, amelyet már teljesen látnak, és ilyen formában optimalizálhatják a működését is. Ilyen módszer például az Unreal Engine 5 Lumen eljárása, vagy az Ubisoft-féle gyári sugárkövetés a Snowdrop 2.0-s videojáték-motort használó játékokban.
Összességében, a jelenlegi tapasztalataink alapján problémásnak tűnnek a 8 GB-os VGA-k az idei évre, de valójában nem annyira nagy a baj, mert nagyon jó módszerek vannak arra, amivel elég lehet ennyi VRAM a tipikus Full HD-s igényekre, vagy akár WQHD-re is. Minden csak azon múlik, hogy a programozók milyen döntéseket hoznak, és a sugárkövetésre vonatkozó példán látszik, hogy az egyáltalán nem segít, ha maga az API nem teszi lehetővé az optimalizálást. És itt nagyon extrémnek tűnik a Battlefield 6 fejlesztőinek döntése, de abszolút védhető, hogy ha valamit nem lehet optimalizálni, akkor arra épülő kódot nem érdemes a végfelhasználóknak szállítani. Az ilyen problémás tényezőkből adódik össze az, hogy irreálisan nagy lett manapság a játékok VRAM-igénye, ebből viszont van visszaút. Ki tudja, még jól is járhat az ipar a memóriapánikkal, mivel újra lehet gondolni, hogy milyen eljárásokat érdemes az újabb címekben szállítani.
