Az új WDDM felület

A Microsoft DirectX 11.1-ről már sok adat ismert volt korábbról, és az sem újdonság, hogy az új API a Windows 8 operációs rendszerrel együtt érkezik. Az AMD GCN és az NVIDIA Kepler architektúrája már támogatja a felületet, melyet korábban még csak az előzetes specifikációk alapján lehetett megtenni, de a végleges követelmények ismeretében ez most már teljes bizonyossággal kijelenthető. Az előbbi cégek gyártópartnerei mostantól hivatalosan is ráírhatják az adott termék dobozára a DirectX 11.1 támogatását igazoló feliratot, amit eddig – érthető okokból – nem tehettek meg. Kiegészítés: Utólag kiderült, hogy az NVIDIA Kepler architektúrája mégsem támogatja a DirectX 11.1-et, melyről a linkelt hírben be is számoltunk.

A specifikációk véglegesítése mellett a Microsoft kiadta az újítások teljes listáját is, amelyet végre ténylegesen elemezni lehet. Az új DirectX 11.1-es API a szintén új WDDM 1.2-es felülethez kötődik, ami a Windows 8-ban mutatkozik be. Ezt a felületet később vissza lehet frissíteni a Windows 7-re is, de erről még nincs konkrét döntés, így az aktuálisan elterjedt operációs rendszeren a DirectX 11.1 alkalmazása limitációkba ütközik. A WDDM 1.2 egyébként a DXGI 1.2-vel együtt érkezik, és némi általános teljesítménynövekedés mellett bevezeti a sztereó 3D hivatalos, és egyben szabványos támogatását, ami már nagyon ráfért erre a széttördelt területre. A Microsoft itt tulajdonképpen egy fejlesztőkörnyezetet kínál, mellyel natív sztereó 3D támogatás építhető az adott programba, és minden olyan grafikus vezérlőn működni fog a szolgáltatás, mely támogatja a Windows 8 megoldását. Technikailag itt túl sok komoly követelmény nincs, így valószínű, hogy az Intel InTru 3D-t, az AMD HD3D-t és az NVIDIA 3D Visiont kezelő termékek megfelelnek erre a célra. Természetesen az adott gyártónak gondoskodnia kell a driveres támogatásról is.

A további szolgáltatások tekintetében elmondható, hogy javul az erőforrás-megosztás, mely egy újszerű preemptív multitask modellel valósul meg. A rendszer ezzel alacsony késleltetés mellett hozzáférhetővé teszi a grafikus vezérlőt az alkalmazások számára, így az jobban kihasználható. Bevezetésre kerül az úgynevezett DirectFlip is, amivel kevesebb memória-sávszélességet követel a felület futtatása. Ezen belül a megjelenik egy hatékonyabb energiamenedzsment is, mely igyekszik olyan alacsonyan tartani a grafikus vezérlő fogyasztását, amennyire csak lehet. 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. A hatékonyabb jelző abban rejlik, hogy a WDDM 1.2-ben a rendszer mostantól a grafikus vezérlőt logikai szinteken kezeli, melyek az engine nevet kapták. Az alkalmazások ezeken a logikai szinteken futnak, és ha valami probléma történik az adott szinten futó programmal, akkor a TDR funkció nem indítja újra a teljes WDDM felületet és a grafikus vezérlőt, hanem csak az adott engine-höz kapcsolódó folyamatokat állítja le, majd indítja újra el.

A TDR működése a WDDM 1.1-ben és a WDDM 1.2-ben

Komoly újítás még a multimédiás képességek javítása. Az aktuális DXVA API 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 Unified Video API ezen segít, ugyanis a feldolgozás mostantól a – némileg kiegészített – DirectX 11-es futószalagon belül zajlik, ami jelentősen megkönnyíti a fejlesztők munkáját.

A WDDM 1.2 felület újításainak támogatása némi áldozattal is jár, ugyanis a fentebb részletezett összes új funkcióhoz minimum DirectX 11-es grafikus vezérlő szükséges. E nélkül például nem lesz elérhető a Unified Video API, a DirectFlip szolgáltatás, illetve az új preemptív multitask modell és a fejlettebb energiagazdálkodás sem. Emellett számos szolgáltatás lassabban, illetve nagyobb memóriaigény mellett fog működni. Természetesen a Windows 8 működni fog DirectX 10.1-es, 10-es vagy akár régebbi hardveren is, de a WDDM 1.2 felület a butább rendszereken viszonylag kevés új szolgáltatást fog nyújtani.

