A Microsoft a DirectX 12-t még az idei év márciusában mutatta be, amiről természetesen beszámoltunk, illetve azt is pedzegettük, hogy milyen hardverre lehet szükség az API támogatásához.

Persze sejthető volt, hogy a Microsoft nem mondott el mindent a korábbi bemutatókon, így például a bekötési modellt is csak vázlatosan mutatták be. Ezzel nincs gond, de már akkor világos volt, hogy abban a formában ahogy felvázolták, a legtöbb ma megvásárolható grafikus vezérlő képtelen lesz támogatni.

Mint ismeretes a bekötési modell teljesen megváltozik a DirectX 11-hez képest. Utóbbival az a gond, hogy például a program létrehozza az erőforrásokat, majd ezeket beköti számos slotba a futószalag különböző shader lépcsőin. A shaderek ezekből a bekötött slotokból olvassák az adatokat, ami nem szerencsés, mert ha a program különböző erőforrásokból szeretne rajzolni, akkor újra be kell kötni a különböző látképeket a különböző slotokba, és újra ki kell adni a rajzolási parancsot. Itt több probléma is fennáll. Egyrészt a rajzolási parancs nagyon nincs ingyen, és tulajdonképpen ezzel pazaroljuk az erőforrást, emellett a bekötés processzorigényes, ami szintén pazarlás.

A DirectX 12 erre a gondra bevezeti a leírótáblákat, amelyek reprezentálják egy részét a teljes leíróhalmaznak. A leírótáblák módosítása rendkívül olcsó művelet, és az új API ezt használja ki. A program számos látképet készít az erőforrásokról, így pedig kiválasztható, hogy mely erőforrások használata szükséges az adott rajzolási parancshoz. Az előnyök egyértelműek. Csak annyi rajzolási parancs lesz, amennyi feltétlenül szükséges, illetve a bekötések száma is jelentősen redukálódik.

Ez mind jól hangzik, de maga a leírás feltétezi, hogy mindegyik hardver végtelen erőforrás kreálásának lehetőségével rendelkezik, tehát valamiféle limitációt be kell vezetni, hogy a mai grafikus vezérlők többsége ezt a működési modellt támogathassa.

A Microsoft bekötési modell szempontjából három szintet különböztet majd meg, amelyekről az alábbi táblázat ad felvilágosítást:

A PC-s grafikus vezérlők az említett szinteket támogathatják annak megfelelően, hogy az adott architektúra mire képes. A fejlesztőktől megtudtuk, hogy jelenleg a TIER_1-et és a TIER_3-at támogatják a mai, DirectX 12-es eszközillesztővel rendelkező termékek. Tulajdonképpen most még egyszerű a helyzet, mivel az AMD GCN architektúrája képes a TIER_3 szint kezelésére, míg az összes többi opció, ideértve az Intel Gen7.5 és Gen8, illetve az NVIDIA Fermi, Kepler és Maxwell architektúrát, a TIER_1 szintnek megfelelő tudást kínál.

Az NVIDIA Kepler és Maxwell egyébként képes lenne támogatni a TIER_2 szintet, de az UAV-k száma az összes shader lépcsőn az említett architektúráknál maximum 8 lehet, vagyis hiába felelnek meg az összes többi követelménynek egy hiányos funkció miatt az egész rendszer visszaminősül a TIER_1 szintre.

A Microsoft követelményei szerint a TIER_2 és a TIER_3 szint opcionális, vagyis a program oldaláról a kompatibilitást nem befolyásolja. Ez többek között annak köszönhető, hogy a fejlesztők szempontjából a támogatás nagyon egyszerűen oldható meg. A program futtatásának megkezdésekor le kell kérdezni a hardver tudását. Az adott eszközillesztő a három szint közül valamelyiket visszajelzi. Ezt a program beolvassa, és aszerint engedélyezi az egyes effektek aktiválhatóságát, hogy a rendszer melyik szintet jelezte vissza.

Gyakorlatilag így lehet a TIER_3 szintre dolgozni, amelyet egyébként az Xbox One konzol is támogat, és csak azt kell kijelölni a PC-s portban, hogy melyik effekt melyik szinten aktiválódhat. Ezután csak az erőforrást kell ellenőrizni és kész. A kompatibilitás tulajdonképpen garantált, ennél egyszerűbben szinte meg sem lehetne oldani.

A DirectX 12 a fenti szintek mellett a Microsoft terveinek is megfelel, vagyis egy olyan API-ról van szó, amelynél az Xbox One konzolra írt kódot direkten át lehet másolni PC-re, és igen apró, pár soros kiegészítésekkel futtathatóvá lehet tenni az érkező Windows operációs rendszeren.