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.
A cikk még nem ért véget, kérlek, lapozz!