A Microsoft bevezet még egy extrát is, mellyel a fejlesztők nyomon követhetik a shaderek futását, és ehhez mostantól nem szükséges külső segédprogram. Persze a vállalat 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, sőt érdemes vele élni.

A DirectX 11.1 extrái

Az alapok után érdemes a DirectX 11.1 újításaira koncentrálni. Az új felület nem szakít a DirectX 11-gyel, így az előző API kibővítésének tekinthető. Ennek megfelelően működésben a rendszer nagyon hasonló, így megmaradnak a futtatási szintetek is. Ez azt jelenti, hogy a fejlesztőnek elég a DirectX 11.1-es kódot megírni, és az API a hardvernek megfelelő futtatási szintet kalibrálja. A legjobb DirectX 11.1-es szint alatt található még hat opció, így a kód futhat DirectX 11-es, 10.1-es, 10-es, 9.3-as, 9.2-es és 9.1-es módban. Az előbb tárgyalt szintek közül a számítógépben talált hardvernek megfelelő erőforrás automatikusan, a program indulásakor jön létre. Természetesen gyengébb hardverek esetén a rendszer a kódban szereplő nem kompatibilis utasításokat és funkciókat egyszerűen nem futtatja le.

Az új API főleg olyan helyeken újít, ahol a fejlesztők nem voltak megelégedve a DirectX 11-gyel. Ezek közül az egyik fontos változás a logikai operációk engedélyezése a render targeteken, ám némi megkötés, hogy ezeket nem lehet mixelni a blendinggel. A másik lényegesebb újítás a kényszerített mintaszámítás lehetősége a raszterizáló státusz készítésénél. Szintén előrelépés, hogy a DirectX 11.1-gyel 64 kB-nál nagyobb constant bufferek is létrehozhatók, ám a shaderek ebből továbbra is csak 64 kB-os részt érhetnek el, ezt a tartományt viszont egyénileg lehet specifikálni constant bufferen belül. Változik az UAV-k (Unordered Access View) kezelése is. Ezek általános adatpufferek, melyeket a DirectX 11 vezetett be, és a futószalag pixel, valamint compute shader része olvashatta a tartalmukat. A DirectX 11.1 újítása erre vonatkozóan, hogy több UAV-t lehet kreálni, továbbá most már a futószalag összes programozható lépcsője olvashatja a tárolt adatokat. Ezenkívül az API több új Texture2D erőforrástípust és formátumot is bevezet.

A fenti újítások mellett akadnak általánosabb funkciók is, melyek nem feltétlenül követelnek DirectX 11.1-es hardvert. Például a dupla pontosságot támogató grafikus vezérlők esetében lehetőség lesz elérni ezt a tudást a pixel shader kódok mellett. Ezzel a számítások precizitása jelentősen nőhet, ugyanakkor kérdés, hogy ennek van-e értelme, hiszen a legtöbb mai hardver dupla pontosság melletti teljesítménye nem valami acélos. Ettől függetlenül a lehetőség adott. Komoly újítás lehet az eszközmegosztás a Direct3D-n belül. A DirectX 11.1 lehetővé teszi, hogy a DirecX10 és 11 API használjon egy alárendelt eszközt. Ez érdekes funkció lehet a több grafikus vezérlőt tartalmazó gépek esetében, amiből amúgy is egyre több van, hiszen a legtöbb processzort IGP-vel adják el, ami mellé a játékosok egy része még dedikált GPU-t is használ.

