Bár a Microsoft portáján a grafikus API-k szempontjából egy ideje minden a DirectX 12-ről szól, a vállalat bejelentette, hogy nem fejezik be az aktuális DirectX 11 alapjaira való építkezést sem. Erre a cégnek jó oka van, ugyanis a DirectX 12 egy alacsony szintű hardverelérést biztosító API, ami egyrészt nagyon jó, mert jóval hatékonyabban lehet majd kihasználni a PC-s hardvereket, de vannak bizonyos olyan hátrányos tényezők, amelyek miatt nem mindegyik fejlesztőstúdiónak ajánlott ez az irány. Erre most a Microsoft is figyelmeztette az ipart, hiszen a DirectX 12-vel a kontroll az alkalmazásé lesz, vagyis a program fejlesztőjének kell megírni az adott architektúra működéséhez szükséges optimalizálást.

Technikai értelemben úgy a legegyszerűbb ezt leírni, hogy a grafikus meghajtó leegyszerűsödik, azaz nem igazán lesz több, mint egy shader programok futtathatóságát lehetővé tevő réteg. A többi funkció nem tűnik el, csak amíg a DirectX 11-ben ezek a grafikus meghajtóban voltak, addig a DirectX 12-ben átkerülnek magába az alkalmazásba. Bár kisarkított nézet a működés szempontjából, de a közérthetőség érdekében mondható az, hogy a DirectX 12-ben maga a program tartalmazza a grafikus meghajtókban jellemzően fellelhető fontosabb funkciókat, vagyis kvázi a fejlesztők írnak minden architektúrára egy grafikus eszközillesztőt. Ez persze a Microsoft szerint sem pontos megfogalmazás, mivel alapvetően szabványosítva lesznek a fontosabb elérési utak a hardverek felé, de a végfelhasználók által ismert fogalmakra és tényezőkre építve valóban így a legegyszerűbb megértetni azt, hogy mi változik a DirectX 12-ben.

Ez azonban óhatatlanul azt eredményezi, hogy az adott program fejlesztője felelősséget vállal azért, hogy a futtatott játék nem tesz majd kárt az operációs rendszerben, azaz nem okoz majd fagyást, vagy esetleg valami rosszabbat. A Microsoft és az API-t támogató gyártók szimplán megbíznak a fejlesztőkben, hogy képesek olyan programokat írni, amelyek egy fagyás után sem végzik ki Windowst, azaz az operációs rendszer bejegyzéseiben nem keletkezik majd olyan kár, hogy újraindítás után ne legyen képes elindulni és hasonlók. Nagyon sokan képesek erre, illetve ha teljesítményre van szükség, akkor meg kell tanulni az alacsony szintű hardverelérést biztosító API-k rejtelmeit, illetve a megcélzott architektúrák működését. A Microsoft azonban meg akarja hagyni az alternatív lehetőséget, így a DirectX 11-et folyamatosan ki fogják egészíteni.

A következő lépcső a DirectX 11.3, amely négy opcionális funkcióval egészíti ki az API-t. Ezek csak a DirectX 12-ben kötődnek majd egy D3D_FEATURE_LEVEL szinthez, míg a DirectX 11.3-ban szimplán egyenként kell ellenőrizni az elérhetőségüket. Ez nem olyan nagy dolog, lényegében a program indításakor kell lefuttatni egy erőforrás-ellenőrzést, és ha az adott technikára vonatkozóan van támogatás, akkor aktiválható a rá épülő effekt is.

A legfontosabb újítás az úgynevezett typed UAV loads kiterjesztés. Ez kiegészíti az UAV-k kezelésének lehetőségeit, hiszen utóbbi eddig csak egykomponenses 32 bites elemtípusokra volt használható. Mostantól ez a limitáció eltűnik, ami eléggé fontos szempont volt a Microsoft számára, hiszen többek között az Xbox One-hoz használt APU IGP-je nem rendelkezik ezzel a korláttal, így jóval kedvezőbb a shader programok fejlesztése erre a konzolra, de az újításokkal ezek komolyabb módosítások nélkül is átmenthetők lesznek egy szabványos PC-s grafikus API-ra is.

A DirectX 11.3 extrája még az Intel PixelSync technikájának szabványosítása. Ennek képességeit az alábbi oldalon mutattuk be, így nem részleteznénk újból. A Microsoft viszont raster order view néven emlegeti, és azt is fontos kiemelni, hogy a korábban írt PixelSync használatát lehetővé tevő kódokat mindenképp át kell írni a szabványos formához.

[+]

Szintén érdekes újítás a konzervatív raszterizáció hardveres gyorsítása, ami arra szolgál, hogy a raszterizálás a mostani kötött formánál jobb irányíthatóságot kapjon. Mint ismeretes, a normál raszterizálás esetében a háromszög akkor fedi az adott pixelt, ha a mintavételi pont fedi azt. A konzervatív raszterizáció esetében lehetőség van arra, hogy a háromszög akkor is fedje a pixelt, ha annak csak egy nagyon apró része nyúlik bele a pixelbe.

Végül a DirectX 11.3-ban megjelenik a Volume Tiled Resources funkció. Ez nagyon hasonló a Tiled Resources koncepciójához, csak éppen 32 bites 3D-s textúrákra van kiterjesztve. Az eljárás alapja nem újdonság, hiszen erre az OpenGL-ben már létezik kiterjesztés, ahogy a két új generációs konzol támogatja a technikát, de ugyanakkor ezek nem szabványos megoldások. A Volume Tiled Resources viszont az lesz.

Az alapötletet az adja, hogy a 3D-s virtuális világról tároljunk el tetszőleges információkat. Erre a 3D-s textúra elvben tökéletes, de maga a létrehozott világ elég nagy lehet, tehát nagy textúra is kell hozzá. A Microsoft példaprogramjában ez a textúra önmagában elérheti az 1,6 GB-ot is. Valójában azonban ebből a töménytelen adatból csak kevés olyan hasznos információ van, amely szükséges az adott képkocka számításához. Ez persze nagyban függ a jelenet komplexitásától, de valamekkora pazarlás mindenképpen lesz.

[+]

Ugyanebben a példaprogramban a nagy 3D-s textúrát sok kicsi, 32x32x16-os 3D-s textúrákra cserélve, a Volume Tiled Resources funkciót használva nagyjából 2500 darab 3D-s textúra betöltése szükséges ugyanahhoz a számításhoz, de a memóriában tárolt információ már csak nagyjából 156 MB lesz.

Más jelenetek természetesen más eredményeket adnak majd, de a memóriaigény minden esetben csökkenni fog.

A DirectX 11.3 várhatóan a Windows 9-cel, illetve az újabban már csak szimplán Windowsnak nevezett operációs rendszerrel fog megérkezni, valamikor tavasszal. Ugyanakkor a specifikáció nincs véglegesítve, így hivatalosan egyetlen gyártó sem jelentett be támogatást az új effektekhez.

Az NVIDIA utalt rá, hogy a frissen megjelent GM204 kódnevű lapka a specifikációk jelen formájában támogatja az újításokat. Az egyes architektúrák működését figyelembe véve a többi GeForce GPU valószínűleg egyiket sem támogatja, míg az Intel Gen7.5 és Gen8 architektúrára épülő IGP-i a PixelSync technikából kiindulva alkalmasak lehetnek raster order view használatára. Az AMD GCN architektúrája a Mantle API-ba épített hasonló képességeket figyelembe véve támogathatja a typed UAV load kiterjesztését és a Volume Tiled Resources funkciót. Ennél többet csak a specifikációk lezárása és a gyártók hivatalos bejelentései után lehet majd tudni.