Miért kell a megatextúrázás?
A DirectX 11.2 előzeteséről nemrég írtunk egy hírt, viszont a Tiled Resources funkció amellett, hogy örömteli újítást vezet be, sok kérdést is felvet; hiszen opcionálisan támogatható, vagyis bizonyos értelemben nem része a DirectX szabvány követelményeinek. Azt kell mondanunk, hogy a vásárlók szempontjából ezek az opcionális funkciók a legkedvezőtlenebbek, hiszen nagyon mélyen bele kell ásniuk magukat, hogy melyik hardver mit támogat, amit a többség eleve nem fog megtenni, de még ha érdekli is a potenciális vevőt, akkor is komoly szaktudás kell ahhoz, hogy a Microsoft, illetve az adott gyártó leírását értelmezze.
A korábbi cikkünkben az opcionálisan támogatható DirectX funkciókat annyira leegyszerűsítettük, amennyire csak lehet, így a linkelt oldalon a táblázat már jól értelmezhető a felhasználók számára. A Tiled Resources funkció ennél bonyolultabb, így ezt jóval nehezebb egy táblázattal elintézni, viszont nagyon fontos technikáról van szó, hiszen ennek használata meghatározó lesz a jövőben. A Tiled Resources beépítését is konkrétan a fejlesztők kérték, hiszen az új generációs konzolokban használt AMD GCN architektúra kínál egy Partially Resident Textures (PRT) eljárást a megatextúrázásra, amit nyilván mindenki szeretne kihasználni. Kell tehát egy átfogó implementáció a grafikus API-kba, de gondot jelent, hogy az elérhető hardverek szempontjából nem megoldható az egységes megoldás. Éppen ezért a Tiled Resources funkció két eltérő szinten lett implementálva egy szoftveres opció lehetősége mellett.
Mielőtt a különböző szinteket megnéznénk, fontos lenne tisztázni, hogy miért van szükség egyáltalán a Tiled Resources funkcióra, illetve magára a megatextúrázásra. Utóbbi a Rage című játékban szoftveresen volt implementálva, így túl jó benyomást nem tett a játékosokra. A megatextúrázás ötlete viszont zseniális és úttörő, így az új generációs grafikus motorokban szinte biztos, hogy helyet kap. A legfontosabb meglátni azt a tényt, hogy a játékok mérete extrém módon növekszik, és ezen belül is az adott program helyigényének 50-70%-át a textúrák teszik ki. Tulajdonképpen ez egy logikus fejlődési irány, hiszen a jó minőségű és éles textúrák alapvetően határozzák meg a játék grafikai megjelenését, továbbá a játékos is minőségi tartalmat szeretne látni a virtuális világ felületein. A textúrákat viszont be kell tölteni a memóriába, és ha a mai alkalmazások mellett figyelembe vesszük, hogy 5-10 GB-nyi adatról lehet szó, akkor könnyen kitalálható, hogy képtelenség ennyi információt a memóriában tárolni. Ez a probléma alapvetően nem új, lassan tíz éve elértük azt a szintet, hogy az összes textúrát egyszerűen nem lehet betölteni a VRAM-ba, így jöttek is a lehetséges megoldások a gondra.
Mára széleskörűen alkalmazott technika lett a textúrák streamelése, vagyis az adott játék motorja igyekszik úgy hasznosítani a memóriát, hogy csak az adott képkocka számításához szükséges textúrák legyenek benne, a többi pedig lényegében nem érdekes. Az ötlet kiváló, hiszen pont arra van szükség, hogy a felesleges adatokat ne kelljen tárolni a VRAM-ban. A streamelésre különböző algoritmusok születtek, melyek között természetesen voltak kevésbé jól működő alternatívák is, de manapság elmondható, hogy az elmúlt évek tapasztalatai alapján a fejlesztők igen jó implementációkat tesznek le az asztalra. Ugyanakkora a textúrák streamelése sem teljesen átfogó megoldás az alapproblémára, hiszen a PCI Express összeköttetés sebessége viszonylag lassú fejlődést mutat, amellett sűrűn keletkezik olyan igény is a programon belül, hogy egy adott textúrának csak egy apró részletére van szükség, de ehhez a teljes textúrát be kell tölteni, ami a memória pazarlásához vezet.
Nem elhanyagolható az az irányzat sem, hogy a mai játékok többségének motorja igen memóriaigényes deferred leképzőt használ, vagyis a textúrák számára biztosítható hely esetenként igen szűkös. Példának okáért a Battlefield 3-ban egy Full HD-s képkocka kiszámítása négymintás MSAA mellett valamivel több mint fél gigabájt memóriát igényel, és ezt csak a számításhoz szükséges render targetek és egyéb pufferek teszik ki. A manapság kedvelt többmonitoros rendszerek esetén, három kijelzővel már 1,5 GB helyigény is keletkezik, megegyező monitoronkénti felbontás mellett, míg 4K felbontáson a VGA-k többségéhez társított 2 GB VRAM-ba egyszerűen a négymintás MSAA-val megtámogatott képkocka számításához szükséges információk szimplán be sem férnek, és akkor még a textúrák nem is kerültek szóba. Persze ez a Frostbite 2/3 motor jellegzetessége, így felhozható ennek a gyökeres ellentéte is, a CodeMasters, forward leképzőt használó EGO motorja kapcsán, ami 1 GB VRAM-mal lényegében bármilyen igény mellett elvan. Sőt, az átlagos felbontások esetén még fél gigabájt memóriával is beéri textúrástól, mindenestül.
Extrém részletességű megatextúra a virágon [+]
Látható, hogy bizonyos leképzők használatával a textúrák streamelése sem kedvező, de évek óta vannak kutatások a következő lépcsőnek tekinthető megatextúrázás irányában. Ennek az elgondolásnak a koncepciója minden, textúrázással kapcsolatos problémát felszámolni. Ha belegondolunk az egész képszámítás lényegébe, akkor tulajdonképpen nincs is szüksége a motornak a textúrák minden egyes texeljére. Gyakorlatilag csak azok a texelek kellenek, amelyek segítségével történik a pixelek számítása. Ez Full HD felbontáson gyakorlatilag igen csekély, 100 MB-nál is kevesebb adatot jelent. A megatextúrázás tehát nem tesz mást, mint az adott megatextúrából – melynek mérete akár több terabájt is lehet – kiválasztja azokat az úgynevezett mozaikokat (textúraszeleteket), amelyek texeljeire szükség van az adott képkocka számításához, és ezt a – felbontástól függően – közel száz vagy párszáz megabájtos adatmennyiséget elhelyezi a VRAM-ban. A memóriaigény szempontjából ez a textúrázás leghatékonyabb formája, és a fejlesztők is lehetőséget kapnak a textúra részletességének igen extrém javítására, hiszen a megatextúrázás mellett tulajdonképpen nem számít a textúra tényleges mérete. Ez maximum a HDD-n vagy az SSD-n tárolandó adatmennyiség szempontjából lehet probléma, viszont egy nagy megatextúrával akár egy hajszálrepedés is reprezentálható egy kés nyelén, miközben ez a számítások és a memóriaigény szempontjából abszolút nem jelent extra terhelést. Persze ilyen bizonyosan nem lesz, hiszen egy hajszálrepedésre ki lenne kíváncsi egy játékban, de a példa jól szemlélteti a lehetőségeket.
Hogyan működik a megatextúrázás?
A megatextúrázást jelenleg csak szoftveres formában csodálhattuk meg, ami azért komoly problémáktól is küzdött. A működési elv alapvetően annyi, hogy a megatextúrát szeletekre, illetve szakszóval mozaikokra kell osztani, így ahelyett, hogy az egészet betöltenénk a VRAM-ba, lényegében csak annak részeit hasznosítjuk. Ehhez szükség van egy úgynevezett lookup textúrára, ami nem tartalmaz színinformációt, viszont olyan metaadatokat tárol, amelyekkel meghatározható, hogy a tényleges textúráról milyen adatokra van szükség a leképzéshez. A program tehát a lookup textúrán jelöli ki, hogy mire van szüksége, majd a megadott koordináták alapján a rendszer kikeresi a valós textúrán az igényelt információkat, és ezek egy pixel shaderrel betölthetők a VRAM-ba. Ez egy rendkívül összefüggéstelen fizikai textúra lesz a végén, de a program tudni fogja, hogy az adott pixel színinformációinak számításához mely texelekre van szükség.
Szoftveres megatextúrázás [+]
A szoftveres megatextúrázás alapvető hátránya, hogy tulajdonképpen mindent szoftverből kell megoldani. Implementálni kell a támogatott formátumokat és textúratípusokat, az anizotropikus szűrést szoftveres formában is segíteni kell, ami már négyszeres opcióval is nagyon sok sebességvesztést jelent, illetve komoly gond, hogy a textúrából az adatok betöltése két egymástól függő utasítással lehetséges, hiszen előbb szükség van a lookup textúráról az információra, és csak utána lehet a konkrét adatot betölteni. Ez tulajdonképpen csupa hátrány a szoftveres megatextúrázás esetében, amit mindenképp kezelni kell, hiszen maga az alapelv úttörő koncepcióra épül.
A hardveres megatextúrázás eltünteti a fenti hátrányokat. Alapjaiban úgy működik, ahogy a szoftveres opció, de nincs lookup textúra, mert ennek helyét átveszi a hardveres laptábla. Innen már sejthető, hogy ehhez a funkcióhoz MMU-val (memóriakezelő egység) rendelkező grafikus processzorok szükségesek. A szűrés teljesen hardveres lehet, aminek hála nem drágább a megszokottnál az anizotropikus szűrés használata, illetve nincs szükség két egymástól függő adatbetöltésre, mert a lookup textúrát kiváltó laptábla elérése úgymond ingyenes. Emellett a hardver által támogatott összes formátum és textúratípus kezelhető, vagyis nincs szükség ezek szoftveres implementálására.
Hardveres megatextúrázás [+]
A hardveres megatextúrázás eddig csak OpenGL alól volt megoldható, méghozzá a GL_AMD_sparse_texture kiterjesztés használatával, de ezt csak a GCN architektúrára épülő AMD Radeon termékek támogatják. Ennek butított verziója az opcionálisan támogatható GL_ARB_sparse_texture kiterjesztés, ami már a többi hardveren is üzemképes.
A Microsoft is saját megoldást dolgozott ki a DirectX új verziójába, hiszen nagyon fontos funkcióról van szó. A Tiled Resources még mindig opcionális megoldás, tehát a támogatása nem kötelező a gyártóknak. Nyilván egyik fejlesztő sem szereti a nem egységesen kezelt funkciókat, de a Microsoft keze is meg van kötve, hiszen a fejlesztői igény az új konzolok érkezésével óriási lett a megatextúrázásra, eközben viszont túl későn kaptak észbe a hardvergyártók. Gyakorlatilag egyedül az AMD ismerte fel, hogy ez egy rendkívül fontos irány, viszont egy szabvány arról szól, hogy átfogó megoldást nyújtson a fejlesztőknek, amire bátran lehet építeni.
A Tiled Resources jelenlegi formájában egy szükségmegoldás, hogy a lehető legtöbb hardver legyen képes a hardveres megatextúrázásra. A Microsoft a körülményekhez képest igen jó rendszerrel állt elő. A Tiled Resources használatához a programba be kell építeni egy ellenőrzést, ami meghatározza, hogy az adott hardver egyáltalán képes-e támogatni az új DirectX funkciót. Ha nem, akkor az ellenőrzés egy 0-val tér vissza. Ezt az alkalmazás érzékeli, így betöltheti a szoftveres megatextúrázót, ami a fenti bekezdésekben közölt hátrányok mellett biztosítja a működést.
Ha a Tiled Resources támogatott, akkor sincs még minden eldöntve, ugyanis az ellenőrző visszatérhet 1-es és 2-es értékkel is. A 2-es érték esetében a Tiled Resources úgynevezett TIER_2 szintje töltődik be. Ez konkrétan ugyanazt a működést kínálja a DirectX API-n belül, amit az új generációs Xbox One és PlayStation 4, illetve ez a kiterjesztés lényegében az OpenGL-es GL_AMD_sparse_texture másolata, illetve alapvető továbbfejlesztése. Ebből az is következik, hogy csak akkor használható ez a működési szint, ha a felhasználó konfigurációja GCN architektúrára épülő AMD Radeon grafikus processzort rejt.
Az 1-es értékhez tartozó TIER_1 lényegében egy butított TIER_2 szint. Gyakorlatilag minden kikerült belőle, amit a Kepler architektúrára épülő NVIDIA GeForce grafikus processzorok nem tudnak megoldani. Ezek helyét szoftveres implementációk veszik át, hogy a működés biztosított legyen, viszont funkcionális szempontból le kell mondani a shader feedback utasításokról, mivel ez a kepleres GeForce-okon nem lehetséges.
Tiled Resources a gyakorlatban
A Tiled Resources esetében fontos szempont, hogy még nincs elfogadva a végleges specifikáció, ezért nincs a különböző szintekről tényleges leírás. A TIER_2 szint megoldott, hiszen annak zömében az Xbox One és a PlayStation 4 funkcionalitását kell hoznia. Ha minden jól megy, akkor ez a szint lesz a szabványban elfogadott és kötelező támogatást élvező módszer, de erre leghamarabb csak a következő nagyobb DirectX frissítésnél kerülhet sor. A TIER_1 szint kapcsán vannak kérdések, ugyanis ezt a Kepler architektúrára épülő GeForce kártyákhoz szabná a Microsoft. Ezt az álláspontot az NVIDIA elfogadja, hiszen aktuális hardvereivel a TIER_2 szintet úgysem tudják támogatni, de arról vita van, hogy mi lesz a régebbi architektúrára alapozó Radeon és GeForce termékekkel, valamint az Intel grafikus vezérlőivel. További butításokkal ezek is támogathatók, de ilyenkor a kepleres GeForce is kevesebbet tudna, azaz el is érkeztünk egy érdekellentéthez. Nagyon valószínűnek tartjuk, hogy a Microsoft nem fog változtatni eredeti tervein, hiszen az aktuális VGA-k zöme már NVIDIA Kepler és AMD GCN architektúrára épít, tehát logikus lépés a támogatás előbbi rendszerekre való korlátozása. A régebbi hardvereket könnyen le lehet cserélni újakra, míg az Intel esetében a játék a Microsoft szerint is másodlagos szempont lehet a vásárlók számára, így nincs értelme butítani a TIER_1 szinten, csak azért, hogy az Ivy Bridge és a Haswell IGP-je is megfeleljen az előírásoknak.
Ami a legfontosabb, hogy a Microsoft a Tiled Resources kihasználásához a Granite 2.0-t javasolja. Félreértés ne essék, egyik fejlesztőre sincs rákényszerítve semmi, tehát bárki írhat saját rendszert is, de a Granite 2.0 egy kész és egyben komplett környezet a Tiled Resources funkcióhoz. A middleware támogatja a TIER_1 és a TIER_2 szintet, illetve van egy szoftveres megatextúrázója is, ha az adott grafikus vezérlő a hardveresen gyorsított megoldásokat nem kezelné. A Granite 2.0 előnye, hogy mindig az elérhető legjobb szinten fut, illetve az adott program fejlesztésének késői fázisában is implementálható.
A Granite middleware működése [+]
Természetesen a Tiled Resources használata DirectX 11.2-es API-t igénye, így Windows 8.1 operációs rendszer szükséges hozzá. Ez a program oldaláról nem gond, hiszen a régebbi operációs rendszereken a Granite 2.0 azonnal visszavált a szoftveres megatextúrázásra, tehát a futtatás biztosított. Viszont Windows 8.1 mellett az alkalmazás gyorsabban dolgozhat, és jobb minőségű megjelenítést produkálhat például az anizotropikus szűrés támogatása kapcsán, így a játékosok számára az új operációs rendszerre való áttérés alapvető szempont lesz.
A Granite 2.0 jelenleg még nem támogatja direkten az új generációs konzolokat, de a fejlesztők valószínűleg ezen is dolgoznak. Érdemes megjegyezni, hogy a Microsoft ezt a rendszert nagyon támogatja, és ebben a cégnek érdeke is van. Elsősorban nem üzleti, hanem inkább az Xbox One működéséhez kapcsolódó koncepciók vezérlik a megatextúrázás használatának erősítését. A Tiled Resources működése után végzett kutatásunk során ugyanis megtudtuk, hogy a Microsoft a megatextúrázás potenciális terjedése miatt kért 32 MB-os ESRAM-ot az Xbox One APU-jába. Ez nagyon logikus, mivel a megatextúrázás az elvi működés miatt igen kevés memóriával is beéri a textúrák tárolt adataira vonatkozóan. A Granite 2.0 a Microsoft demonstrációján mindössze 16 MB-nyi VRAM-ot használt a textúrákra vonatkozóan (Full HD felbontás mellett), miközben a példaprogram több gigabájtnyi textúrával dolgozott. Utóbbi adatmennyiség akár több terabájt is lehet, de a működés akkor sem változik, így a memóriahasználat Full HD-ben 16 MB maradna.
Az Xbox One esetében a 16 MB-nyi textúra bőven elfér a 32 MB ESRAM-ban, ráadásul ezek elérése rendkívül gyors lesz, ami fontos, mivel a megatextúrázás elsősorban a késleltetésre és a memória-sávszélességre érzékeny. Persze a 32 MB-os ESRAM-ot nem kötelező erre vonatkozóan felhasználni, de a mögöttes koncepció jól látható.
A megatextúrázás buktatói
A megatextúrázásról eddig csupa jót írtunk, hiszen rendkívül előnyös technikáról van szó, melynek hála eddig sosem látott részletességű világ készíthető el. Egy probléma van ezzel kapcsolatban, ami szerencsére nem technikai eredetű, de így is jelentős gond. A megatextúrát el kell készíteni. Kiváló minőség mellett akár 10 TB-os tömörítetlen textúráról is beszélhetünk, aminek a megrajzolása rengeteg anyagi és emberi erőforrást igényel. Ez az a pont, ahol a fejlesztők felteszik majd a nagy kérdést: megéri-e a befektetett munka és pénz? Erre nehéz válaszolni.
Véleményünk szerint a Tiled Resources még extrém részletességű megatextúra nélkül is rendkívül hasznos funkció, hiszen drámaian csökkenti a VRAM terhelését a tárolt adatok szempontjából. Egy alapvető minőségű textúrát úgyis el kell készíteni a játékokhoz, tehát a Tiled Resources támogatása mindenképp megfontolandó, már az új generációs konzolok miatt is. Extrém minőségű megatextúrákra azonban nem sok remény van. Annyira sok erőforrás befektetését igényli, hogy jobb eszközök szükségesek a textúrák megrajzolásához. Mindenesetre a lehetőség adott, így remélhetőleg lesz legalább egy stúdió, amely bevállalja a régóta várt minőségi ugrást a textúrák részletessége szempontjából.
Abu85