Az előbbi bekezdésekből látható, hogy a DirectX 11.1 nagyon értékes funkciókat vezet be, de a legjobb újítás még csak most jön. Az új API ugyanis kezelni fogja a specifikus kiterjesztéseket, amelyeket a gyártók adhatnak hozzá a rendszerhez. A Microsoft a DirectX 10 óta ezt a lehetőséget mellőzi, ami egyrészt egyszerűbbé tette a fejlesztők életét, másrészt jelentősen leegyszerűsítette erőforrás érvényesítést is. Ez a DirectX 10-ben bevezetett reformok óta a program indításakor egyszer történik meg, szemben a korábbi DirectX API-kkal, amikor minden egyes rajzolási parancs előtt meg kellett kérdezni a drivert, hogy a rendszer támogatja-e. Nyilván utóbbi megoldás az erőforrás érvényesítésére nem jó, így a Microsoft bevezeti a kiterjesztéseket. A rendszer lényegében úgy működik, hogy a program elindításakor az erőforrás érvényesítésre kerül, vagyis itt nincs változás a DirectX 10 óta, de lesz még egy ID3D11Device::CheckFeatureSupport és egy ID3D11Device::CheckFormatSupport paraméter is, melyek szintén a program indításakor futnak le. Lényegében ez a két funkció gyűjti be az adott rendszerről az összes adatot, így a program látni fogja, hogy a driver és a hardver alkalmaz-e specifikus kiterjesztéseket. Talán írni sem kell, hogy ezeket nem kötelező támogatni, vagyis a gyártók kiterjesztéseit a Microsoft nem veszi számításba, de ez a lépés szükséges volt, mivel az egyes cégek eléggé eltérő grafikus vezérlőket terveznek, valamint a legtöbb ARM-os gyártók számára sem optimális az eredeti futószalag. Röviden tehát, az API-nak lesz egy olyan része, amit kötelező támogatni, ám ehhez a gyártók írhatnak kiegészítéseket, amivel a hardver egyes extra funkcióit lehet kihasználni, vagy csak a hatékonyabb működést garantálni. Természetesen a kiterjesztéseket a fejlesztőknek kell támogatni az adott programon belül.

Mivel a DirectX szabvány, így minden kiterjesztés nyitott a gyártók között, vagyis ha valaki ír egyet, akkor azt bárki támogathatja, feltéve, hogy az adott hardver képes arra. Felmerülhet persze a kérdés, hogy hol lehet ennek jelentősége. Például érdemes megnézni az AMD GCN és az NVIDIA Kepler architektúráját. Mindkét rendszer több egyedi textúrát kezel egy shader kódban, mint amennyit a DirectX 11.1 megkövetel (128 darab). Az NVIDIA új generációs hardvere kicsivel több, mint egymillió egyedi textúrát támogat, míg az AMD megoldása gyakorlatilag végtelen mennyiségűt (ezt persze senki se fogja kihasználni, hiszen sosem futna le a kód). Valószínű, hogy a két vállalat készít egy-egy különálló, vagy akár egy közös kiterjesztést erre, hiszen értékes funkcióról van szó. Az természetesen világos, hogy a shader kódok nem fognak rögtön egymillió egyedi textúrát bekötni, de esetenként hasznos, ha a shader kódon belül 128-nál több egyedi textúra kezelhető. Ezenkívül az úgynevezett bindless textúrázás csökkenti a processzorra rótt terhelést, ami nagyon hasznos tulajdonság.

Szintén érkezhet az AMD-től egy PRT (Partially Resident Textures) kiterjesztés is, mely kihasználja az új generációs GCN architektúra legértékesebb extra képességét. A PRT eljárás lehetővé teszi a hardveres virtuális textúrázást (ismertebb néven 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 segítségével. Emellett jelenleg a PRT az egyetlen ismert megoldás arra, hogy virtuális vagy megatextúrázás mellett alkalmazható legyen a teljes értékű hardveres anizotropikus szűrés.

A PRT előnyei a szoftveres implementációhoz viszonyítva [+]

Érdemes megjegyezni, hogy a bindless textúrázás lehet egyfajta eszköz az egyéni, szoftveres megatextúrázó algoritmus kreálásához, de a teljesen hardveres megvalósításhoz, illetve az anizotropikus szűrés támogatásához már PRT-re van szükség.

Természetesen a DirectX 11-es hardverekhez is érkezhetnek kiterjesztések, de nem biztos, hogy ezeknek sok értelme lenne. Mindenesetre erről a gyártó dönt, a Microsoft pedig megadja a lehetőséget. A DirectX 11.1 a végleges és mondhatni tényleges specifikációk alapján egy értékes fejlesztés, melynek nemcsak a DirectX 11.1-es kártyákkal rendelkező felhasználók veszik hasznát. Ugyanezt tudjuk elmondani a WDDM 1.2-es felületről, mely minden szempontból előrelépés az elődhöz képest.

Abu85