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