A Microsoft még 2015-ben mutatta be a DirectX 12-t, ami máig az iránymutató alternatívának számít az explicit grafikus API-k között. Ugyanakkor az idősebb olvasók tudhatják, hogy korábban milyen sűrűn érkeztek új DirectX verziók, ami miatt a DirectX 13-at sokan hiányolhatják. Miért nincs még szó erről a fejlesztésről, esetleg a redmondiak félnek ettől a számtól? Ennek kérdeztünk utána az elmúlt hetekben.
Valójában a DirectX 12 kapcsán megjegyzendő, hogy alapvetően egy folyamatosan fejlődő API-ról van szó. Tehát attól, hogy nincs DirectX 13, még új funkciók legalább évente érkeznek. Sőt, ezeket régen a Microsoft funkciószintekre is osztotta, de már nem teszik meg, ugyanis megfigyelték, hogy a fejlesztők az egyes funkciók elérhetőségét külön-külön ellenőrzik, vagyis a funkciószinteknek túl nagy szerepe így nincsen. Itt persze nagy segítség, hogy a gyártók az egyes újításokat törekednek relatíve hamar támogatni, tehát a redmondi óriáscég számára optimális a helyzet, mivel a funkciók kategorizálása nélkül is gyorsan elérhetők a frissítéseket támogató API implementációk – hardveres és szoftveres szinten is.
Információink szerint a Microsoft addig nem is nagyon gondolkodik a DirectX 13-ban, amíg valami radikális módosításra nincs szükség az API működését tekintve, de a DirectX 12 alapjai nagyon jól sikerültek, így ezekre még sokáig lehet építeni. Ettől függetlenül számos újítás készül, tehát szó sincs arról, hogy a háttérben ne lenne munka.
Hirdetés
A várható frissítésekkel kapcsolatban megtudtuk, hogy az egyik kritikus projekt most a HLSL specifikálása, illetve a DirectX Shader Compiler (DXC), vagyis a HLSL kódokból DXIL-t generáló shader fordító modernizálása. Utóbbi szempontból ismert, hogy a DXC az LLVM és Clang 3.7-es verziójára épít, ami meglehetősen korosodó alap, nehézkes is a frissítés egy új LLVM verzióra, ráadásul nem túl szerencsés, hogy a HLSL sincs hivatalosan specifikálva.
A további fejleszthetőség egyszerűsítése érdekében a Microsoft a HLSL 202x projekt részeként készíti el a szóban forgó nyelv alapspecifikációját, amit később majd kiegészíthetnek, és itt már a HLSL 202y egy most létező irány. Ehhez kapcsolódó projekt a HLSL támogatásának megvalósítása Clangben, így úgynevezett Clang DXC binárisok fordíthatók a mostani MSVC DXC helyett. A változások célja a jelenleg hiányzó C/C++ funkciók optimális implementálása, hogy a jövőben hatékonyabban fejlődhessen a HLSL nyelv.
Bár a fentiek nagyon lekötik a Microsoft figyelmét, hiszen tényleg kritikus tényezőkről van szó, azért a háttérben más újításokon is dolgoznak. Többek között még mindig terítéken van a traversal shader. Ezt leginkább a fejlesztők igényelnék, ugyanis a jelenlegi DirectX Raytracing masszív problémája, hogy a sugárkövetés amolyan „feketedobozként” valósul meg benne. Vannak tehát bizonyos funkciók, amelyeket a shaderekben meg lehet hívni, de ezek nagy része limitált lehetőségeket ad, és az API specifikáció is rendkívül titkolózó az alkalmazott BVH adatstruktúra formátumával kapcsolatban. Ezt a gondot gyakorlatilag az hozza elő, hogy az API egyedi BVH adatstruktúra-formátuma zárt.
Maga a traversal shader megoldás lehetne, de ennek az implementálása jelenleg azért nehézkes, mert kötelezően igényli a nyílt BVH adatstruktúra-formátumot, hogy a programozhatóság megvalósulhasson. Utóbbi ötletért az egyes gyártók nem rajonganak, mert csupán azért, hogy a fejlesztők jóval gyorsabb kódot írhassanak, nem hoznák nyilvánosságra a jelenlegi zárt BVH adatstruktúra-formátum specifikációját. És itt akadt meg a projekt, ugyanis a Microsoft vagy rábeszéli az érintett cégeket ennek a publikálására, vagy az API vált egy teljesen új, de nyílt BVH adatstruktúra-formátumra. Utóbbi egyébként technikailag megoldható lenne a meglévő hardvereken is, tehát a mostani GPU-k ugyanúgy tudnák gyorsítani a sugárkövetést, de a bejárás gyorsítótására szabott specifikus célhardver működésképtelenné válna bennük. Ha viszont a meglévő BVH adatstruktúra-formátum lenne megnyitva, akkor egyrészt az alapprobléma ugyanúgy megoldódna, másrészt pedig a már beépített célhardverek is működhetnének tovább, ha a fejlesztők éppen nem akarnak traversal shadert használni.
Aktív munka zajlik még a háttérben a geometria tömörítésének megoldásán is. Utóbbi egy igencsak forró téma az Unreal Engine 5-ben bemutatott Nanite rendszer óta, ami a sugárkövetésnek nem igazán tesz jót, mivel a mikropoligon jellegű ábrázolás nem kicsit nehezíti a munkát, nem beszélve arról, hogy mennyire extrém lehet a memóriaigénye. Emiatt a szóban forgó videojáték-motor nem is engedi a virtualizált geometriát sugárkövetés mellett, helyette egy nagyon lebutított proxy mesh szolgáltatja az alapot, ami ideig-óráig elmegy, de ennél azért sokkal jobb kellene, hogy a kapott minőség is elfogadható legyen.
A probléma kapcsán két alternatívan van az asztalon, az egyiket az NVIDIA, míg a másikat az AMD kínálja. Az NVIDIA megoldása a már ismert DMM, azaz Displaced Micro-Mesh, ami része az Ada Lovelace architektúrának. A működés szempontjából a rendszer veszi az eredeti felületet, majd annak a részletességét radikálisan csökkenti, így végeredményben sokkal kevesebb háromszögből áll majd, miközben a felület információit elmenti displacement map formájában. Ezáltal maga a gyorsítóstruktúra egyszerű maradhat, hiszen a valós számítások szintjén a felület tényleges részletességének csak a töredékét kell figyelembe venni, ami ad némi minőségbeli különbséget, de az alapvető gondot kompromisszumok nélkül nem lehet megoldani. A DMM alapvetően működik, de van két nagy gondja. Egyrészt a felületek előkészítése rendkívül sok processzoridőt igényel, másrészt a funkciót figyelembe véve kell elkészíteni hozzá a geometriát, és utóbbi miatt nem is nagyon érdeklődnek iránta a fejlesztők, mert extrém mennyiségű pluszmunkával jár.
Az AMD alternatívája az alapproblémára a DGF, vagyis a Dense Geometry Format. Ez a DMM-hez viszonyítva kevésbé trükkösen veszi célba a gondokat, ugyanis egy skálázható, veszteséges tömörítésről van szó a meshletekhez. A DGF tömörítési aránya sokkal kevesebb a DMM-hez képest, mivel valóban reprezentálja a geometriát, nem csak egy displacement map formájában adja vissza, és emiatt bármilyen geometriával megbirkózik, azaz nem igényel ezen a területen semennyi pluszmunkát fejlesztői oldalon. Emellett a felületek előkészítése a processzorra rótt terhelés szempontjából nagyságrendekkel kedvezőbb, cserébe kevésbé csökken tőle a memóriaigény, mint az DMM esetében.
Információink szerint az egyik rendszer lesz szabványosítva a DirectX-ben. Nyilván a gyártói háttér tekintetében a saját megoldáshoz ragaszkodnak az érintettek, de a fejlesztők egységesen a DGF-et tekintik optimálisnak, valószínűleg annak köszönhetően, hogy ennek használata nem jár jelentős extra munkával.
Az látható tehát, hogy nagyon aktív munka zajlik a háttérben, és az ötletek is kedvezők, csupa olyan újítás, ami kritikus fontosságú. Egyetlen terület van elhanyagolva: az AI grafikai alkalmazása, ami egyelőre nem tűnik prioritásnak a szabványos API szintjén.
