A DirectX 12 megjelenésével a Microsoft több dián is feltüntette a JPEG támogatását, amiből sokan arra következtettek, hogy a jelenleg elfogadott textúratömörítési formátumok mellett a JPEG is elérhető lesz a grafikus vezérlők számára. Mint ötlet ez nem rossz, illetve átlagos szemmel nézve logikus is, hiszen a JPEG jó tömörítést kínál amellett, hogy a minőségen csak nagyon enyhén ront. A kompromisszumot a kisebb memóriahasználat érdekében nagyon sokan bevállalnák, de a Build konferencián elhangzottak alapján a JPEG nem lesz direkten támogatott formátum. A Microsoft az indokokat nem részletezte, de valójában jó okuk van erre, és ez a JPEG kódolás, illetve pontosabban dekódolás működésében keresendő.
A válaszok kapcsán fontos látni, hogy a grafikus processzornak igazából a tömörítetlen bittérkép az ideális. Egyszerűen a feldolgozás során az egyes pixelek számításához csak az adott textúra egyes információi (texelek) kellenek, amelyeket bittérképben tárolt adatként könnyen meg lehet szerezni a videomemóriából. Ha a textúra már tárolva van, akkor annak minden egyes eleme tetszőlegesen elérhető egy bizonyos memóriacímen. A jelenlegi grafikus API-kban használatos tömörített formátumok sem kavarják meg túlzottan ezt a rendszert, mivel blokkosított tömörítést alkalmaznak. Ennek az előnye, hogy egy meghatározott, jellemzően (de nem törvényszerűen) 4x4 pixelből álló mozaikon belül történik meg a tömörítés, így a mozaikokat könnyen be lehet olvasni, a dekódolást pedig a direkt támogatást kínáló textúrázó elvégzi, vagy esetleg utóbbi megoldható emuláció mellett is a shader processzorok segítségével. Az eredmény lényegében ugyanaz lesz, mint a tömörítetlen bittérképek beolvasásánál, csak némi extra munkával, ezt viszont kompenzálja a memória kapacitásának visszafogott kihasználása, illetve a memória-sávszélesség kímélése.
A JPEG mint esetlegesen életképes alternatíva leginkább a megatextúrázás felvázolásának idején került elő. Utóbbi technológia elméletben kivitelezhető tömörítetlen bittérképekkel is, de példaként a Rage című játék tömörítetlen megatextúrája 1 TB-ot foglalna. Ez tisztán technikai oldalról nem vállalható be, mivel megakadályozza a program terjesztését. A JPEG tömörítéssel az ominózus tartalom közel 13 GB-os méretűre csökkent, ami manapság már elfogadható. Itt jön viszont az a probléma, hogy a JPEG formátummal nem tud mit kezdeni a grafikus vezérlő, így ezt előbb át kell kódolni egy másik formátumba, majd úgy lehet használni az adatot textúraként.
A kérdés, ami foglalkoztatja a közvéleményt a DirectX 12 bejelentésével, hogy a JPEG használható-e átkódolás nélkül? A rövid válasz erre a nem. A hosszabb választ a specifikációkban kell keresni, amiből kiderül, hogy a JPEG dekódolása nem könnyű. Önmagában a grafikus vezérlő nem is ideális rá, illetve a központi processzor sem. A legjobb eredményeket mély integrációval összekapcsolt CPU és IGP közös munkájával lehet elérni, de még jobb egy dedikált hardveres blokk speciálisan a dekódolásra kialakítva. Amennyiben a JPEG-et direkt textúraként akarjuk felhasználni, akkor minden textúrázóhoz alkalmazni kell egy teljes dekódolót, ami pusztán a hardver tervezése szintjén vállalhatatlan, hiszen rengeteg extra tranzisztort igényelne. Egyetlen dekódoló azonban bőven belefér, és ezt az Xbox One APU-ja már tartalmazza is. Ezzel a módszerrel a megatextúra minden probléma nélkül szállítható JPEG formátumban, majd az előre meghatározott mozaikjait külön-külön ki lehet kódolni. Ezen a ponton arra kell figyelni, hogy a megatextúra dekódolt mozaikjai szabványosan elfogadott méretűek legyenek, ami a DirectX Tiled Resources esetén, az AMD GCN architektúra optimális működéséhez igazodva 64 kB.
A JPEG megatextúrát is úgy kell elkészíteni, hogy a mozaikok már magán a tartalmon ki vannak jelölve, és ezek egymástól függetlenül vannak kódolva. A dekódolás ugyanis a JPEG formátum esetében egy bonyolult folyamat, mivel maga a rendszer nem támogatja a véletlenszerű elérést, vagyis egy pixelnyi információ kinyeréséhez ki kell kódolni az egész soros bitfolyamot. Lényegében ez a működés az oka annak, hogy a JPEG nem lesz direkten támogatott formátum.
Ettől függetlenül a JPEG nagyon hasznos, és a jövőben a megatextúrázásra építő játékokhoz elengedhetetlen lesz. A grafikus vezérlőbe épített fixfunkciós dekódolónak tehát van értelme, és tulajdonképpen maga a működése is kellően átgondolt, hiszen az adott jelenethez mindig csak annyi információt kell a memóriában tartani, amennyivel megoldható az adott képkocka számítása. A dedikált dekódoló egyszerűen folyamatosan kitömöríti a program által igényelt mozaikokat és elhelyezi őket a videomemóriában, amelyek ily módon szimpla bittérképek lesznek, vagyis véletlenszerűen címezhetők. Persze némileg lassabban, dedikált hardver nélkül is kitömöríthető a JPEG, de ekkor ezen a központi processzornak kell dolgoznia, vagy esetleg egy modern APU-nak, ami mély integráció mellett sokkal gyorsabban meg tudja oldani ezt a feladatot.
A JPEG tehát fontos eleme lehet, sőt véleményünk szerint lesz is a jövő textúrázási koncepciójának, de nem direkten támogatott formában, mivel erre ez a rendszer alkalmatlan. Alternatívaként a blokkosított tömörítési formátumok további fejlesztése hozható fel, de ezeknél pusztán a működési elv behatárolja a reálisan érzékelhető minőségromlás nélküli tömörítés hatékonyságát.
