A Microsoft a Build konferencián beszámolt a DirectX 11.1-ről, melynek érkezéséről már korábban írtunk, ám akkor csak találgatni lehetett, hogy milyen újításokat hozhat. Akkor a DirectX 11 hibáiból indultunk ki, és részleteztük, hogy a rendszer hol szorulhat újításra, vagy reformra. A hivatalos adatok birtokában azonban kijelenthető, hogy a DirectX 11.1 egy apró lépés lesz előre, így alapvetően a DirectX 11 frissítésének fogható fel.
Elsőként az új API követelményeit érdemes elemezni. A Microsoft a WDDM 1.2-es felülethez köti a rendszert, és a Windows 8 megjelenésével lesz elérhető. A régebbi Windows rendszereken kérdéses a működése. Az egész attól függ, hogy a Windows 7, vagy a Vista megkapja-e a WDDM 1.2-es felületet egy frissítés formájában. Amennyiben nem, úgy a DirectX 11.1 csak Windows 8 alatt lesz elérhető. A WDDM 1.2 egyébként a DXGI 1.2-vel karöltve érkezik, és némi általános teljesítménynövekedés mellett, bevezeti a sztereó 3D hivatalos, és egyben szabványosan kezelt támogatását. További szolgáltatások tekintetében javul a rendszer erőforrás-megosztása, kevesebb memóriát követel a felület futtatása, és a TDR funkció is hatékonyabb lesz, ami esetlegesen megakadályozhatja az operációs rendszer lefagyását, amennyiben az adott hiba helyreállítható a WDDM újraindításával. Emellett a multimédiás képességek is javulnak. A DXVA esetében a pufferek megosztása eléggé nehézkes a DirectX számára, ezzel nagyon körülményes a különböző post-process effekteket megírása, amelyekkel javítható az adott videó képminősége. Az új felületek mellett ez már sokkal egyszerűbben kivitelezhető. Értékelhető extra még a shaderek futásának nyomon követhetősége, amihez mostantól nem szükséges külső segédprogram. Ettől függetlenül a Microsoft nem akadályozza meg a gyártói fejlesztőkörnyezeteken keresztül történő elemzést sem, így ez a része a rendszernek csak egy kiegészítés, amit igény esetén használni lehet.
A DirectX 11.1 – némi kiegészítés mellett – alapvetően a DirectX 11 fő képességeit másolja, ám újra elérhetőek lesznek az úgynevezett Vendor Specific Caps bitek. Ezek olyan specifikus funkciók, melyek egy-egy gyártó hardveréhez köthetők, azaz részei a szabványnak, de más gyártó esetlegesen nem támogatja őket. A Microsoft a DirectX 10-es API reformjaival hagyta el először ezt a rendszer, mégpedig azért, hogy az úgymond kőbe véset paraméterek mellett jelentősen egyszerűbb legyen a fejlesztők élete, hiszen egy szabványos kód biztos futni fog bármilyen hardveren, ami az adott kód által követelt DirectX verziót támogatja. Szintén nem elhanyagolható szempont az erőforrás érvényesítése, amit a specifikus kódok nélkül a program futásának kezdetekor kellett megtenni, és többet nem is szükséges vele foglalkozni, szemben a DirectX 9 modelljével, ahol a Vendor Specific Caps bitek következtében minden parancs kiadása előtt érvényesíteni kellett azt, hiszen nem volt garantált, hogy a hardver egyáltalán képes-e lefuttatni a kódot. Ez természetesen nem kevés késleltetést eredményezett a kódban, hiszen az érvényesítés feladata a központi processzort terhelte.
Az új API-val a Microsoft visszatért a DirectX 10-es reformok előtti útra, de meghagyta a lehetőséget a fejlesztőknek a Vendor Specific Caps bitek kizárására. Ezzel a rendszer használható úgy, hogy az erőforrás érvényesítése az alkalmazás indításakor egyszer történik meg, így kerülve el azt az extra késleltetést, amit a specifikus kiterjesztések ellenőrzése okoz. Ezen a ponton az API az új generációs hardvereket D3D_FEATURE_LEVEL_11_1 erőforrásként értékeli, és minden olyan kiterjesztést leválaszt, ami gyártóhoz köthető, vagyis nem biztosított az összes DirectX 11.1-es GPU-n történő támogatása. Ez a modell az erőforrás érvényesítése szempontjából a DirectX 10-es, 10.1-es és 11-es API működésére hasonlít. Lehetőség van azonban egy másik utat választani, ha a fejlesztő úgy gondolja. Ilyenkor az erőforrás érvényesítése a DirectX 9-es modellhez hasonlít, és használhatóvá válnak a Vendor Specific Caps bitek.
Gyakorlatilag ez a DirectX 11.1 legnagyobb változtatása, és ez egy kényszerű lépés is egyben, hiszen a DirectX 10-es API reformjai nagyon jól működtek, de a Microsoftot az új rendszerek támogatása, és a hardverek fejlődése sarokba szorította, így egy szükséges kompromisszum született. Itt nem szabad elfelejteni, hogy a Windows 8 már támogatja az ARM-os lapkákat is, melyek az asztali GPU-knál nagyon eltérő képességekkel is rendelkezhetnek. Az AMD, az Intel és az NVIDIA a PC-ben úgynevezett immediate render GPU-kat használ, amelyek egyben képzik le az adott jelenetből a képkockát. Az ARM-os vonalon azonban találkozhatunk eltérő megoldásokkal is. A Qualcomm Adreno és az ARM Mali sorozat például tile-based rendert használ, azaz a képkockát több kisebb szeletre osztják, és azokat számítják ki sorról-sorra. Ilyenkor a hardver a memóriával spórol, és az egymás mögött található, nem kivágott háromszögeket nem képzi le, hanem felállítja ezek sorrendjét, majd a legelöl lévő poligont dolgozza fel, míg a többi háromszöget figyelmen kívül hagyja. Az Immediate render ezzel ellentétben nem állítja fel az egy pixelen fekvő háromszögek sorrendjét, hanem egyszerűen mindet leképzi, majd a mélységteszt után az az eredmény marad meg, amely a legkisebb mélységértékkel tért vissza, vagyis ez a háromszög fedi az összes többit. A két elgondolás között állandó vita van, hogy melyik a jobb. Ha az adott rendszer kevés memóriából gazdálkodhat úgy biztos, hogy a tile-based render a nyerő, míg sok memória mellett az immediate render az előnyösebb, mert a háromszögek sorba rendezése nagyon komplex hardvert követel, és alapvetően lassú is a folyamat. Az Imagination Technologies PowerVR fejlesztései ebből a szempontból egy külön utat járnak, ami a tile-based deferred render néven ismert. Az alapötlet a tile-based rendert másolja, ám az árnyalás csak a látható pixeleken történik meg, amivel erőforrást lehet megspórolni. Ez úgy működik, hogy a leképzés előtt a rendszer az adott mozaikhoz tartozó poligontömböket elmenti a memóriába, majd a renderelés teljes menete a textúrázással együtt csak akkor kezdődik meg, ha kiderült, hogy mely poligonhoz tartozó pixel lesz látható a végső képen. Ezzel tulajdonképpen a felesleges textúrázási és fragment shader műveleteket lehet elkerülni. Természetesen ennél a módszernél kiemelt szerepe van a driveres támogatásnak, különben az egész feldolgozás nem lesz hatékony, és rossz esetben képhibák keletkeznek.
Az előző bekezdésből látszik, hogy a Windows 8-nak egy eléggé bonyolult helyzetet kellene egységesen lefedni, ami tulajdonképpen lehetetlen, éppen ezért sokkal jobb a gyártóknak is, ha visszatérnek a Vendor Specific Caps bitek, melyekkel a fejlesztő kezelheti a különböző architektúrák sajátosságait. Az asztali VGA-knál fontos funkció lesz még a virtuális memória támogatása, ami szintén nem lesz egységes, ráadásul mindez merőben új dolog egy GPU esetében, és sajnos az operációs rendszerek erre nem igazán vannak felkészítve. Ezen a ponton az AMD új generációs rendszere CPU pointereken keresztül támogatja az x86 virtuális memóriát, ami a PRT (Partially Resonant Textures) kiterjesztés mellett lesz elérhető. Ez eddig nagyon kedvező, hiszen egy új funkciónak mindenki örül, főleg annak fényében, hogy a PRT lehetővé teszi a hardveres megatextúrázást és a hardveres textúra streaming algoritmusok kreálását, valamint jelentősen több adat kezelése oldható meg a segítségével. A probléma ott kezdődik, hogy az NVIDIA ezt a funkciót nem támogathatja, ugyanis az x86 licenchez van kötve az x86 virtuális memória közvetlen kezelése. A Kepler architektúrára épülő GPU-k természetesen közvetlenül is kezelik a virtuális memóriát, de nem az x86, hanem az ARM oldaláról. Ez azt jelenti, hogy rögtön kaptunk egy feladatra két megoldást, amit egy szabványon belül csak a korábbi Vendor Specific Caps bites rendszerrel lehet támogatni. Érdemes megjegyezni, hogy az x86 virtuális memóriát közvetve is el lehet érni AMD IOMMU és az Intel VT-d technológiákkal, és ez az NVIDIA számára is járható út, de ezt a fejlesztőnek kell implementálnia az adott programba. Ha a mai viszonyokat nézzük, akkor ez rögtön három kódot jelentene ugyanarra a feladatra, és ez a programozó oldaláról nem a legjobb opció, de egyelőre nincs más lehetőség. Az Intel DirectX 11.1-es grafikus magja még messze van a megjelenéstől, de valószínű, hogy a Santa Clara-i óriáscég az AMD PRT kiterjesztésére épít, hiszen ennek támogatása számukra megoldható.
Egyelőre ennyit lehet tudni a DirectX 11.1-ről, és az új WDDM felületről. A Microsoft nem kétséges, hogy nehéz helyzetbe került, de az ismert adatok birtokában kifejezetten jól oldották meg a problémákat. Már csak a gyakorlati működés kérdéses.
