A lehetetlen mégis lehetséges?

A DirectX API-t talán mindenki ismeri, hiszen a Windows operációs rendszerre épülő játékok, illetve grafikai alkalmazások döntő többsége ezt a rendszert használja. Éppen ezért az API fejlődését is igen nagy érdeklődés övezi. A Microsoft a Windows 8-cal egy újabb DirectX verziót indított útjára, mely a 11.1-es jelzést viseli, és talán az egyik legnagyobb változást hozza a cég történetében.

Rögtön az elején hangsúlyozzuk, hogy a DirectX 11.1 működése bonyolult, ami annak köszönhető, hogy a Microsoft minden igényt le szeretne fedni az új API-val. Ezt rendkívül nehéz megtenni, mivel az ultramobil grafikus vezérlők működése nagyban eltér a hagyományos PC-s piacra szánt társaikétól, amit nemrég elemeztünk is egy cikk erejéig. Az API tervezésénél igyekeztek a fejlesztők a lehető legegyszerűbb működést kialakítani, de könnyen kitalálható, hogy minél több hardvert kell megfelelően támogatni, annál bonyolultabb minden szempontból egységes funkciókat beépíteni. Ez természetesen nem csak a Microsofton múlik. Mint ismeretes, az API alapvető célja, hogy az alkalmazásfejlesztőknek ne kelljen a hardverek működését ismernie a program írásánál, így alapvetően minden funkciót érdemes egységesen kezelni. A hardvert fejlesztő cégek azonban eltérő tempóban és eltérő koncepciókkal dolgoznak, így a grafikus vezérlők sok szempontból támogathatók megegyező funkciókkal, de ugyanakkor lesznek eltérések, amire vagy nincs támogatás, vagy specifikusan kell valamilyen DirectX funkciót beépíteni.

Összefoglalva a DirectX 11.1-gyel a Microsoft nem kisebb célt tűzött ki, mint egy grafikus API-ból kiszolgálni a sokszor igen eltérően működő ultramobil grafikus vezérlőket, teljesíteni a fejlesztők alapvető kívánságait, jobb programozhatóságot biztosítani a új generációs PC-s grafikus processzorokhoz, illetve a gyártók kívánalmainak eleget téve egyfajta jól működő kiterjesztésrendszert is be kellett vezetni. Egyenként ezek nem jelentenek problémát, de egyszerre, egy tényleg egységes API-ba beépítve már komoly fejfájást okozhatott a rendszerprogramozóknak, talán néha arra is gondoltak, hogy lehetetlen megoldani a felmerült igényeket.

Játék a precizitással

Valószínűleg az ultramobil grafikus vezérlők figyelembe vétele jelenthette a legtöbb gondot a fejlesztés során. A Microsoftra a DirectX 10-től jellemző volt, hogy nem tűrte meg a minőség korlátozását, így az új elvek szerint tervezett DirectX API-k megkövetelték, hogy a shader programok 32 bites lebegőpontos (FP32) precizitással legyenek futtatva. Pár alkalmazás a Windows XP-vel való kompatibilitás miatt 16 vagy 24 bites lebegőpontos (FP16 és FP24) feldolgozást is megengedett, de Windows 7 és Vista operációs rendszeren a grafikus driverek shader fordítói ezeket kicserélték FP32-re, ugyanis ez követelmény volt a Microsoft részéről. Ez senkinek sem jelentett eddig gondot, hiszen a gyártók a hardvereket eleve ilyen igénybevételre tervezték, a felhasználók pedig jobb képminőségre tehettek szert bizonyos programokban, ha új operációs rendszert használtak.

A DirectX 11.1 azonban mindent megváltoztatott. Ha maradt volna az FP32-es precizitás, mint követelmény, akkor a piacon fellelhető ultramobil grafikus vezérlők egy része nem felelne meg az elvárásoknak. A Microsoft az egységesség miatt új formátumokat vezetett be, így mostantól a fejlesztőknek nem kell konkrétan meghatározni a feldolgozás precizitását, de ki kell jelölniük egy minimumszintet.

A lebegőpontos adattípusok szempontjából 10 bit (min10float) vagy 16 bit (min16float) lehet a minimum. Egy példával élve, ha a program min16float értéket határoz meg, akkor a feldolgozás precizitásának minimum 16 bitesnek kell lennie, a gyakorlatban pedig a grafikus driver shader fordítója a támogatott legjobb precizitást állítja be. Ez egy korszerű AMD Radeonon vagy NVIDIA GeForce-on 32 bitet jelent, de mondjuk az ultramobil mezőnyből az NVIDIA Tegra integrált grafikus vezérlője már csak 20 bites pontosságot támogat a pixel shader programok szempontjából, így a rendszer erre fog építeni.

Érdekességként elmondható, hogy a ma kapható termékek igen nagy többsége támogatja a 32 bites lebegőpontos precizitást. Gyakorlatilag ide sorolható az AMD Radeon X1000 és az összes HD sorozatú termék, az NVIDIA esetében a GeFoce 6 után megjelent összes megoldás, az Intel IGP-iből az új HD Graphics sorozat, illetve az S3 Chrome 400, 500 és 600 széria. A PC-s hardverek tehát jól állnak ebből a szempontból. Funkcionálisan az ultramobil grafikus vezérlők sem szégyenkezhetnek, hiszen a unified shader felépítést használó IGP-k is képesek mindent kiszámolni FP32-es precizitással, de az adatút már igen szűkös, így a cégek a pixel shader programokra limitálják a lehetőségeket az Android driverekben, hogy sebességet nyerjenek

Ezt valószínűleg a Windowsra is átemelik, hiszen a sebesség az operációs rendszer leváltása miatt nem lesz nagyobb. Információink szerint jellemzően FP24-es precizitást állítanak be az ARM-os rendszerchipekben utazó vállalatok. Az új dizájnok azonban kivételt képeznek, mivel ezeket már felkészítették a jövőre, így az ARM Mali-T600, az Imagination Technologies PowerVR Series6, illetve a Qualcomm Adreno 300/400 már gyorsan számol 32 bites lebegőpontos precizitás mellett is. A nem unified shader elven dolgozó ultramobil IGP-k, mint az NVIDIA Tegrákban található ULP GeForce-ok és az ARM Mali-400 sorozat pixel shader processzorai fizikailag is képtelenek FP32-es módban működni. Az NVIDIA 20 bitnél, míg az ARM 16 bitnél húzta meg a határt.

A programok futtatásának szempontjából a precizitás kiválasztása nem jelent majd gondot, a képminőségre viszont hatással lesz, hiszen nyilvánvaló, hogy 32 bites számábrázolás mellett a számítások eredményei pontosabbak. Hogy ez a gyakorlatban milyen különbségeket hoz, az függ majd az adott programtól. Az öreg motorosok számára körvonalazható, hogy mire lehet számítani, hiszen az NVIDIA a GeForce FX generáció idején pont azzal nyert sebességet a DirectX 9-es alkalmazások alatt, hogy a pixel shaderek feldolgozási precizitását 32 bitről 16 bitre limitálták, ami meg is látszott a képminőségen, ugyanakkor gyorsulást hozott.

Természetesen az egységességre való törekvés a fentiek tudatában némileg defektes, de jobban sajnos nem lehet megoldani.

A DirectX 11.1 működése

Ahhoz, hogy az API a rengeteg hardverhez megfelelő minőségű opció legyen, a Microsoft különböző futtatási szinteket kreált. Ez nem mondható újdonságnak, hiszen az elv már a DirectX 11-ben is bemutatkozott, de az ultramobil grafikus vezérlők azért alaposan összekuszálták a dolgokat, így a DirectX 11.1 egy helyen változtatott a korábban kialakított szinteken. Tömören összefoglalva a lényeget: a Microsoft eltörölte a shader modell 3.0-t az eddig ismert formájában.

Ez nem jelenti azt, hogy a régi játékok, amelyek kihasználják ezt, nem fognak jól futni, ebből a szempontból nem lesz változás. Azonban ha valaki DirectX 11.1-re ír programot, akkor a shader modell 3.0 egyetlen futtatási szinten sem érhető el. Ennek elsősorban az az oka, hogy az ultramobil grafikus vezérlők közül kevés megoldás teljesíti a shader modell 3.0 követelményeit, viszont a DirectX 11-ben a D3D_FEATURE_LEVEL_9_3 szinthez van kötve a több render target (multiple render targets, azaz MRT) egyidejűleg történő leképzésének lehetősége, ami egy fontos funkció. Ahhoz, hogy több ultramobil IGP kerüljön be ebbe a kategóriába, a Microsoft a DirectX 11.1-nél visszavett a shader modellre vonatkozó követelményekből.

A döntésben egyébként nagyon-nagy szerepe volt annak is, hogy a Windows RT-vel ellentétben a Windows 8 operációs rendszer futtathatóságának minimális követelménye a D3D_FEATURE_LEVEL_9_3 szint elérhetősége, így az Intel Atom Z2760-as rendszerchipet mindenképp meg kellett feleltetni ennek az elvárásnak. Gyakorlatilag ezt a lépcsőt addig butították, amíg a tabletekbe szánt Atom IGP-je működőképessé nem vált.

A jobb átláthatóság érdekében a DirectX 11.1-ben elérhető futtatási szintek különbségeit az alábbi táblázatban foglaljuk össze:

Az adatok magukért beszélnek, de talán túl sok információ ez így egyszerre, így természetesen taglaljuk, hogy mi mire szolgál, kiegészítve néhány fontos adattal.

Shader modell: A shader modell ismert fogalom, ami lényegében meghatározza, hogy az adott grafikus processzor milyen mértékben programozható. Minél nagyobb a szám, annál kevesebb a megkötés. Az 5.0-s, 4.1-es és 4.0-s szint gyakorlatilag igen kedvező ebből a szempontból, ahogy a 3.0-s is az volt, de erről fentebb leírtuk, hogy a DirectX 11.1-ben elveszett. A shader modell 2.0 esetében érdemes megjegyezni, hogy D3D_FEATURE_LEVEL_9_3 mellett kevesebb limitációval kell számolni, mint az alacsonyabb szinteken, így ezt a táblázatban jeleztük, de hivatalosan a Microsoft ezt is 2.0-s jelzővel illeti.

Geometry shader: Ez a shader lépcső a DirectX 10-ben mutatkozott be, és geometriai alakzatokkal, azaz több vertexszel képes egyszerre dolgozni. Az alkalmazott kódtól függően másolni, nagyítani, kicsinyíteni tudja őket. Emellett további primitíveket hozhat létre, illetve törölhet vertexeket.

Stream out: Ez a funkció a geometry shaderhez tartozik, és a fejlesztő a segítségével képes lementeni vertex és geometriai adatokat még a raszterizálás előtt.

Compute shader: Ez a shader lépcső a DirectX 11-ben debütált, és alapvetően független eleme a DirectX futószalagnak, de használatával a grafikus processzorok általános számítási teljesítményét sokkal hatékonyabban lehet kihasználni, mint ha az adott effekt specializált shader lépcsőn futna.

Tesszelláció: Ezt a funkciót a DirectX 11-ben sikerült bevetni. Segítségével részletesebb felületek kreálhatók, hiszen az eredeti modell geometriáját több kisebb háromszögre lehet bontani, majd a keletkezett vertexek pozicionálhatók. Működéséről részletesen írtunk az alábbi oldalon.

Gather4 utasítás: Hihetetlenül hasznos funkció, ami a DirectX 10.1-től vált elérhetővé. Használatával egy textúrázó csatorna négy mintával térhet vissza egyetlen mintavételi ciklus alatt. Segítségével a fejlesztők 15-25%-kal is képesek gyorsítani a teljes leképzés sebességét. Érdemes megjegyezni, hogy a Microsoft még ma is csak az utasítás támogatását követeli meg hardveres szinten. Ennek eddig nem sok jelentősége volt, mivel a gyártók értették a funkció lényegét, így a grafikus processzorok textúrázó csatornánként négy mintavételezőt tartalmaztak. Az Intel viszont a HD Graphics 2000, 2500, 3000 és 4000 jelzésű IGP-ken úgy támogatja az utasítást, hogy csatornánként csak egy mintavételezőt építettek be a mérnökök. Az API specifikációja elfogadja ezt az elvet is, de ilyenkor semekkora teljesítménynövekedést nem lehet várni a Gather4 utasítás bevetésétől, mivel a rendszer négy mintával nem egy, hanem négy mintavételi ciklus alatt tér vissza.

BC4/BC5 és BC6H/BC7: Különböző textúratömörítési eljárások.

Occlusion query: Ez az eljárás jelzi, hogy melyik objektum van más objektum által takarásban a feldolgozandó képen. Amennyiben az eltakart objektum nem látszik, felesleges erőforrást pazarolni rá, így azt a rendszer kivágja még a leképzés megkezdése előtt. A DirectX 9-ben egy butább rendszer dolgozott ezen, ahol a központi és a grafikus processzor közösen munkálkodott a feladaton, de az újabb DirectX API-kon már csak a grafikus processzorra terhelődik a munka. Az eljárás egyébként úgy működik, hogy a rajzolás előtt a komplex objektumok helyett először tégla alakú dobozok lesznek elhelyezve, amelyek az objektum adatait hordozzák. A mélységtesztek lefuttatása után azok az objektumok nem lesznek megrajzolva, amelyek nem fognak látszani a végső képkockán.

Alpha-to-coverage: A technika segítségével az átlátszó textúrákon lehetségessé válik az élsimítás. A DirectX 10-ben mutatkozott be, de a DirectX 10.1-ben továbbfejlődött, így gyorsabb és hatékonyabban dolgozó élsimítást készíthettek a fejlesztők az adott problémára.

Logikai operációk: Nevének megfelelően logikai operációkat (és, vagy, kizáró vagy) tesz lehetővé a render targeteken. Némi megkötés, hogy ezeket nem lehet mixelni a blendinggel.

TIR (target independent rasterization): A Direct2D felületre van hatása. Lehetővé teszi, hogy a processzor gyorsabban tesszelláljon, aminek köszönhetően a teljes feldolgozás sebessége nő, hiszen a grafikus processzor is gyorsabban kapja meg a rajzolási instrukciókat.

UAV (unordered access view): A DirectX 11 vezetett be a futószalag pixel, valamint compute shader részére. Segítségével az általános és strukturált adatpuffereket lehet kezelni, ezen belül is gather operációval olvasható, vagy scatter operációval írható a tartalmuk, akár párhuzamosan. 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. Egyidejűleg írni és olvasni csak egyetlen formátumot lehet (single uint32).

RT (render target): Képkockára vonatkozó adatpufferek, melyek a leképzéshez szükséges adatokat tartalmazzák.

Mit támogat a PC-m?

[+]

A DirectX 11.1-es API esetében az adott számítógép által támogatott futtatási szintek nagyon egyszerűen ellenőrizhetők. A Windows 8 és RT operációs rendszeren a keresésénél be kell írni a „dxdiag” parancsot, és a megjelenő ikonra kell kattintani. A felugró ablakon a „display” fület kiválasztva megjelennek a grafikus adapter paraméterei. A „Feature Level” pontnál látható, hogy az adott termék mely szinteket kezeli. Erről mi is készítettünk egy képet.

Mi az, hogy opcionális?

Az előbbi oldalon található táblázatban elvétve az opcionális szó is szerepel, ami furcsa lehet az olvasók számára. A DirectX 11.1 ugyanakkor a logikai operációk szempontjából csak a legmagasabb futtatási szinten követeli meg a tényleges támogatást, míg alacsonyabb szinteken erre csak lehetőség van. Itt jön az a pont, ahol az új API igen érdekes újítást is bevezet, azaz a korábbi gyakorlattal ellentétben, amikor a Microsoft minden specifikációt kőbe vésett, alapvető rugalmasságot is ad a fejlesztők és a gyártók kezébe.

Szerencsére ezt kulturált módon teszi, így a DirectX 10-ben bevezetett érvényesítési metódus megmaradt, vagyis az erőforrást elég a program elején ellenőrizni, és a kapott adatok alapján a megfelelő kód futtatható a rendszeren. Az opcionális funkciók esetében az egész folyamat ugyanígy zajlik, csak a program még rákérdez, hogy az adott konfiguráció esetleg támogatja-e a logikai operációkat. Ha igen, akkor minden a legnagyobb rendben, míg ha nem, akkor az adott effekt esetleg nem fut le, vagy ha van alternatív kód rá, akkor szimplán csak lassabban fog futni.

A DirectX 11.1 erre az újításra igen komolyan épít, így a Microsoft olyan funkciókat is beépíthetett az API-ba, amelyeket nem támogat minden gyártó. Ezeket az alábbi táblázat foglalja össze:

Szokás szerint érdemes kifejteni, hogy mi mit jelent, hiszen esetenként nem olyan egyértelmű ez.

SAD4 (sum of absolute differences) utasítás: Az AMD vezette be még a Radeon HD 5000 sorozattal, és azóta minden megjelent termék támogatja. Alapvetően egy képfolyamok feldolgozásában sűrűn használt és igen egyszerű algoritmusra épül, használatával meg lehet állapítani a különböző képtartalmak között a hasonlóságot. A Microsoft minden bizonnyal ezt a funkciót az új generációs Kinect szenzor miatt vette fel a DirectX API-ba, hiszen drámaian felgyorsítható vele a képfolyamokon a mozgás felismerése.

Conservative depth: Lényegében a raszterizálás irányítását teszi lehetővé, vagyis a fejlesztő egy olyan pixel shadert írhat, ami manuálisan kiértékeli az adott képponthoz tartozó mélységértéket. Az API két paramétert kínál erre. Az SV_DepthGreater arra szolgál, hogy a számítások legyenek elhagyva, ha a kinyert mélységérték nagyobb a mélységpufferben szereplő adatnál, míg az SV_DepthLessEqual akkor veti el a kalkulációt, ha a mélységérték kisebb vagy egyenlő a mélységpufferben tárolt információhoz képest.

Gyakorlatilag az eljárás alkalmazásával a GPU a felesleges számítások alól menti fel magát, mivel a conservative depth mellett végrehajtható egy irányított mélységteszt, ami ott vezet eredményre, ahol a hagyományos SV_Depth paraméter már nem képes meghatározni, hogy mely képpontok esetében érdemes elhagyni a további számításokat. Az eljárás jó eredményeket tud felmutatni, ugyanis a mérések szerint a conservative depth alkalmazása – függően a jelenet komplexitásától – 5-20%-os teljesítménynövekedést eredményezhet a hagyományos feldolgozáshoz viszonyítva.

Ez az opcionálisan támogatható technika úgy lett megoldva, hogy ne legyen szükség a program futtatásakor a rendszer megkérdezésére a funkció elérhetőségéről. Ennek hála a régebbi DirectX 10-es Radeonok is profitálnak belőle, ha a driver képes kezelni a megfelelő paramétereket. Az sem baj, ha az adott hardver nem támogatja a funkciót, mivel a Microsoft engedi a driveres emulációt, ami nem hoz magával sebességnövekedést, de az adott program működésére nincs hatással, vagyis az eredmény ugyanaz lesz.

Dedikált atomi számláló: A DirectX 11 vezette be az atomi számlálókat, melyeket opcionálisan lehetőség van dedikált hardverrel támogatni. Az AMD ezt a Radeon HD 5000 sorozat óta meg is teszi, így a termékek helyi adatmegosztásért felelős memóriájában megtalálhatók ezek a feldolgozók. Az atomi számlálóval a shader írhat egyedi offseteket az úgynevezett append pufferekbe és olvashat a consume pufferekből. Ez nagyon hatékonyan használható a különböző PPLL (per-pixel linked list) adatstruktúrára épülő effektekhez. Dedikált feldolgozók mellett természetesen az elérhető atomi számlálók korlátozottak, de ha ezek kifogynak, akkor még mindig ott van az alternatív (API szempontjából alapértelmezett) mód, mely rengeteg atomi számlálót ad. Ez természetesen hatványozottan lassabb is.

Dupla pontosság: Ez magától értetődik. Gyakorlatilag arról van szó, hogy a rendszer 64 bites lebegőpontos precizitással számolhat a jellemzően használt 32 bites helyett. A DirectX 11.1 a compute shader kódok mellett már a pixel shader lépcsőn is kihasználhatóvá teszi ezt az extra tudást. Ugyanakkor a játékok szempontjából ennek nincs, és várhatóan nem is lesz jelentősége a jövőben, mivel a fejlesztők nagy többsége már az FP32-es precizitást is elég pontosnak tartja.

Sztereó 3D: A Microsoft a DirectX 11.1-ben bevezette a sztereó 3D hivatalos és egyben szabványos támogatását is, ami már nagyon ráfért erre a széttördelt területre. A redmondi vállalat itt tulajdonképpen egy fejlesztőkörnyezetet kínál, mellyel natív sztereó 3D támogatás építhető az adott programba. Technikailag túl komoly követelmény nincs, így az AMD HD3D-t, az NVIDIA 3D Visiont és az Intel InTru 3D-t kezelő termékek megfelelnek a célra. Természetesen az adott gyártónak gondoskodnia kell a driveres támogatásról is, de ezt már mindenki megtette. Ezen a ponton a játékfejlesztőknél van a labda.

Rugalmas újítások

Az előző oldalakból kiderült, hogy a Microsoft megpróbálta a gyártók igényeit és a termékek képességeit figyelembe véve megalkotni a DirectX 11.1-et, de volt még egy jelentős probléma, amit meg kellett oldani. Nevezetesen az ultramobil grafikus vezérlők megfelelő kezeléséről van szó. Korábbi cikkünkben már részleteztük, hogy ezek mennyire különbözhetnek a PC-s társaikról, így egységesen támogatni az összes hardvert igen nehéz feladat.

A DirectX 11.1 először is bevezetett egy új szolgáltatást. Ez egy általánosan kihasználható paraméter, amivel a program a futtatás elején lekérdezheti, hogy a hardver milyen elven dolgozik. Ezt a D3D11_FEATURE_DATA_ARCHITECTURE_INFO struktúra használatával lehet megtenni. Amennyiben egy alkalmazást a fejlesztő kellő körültekintéssel ír meg (az eltérő elven működő hardvereket figyelembe véve), akkor az új API-val lehetőség van arra, hogy a program minden hardveren megfelelő hatékonysággal fusson. Fontos, hogy ez az újítás nem csodafunkció, ami bármilyen kódot tökéletesen futtat a különböző elvű leképzést használó architektúrákon, viszont segítségével kifejezetten egyszerűen optimalizálható az alkalmazás a piacon található igen eltérő hardverekre.

Kiterjesztésben a jövő?

A DirectX 11.1 egyik leglényegesebb újítása is kapcsolódik az ultramobil grafikus vezérlők megfelelő működéséhez. 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 az adott hardver támogatja-e. Nyilván utóbbi megoldás az erőforrás érvényesítésére nem jó, így egy jobban működő rendszert kellett kialakítani.

Az egész ú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 mondanunk 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, lesznek opcionálisan támogatható gyári funkciók, és ezekhez 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 direkten kezelni 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 a jövőben, feltéve, hogy az adott hardver megfelel a célnak. A kiterjesztések beépítése egyébként nem olyan egyszerű, mint például az OpenGL esetében. A fejlesztők számára természetesen barátságos ez a rendszer is, de a hivatalos frissítést csak a Microsoft végezheti el. Ez azt jelenti, hogy a redmondi óriáscég időről-időre frissíti majd a DirectX 11.1-es API-t, amikor az általános javítások mellett az újabbnál-újabb kiterjesztések is beépítésre kerülnek. Arról sajnos nincs adatunk, hogy milyen időközönként lehet számítani frissítőcsomagokra.

Aminek a fejlesztők nagyon örülnek

Lényeges újítás a DirectX 11.1-en belül a kényszerített mintaszámítás lehetősége a raszterizáló státusz készítésénél, illetve a 64 kB-nál nagyobb constant pufferek létrehozásának lehetősége. Bár a shaderek ebből továbbra is csak 64 kB-os részt érhetnek el, a kiegészítés mindenképp kedvező a programozóknak, mivel mostantól igen nagy constant puffereket is létrehozhatnak. Korábban vagy többet kreáltak, vagy megpróbáltak a limiten belül maradni.

Megjelent egy úgynevezett shader trace interfész is az új API-ban, amire a fejlesztők már régóta vártak. A DirectX 11-ben bevezetett compute shadernek mindenki örült ugyan, de sajnos nagyon nehéz volt debuggolni a kódot, ami azt is jelentette, hogy a mai játékokba épített compute shaderek többségét nem pont a játékfejlesztők, hanem inkább a gyártók készítették. Itt alapvetően nem a tudás hiányzik a programozók oldalán, hanem az idővel van gond. A kiadók ugyanis nem szeretik az adott játék megjelenését eltolni, főleg nem egy szimpla grafikai effekt miatt.

Sajnos már egy adott effektek kutatása is időigényes, a compute shader alkalmazhatóságának bekalkulálása pedig ezen még tovább ront. A gyártóknak azonban bőven van idejük, és így alakulhatott ki az a norma, hogy a fejlesztők inkább belépnek egy gyártói partnerprogramba, ahol hozzájuthatnak kész algoritmusokhoz, amivel időt nyernek, és az effekteket is be tudják építeni.

Az új shader trace interfész ugyan nem oldja meg a fejlesztők minden gondját, de nagyságrendekkel leegyszerűsíti a compute shaderek debuggolását, ami összességében kedvező a programozóknak, hiszen még gyorsabban dolgozhatnak, így egyre több effektet gyorsíthatnak fel a modern compute képességek kihasználásával. Ennek köszönhetően a programok gyorsabban futhatnak.

A shader trace interfész használatának előnye, hogy csak a fejlesztéshez szükséges Windows 8, így a véglegesen kiadott program az egyszerűbb debuggolás előnyeit a korábbi Windows 7 és Vista operációs rendszeren is kamatoztathatja.

Mindez a gyakorlatban

Az elmúlt négy oldalon elég sok elméleti adat hangzott el, így ideje némi gyakorlati jelleget is adni a cikknek. Az API működése ugyanis nem feltétlen ültethető át egy program működésére. Ez alatt azt értjük, hogy a fejlesztő dönt arról, hogy az adott alkalmazás milyen futtatási szinteken működhet. Ha a DirectX 11.1-es API-t támogatja az alkalmazás, akkor ki kell jelölni, hogy a program mely futtatási szinteken üzemképes. Akár mind a hét kijelölhető, de lehet például csak egyet is választani. Erről mindig az adott program fejlesztője dönt, annak tudatában, hogy mit tartalmaz a forráskód.

A driverek oldalán az API bizonyos futtatási szintjének támogatása sem jelenti azt, hogy a rendszer automatikusan támogatja az alatta lévő szinteket is. Például az Intel HD Graphics családba tartozó grafikus vezérlői a D3D_FEATURE_LEVEL_9_2 és D3D_FEATURE_LEVEL_9_3 szinteket nem ismerik. Ezt később pótolni lehet, hiszen szoftveres korlátozásról van szó, és ajánlott a támogatást beépíteni, mivel van esély rá, hogy egy alkalmazás futtathatóságát csak az említett szinteken engedi a fejlesztő, amivel kvázi kizárja az Intel megoldásait, még ha azok elvben képesek is működni.

Ez a gond egyébként inkább csak elvi szinten létezik, mivel a fejlesztők a gyakorlatban csak azokat az alacsonyabb futtatási szinteket tiltják, amelyeken az adott program már képtelen működni. Például ha egy alkalmazást D3D_FEATURE_LEVEL_9_3 szintre terveztek, de működik D3D_FEATURE_LEVEL_9_2 szinten is, akkor szimplán letiltják a D3D_FEATURE_LEVEL_9_1 szintet. Viszont felső korlát nem lesz, így az újabb termékek a D3D_FEATURE_LEVEL_10_0 vagy magasabb szinteken üzemelhetnek. Persze a fellelhető extra képességeket nem használják ki, de tökéletesen működőképes lesz a kód.

Az előbbi bekezdésben taglalt elvet egyébként amúgy is ajánlott követni, mivel a DirectX 11.1-ben megfeleltetett három legalacsonyabb futtatási szint csak alrétegként van jelen az API-ban. Ez egyrészt jó, mert biztosítja a tökéletes kompatibilitást, másrészt rossz, mert a natív DirectX 9-es kódnál lassabb sebességet kínál. Ennek megfelelően értelmetlen csak ezekre korlátozni egy program futtathatóságát.

Hol hasznos a DirectX 11.1?

Az új API alapvető előrelépés a fejlesztőknek. A Windows 8-on írt DirectX 11.1-gyel kompatibilis alkalmazás tökéletesen működőképes lesz Windows 7 operációs rendszeren is, így a felhasználóknak sem kötelező a váltás. Az első beszámolók alapján a programozókat főleg az általános újítások érdeklik, így számos készülő játék képes lesz a címtérnek megfeleltetni a dinamikus pufferek SRV-it (shader resource views), illetve a dinamikus constant puffereket a D3D11_MAP_WRITE_NO_OVERWRITE funkcióval. Ez az optimalizálás csökkenti a CPU-ra helyezett terhet, és ebből az előzetes mérések szerint átlagosan 10% gyorsulás nyerhető, ha Windows 8 operációs rendszer van az adott DirectX 11-es vagy 11.1-es API-t támogató grafikus processzort használó gépen. Mivel ennek a funkciónak az implementálása nagyon egyszerű, így úgy gondoljuk, hogy majdnem minden új motorban megtalálható lesz, hiszen az extra sebesség mindig jól jön.

A legfőbb kérdés viszont talán azzal kapcsolatban merül fel, hogy az API D3D_FEATURE_LEVEL_11_1 szintjében bevezetett újításokkal mit lehet kezdeni. A játékok szempontjából a támogatott UAV-k száma és azok minden shader lépcsőn való elérhetősége lehet fontos.

Korábban már szerepelt a táblázatban, hogy a legmagasabb szinten 64, míg egyel lejjebb 8 UAV kreálható. Nos, utóbbi kevés. Ezt onnan lehet tudni, hogy a fejlesztők már ma is szoktak úgynevezett virtuális UAV-kkel dolgozni, hogy túllépjék az említett korlátot. Ez az ötlet egy ideje működik, csak körülményes alkalmazni és lassú is, ráadásul ez is limitált valamilyen szinten, mivel 16 384x16 384 pixeles textúrába kell bezsúfolni az adatokat. A több UAV-nek sok helyen lehet haszna. Például a fejlesztők által nagyon kedvelt mélységélesség effekt esetében sok kutatás zajlik olyan egy fázissal dolgozó implementációért, amely jó minőséget kínál. A kutatásoknak hamarosan tényleges eredménye lesz, és a mélységélesség az újabb DirectX 11.1-es játékokban jobb implementációt kaphat, ami a legmagasabb futtatási szinten számottevően gyorsabban is lefuthat.

Az UAV-k elérhetősége is újításokra ad lehetőséget. A DirectX 11-ben csak a pixel és a compute shader használhatta ezeket az általános adatpuffereket, ám a DirectX 11.1 esetében már minden shader lépcsőről alkalmazhatók. A hull és a domain shader ebből a szempontból annyira nem érdekes, mivel ezek a tesszellátorhoz tartoznak, illetve annak a munkáját egészítik ki, vagyis túl sok hasznuk nem származna az UAV-k elérhetőségéből. Igazából nagyon erőltetett dolgokra lehetne használni, így például a hull shader esetében a tesszelláció debuggolására, míg a domain shader lépcsőn amolyan stream out funkciót láthatna el. Utóbbi még hasznos is lehet, ha esetleg pár kimentett adatra szükség van a későbbiekben, és a program nem használ geometry shadert. A kérdés, hogy miért ne használna, hiszen az API lehetővé teszi, és a fejlesztőknek sem kedvező, ha csak a legmodernebb hardverekhez kötnek olyan dolgokat, amiket a régebbiek is meg tudnának oldani más feldolgozási forma mellett.

A vertex shader lépcső már érdekesebb az UAV-k szempontjából. A legkézenfekvőbb felhasználási terület az lehet, ha a fejlesztő LOD információkat akar nyerni a következő képkockára. Az UAV-k segítségével az előző képkockáról származó információk alapján meghatározható az új képkockán a geometria LOD szintje. Gyakorlatilag az előző képkocka kimentett információiról azonnali LOD szintet lehet beállítani bármilyen objektumra. Ezzel időt lehet nyerni, vagyis összességében gyorsulhat a feldolgozás. Ez a megoldás azonban AFR elvű feldolgozás mellett hátrányos lehet, vagyis a CrossFireX és az SLI konfigurációknál, mivel adatot kell másolgatni a grafikus processzorok között. Ezt természetesen meg lehet oldani, de biztosan ront az AFR-elven működő rendszerek hatásfokán.

A geometry shader tűnik az UAV-k szempontjából a legérdekesebbnek, és valószínűleg a legtöbb kutatás is ezt a területet célozza majd meg. Ezek közül az irregurális mélységpuffer teljesen GPU-n dolgozó implementációja lehet majd a figyelem középpontjában, mivel a technika kivitelezhetőnek tűnik a geometry shader lépcső adatai alapján.

Klasszikus és irregurális mélységpuffer

Az irregurális implementáció funkcionálisan úgy működik, mint a klasszikus mélységpuffer, azaz meghatározza, hogy a kamera szemszögéből mely geometriai elemek látszanak. Ez tulajdonképpen a leképzés legfontosabb szakasza. A hagyományos elvhez képest az irregurális megoldás annyival körszerűbb, hogy nem egyenletesen, hanem tetszőlegesen elhelyezett mintavételi pontokkal dolgozhat.

Klasszikus és irregurális mélységpuffer shadow mapping mellett [+]

Maga az eljárás régóta ismert, de a DirectX API-n keresztül most nyílik először lehetőség rá, hogy csak a grafikus processzor erejére támaszkodva megoldható legyen a feladat. Ahol ez hasznos lehet, az a shadow mapping, ami a mai hardverek mélységpufferét használja a komplex jelenetek árnyékolásának megoldására, mindezt rendkívül gyorsan. A rendszer tipikus problémája azonban, hogy az árnyéktérképen – ami hardveres megvalósítás mellett a mélységpuffert jelenti – a mintavételi pontok egyenletesen vannak kijelölve. Ennek köszönhetően a végső képkockán látható árnyékok széle úgymond recés lesz, ami sosem kedvező.

Klasszikus és irregurális mélységpuffer eredménye

Számos algoritmus született már ennek a jelenségnek a redukálására, hiszen alapvetően nagy problémáról van szó. Az irregurális shadow mapping egy rendkívül hatékony technika a gondokra, hiszen segítségével az árnyéktérképen tetszőlegesen kijelölt mintavétel is végrehajtható, így a végső képkockán megjelenő árnyék jó minőségű lesz.

Mit is támogatnak a PC-s hardverek?

Az előbbiek alapján leszűrhető, hogy a DirectX 11.1 nem éppen a megszokott átláthatóságot hozza, és ez nagymértékben köszönhető annak, hogy kibővült az ultramobil grafikus vezérlőkkel a támogatott hardverek sora, illetve visszakerültek a gyártói kiterjesztések a rendszerbe. Ebből a szempontból a hardverek által támogatott extrák is nagy szerephez juthatnak, hiszen az OpenGL-hez hasonlóan ezek opcionálisan kihasználhatók. Információink szerint minden cég dolgozik kisebb-nagyobb fejlesztéseken.

Sajnos arról a Microsoft nem tájékoztatott minket, hogy konkrétan mi várható, ugyanis a cég állítása szerint nincsenek felhatalmazva arra, hogy a gyártók egyedi kiterjesztéseit idő előtt leleplezzék. Azt azonban megtudtuk, hogy a vállalat kifejezetten azokat a kiterjesztéseket szorgalmazza, amelyeket több mai hardver is támogathat. Ez sokszor lehetetlen feladat, de azért vannak kivételek is. 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ó (egészen pontosan 1 048 576 darab) 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). A két vállalat készíthet egy-egy különálló, vagy akár egy közös kiterjesztést erre (ez lenne a logikus), mivel é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 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 rendkívül értékes tulajdonság.

A PC-s hardverek

A legmagasabb D3D_FEATURE_LEVEL_11_1 szintet jelenleg csak az AMD GCN architektúrája támogatja, így a DirectX 11.1 összes szolgáltatását csak az említett architektúrára épülő Radeon HD 7000-es és 8000-es megoldások képesek kihasználni.

A kiterjesztések szempontjából a GCN architektúra igazából sok kérdést vet fel. Technikai szinten a rendszer képességei messze túlteljesítik az API összes kötelező és opcionális követelményét. Az AMD a rendszert úgy tervezte, hogy ne kelljen limitálni a létrehozható UAV-k és SRV-k számát, illetve az UAV-k esetében ne csak az uint32 formátum legyen írható és olvasható, hanem lényegében mindegyik. Ezekre nem lesz kiterjesztés, hiszen a shader modellbe komolyabban belenyúlni nagyon nem célszerű. A Microsoft minden bizonnyal a következő DirectX API-ban majd megköveteli az előbbi funkciókat, hogy a PC-s hardverek a lehető legjobban igazodjanak az új generációs konzolok képességeihez, azaz ne legyen túl nagy a PC lemaradása. Persze felvetődhet a kérdés, hogy miért nincs ez már most megoldva. Erre a válasz gyakorlatilag annyi, hogy a GCN-es Radeonokon kívül semmi sem lenne képes támogatni a rendelkezésre álló erőforrások és mintavételezések végtelenítését, márpedig alapvetően az a célja az API-nak, hogy egységes rendszert kínáljon a termékek programozásához. Később, amikor az NVIDIA és az Intel, illetve nyilván a többiek is kifejlesztettek egy megfelelő architektúrát, akkor már érdemes eltörölni az aktuálisan felállított korlátok egy részét.

[+]

Ami a GCN-hez készített kiterjesztésekben valószínűleg fel fog tűnni, az a PRT (Partially Resident Textures) eljárás támogatása, illetve jó esély van arra, hogy az architektúrában támogatott új stencil műveletek is kihasználhatók lesznek DirectX 11.1-ben. Ami biztos, hogy az AMD-től már elérhető egy úgynevezett depth bounds testing kiterjesztés, ami vélhetően hamarosan bekerül majd az API-ba, és valószínűleg mindegyik gyártó támogathatja, hiszen nincs igazán különleges hardveres követelménye. Ez a kiterjesztés egyébként nagyon hasznos, mivel felesleges munkától kíméli meg a rendszert.

Az eljárás úgynevezett scissor (olló) és az alfa teszt közé ékelődik be. A lényege abban rejlik, hogy a megadott maximális és minimális mélységértékek alapján minden olyan pixeladatot figyelmen kívül hagy, aminek a mélységértéke a meghatározott intervallum alatt vagy fölött lesz. Ez az optimalizálási forma egyébként része volt már a DirectX 9-nek az NVIDIA korábbi kiterjesztésének hála, de a DirectX 10-ből kikerült, de most úgy néz ki, hogy visszatér. Az eredménye lényegében a gyorsabb feldolgozásban nyilvánul majd meg.

A Fermi és Kepler architektúrára épülő NVIDIA GeForce termékek a D3D_FEATURE_LEVEL_11_0 szintet kezelik, vagyis a DirectX 11.1-gyel nem kompatibilisek, ettől függetlenül azért a logikai operációkat képesek kezelni. Érdekesség, hogy funkcionális értelemben a GeForce-ok a többi DirectX 11-es hardverhez hasonlóan képesek elérni az UAV-ket minden shader lépcsőn, de ezt a tudást a DirectX 11.1-ben lehetetlen kihasználni, ha nincs legalább 64 darab UAV támogatva. Itt persze ez lehet egyfajta koncepció is, hiszen nyolc UAV a teljes futószalagra igen kevésnek hangzik, de nem kizárt, hogy van olyan feladat, ahova elég lenne, vagyis a Microsoft ezt jobban is megoldhatta volna, gondolva a kevésbé modern architektúrákra.

Az Intel a készülő Haswell termékek Gen7.5-ös architektúrájú IGP-jével támogatja majd a D3D_FEATURE_LEVEL_11_1 szintet, és még két kiterjesztést is bedobnak a közösbe, melyekről korábban már írtunk. Ezek eléggé specifikusnak tűnnek, így direkt támogatás a konkurensek oldaláról valószínűleg nem lesz. Az Intel újításai közül a PixelSync tűnik érdekesebbnek. Ez egy igen jó technika az OIT (Order Independent Transparency, azaz sorrendtől független átlátszóság) kezelésére, mivel az AMD által kínált szabványos OIT implementációnál számottevően gyorsabb. Persze a fejlesztőket meg kell majd győzni a támogatásáról, hiszen nyilván minden szempontból a szabványos megoldás van előnyben, de opcionálisan bármilyen alternatív opciót be lehet építeni egy adott problémára. Ezt talán meg is teszi majd a programozók egy része, mivel az AMD OIT technikája nagyon a Radeonoknak kedvez, viszont előnye, hogy a többi szabványos megoldáshoz képest sokkal gyorsabban dolgozik. Mindenesetre a PixelSync vagy egy hasonló rendszer a problémára mindenképp kedvezőbb, így a következő DirectX-ben érdemes lenne kötelezővé tenni a támogatását.

Mit is támogatnak az ultramobil hardverek?

Az ultramobil grafikus vezérlők közül a Windows RT-n a Tegra 3 GeForce ULP IGP-je a legelterjedtebb. Nos, ez a rendszer és a Tegra 4 IGP-je is a D3D_FEATURE_LEVEL_9_1 szintet támogatja a pixel shader programokban, 20 bites feldolgozási precizitással. Ez nem sok, de a minimum követelményeket teljesíti. A később érkező Tegra 5 kínál majd nagyobb technológiai ugrást, mivel ez a fejlesztés már a Kepler architektúrát örökli.

A Windows RT piacának másik nagy versenyzője a Qualcomm szeretne lenni. Egy RT-s tablet már használ is Adreno 225-ös IGP-t, ami megfelelő a D3D_FEATURE_LEVEL_9_3 szinthez. Az újabb lapkákban dolgozó Adreno 320 és 330 technikai tudás szempontjából nem sokat fejlődött, így a DirectX támogatási szintje nem változott. Érkezik azonban az Adreno 400-as generáció, melyről annyit már biztosan tudni, hogy megfelel a D3D_FEATURE_LEVEL_11_1 szintnek.

A harmadik cég, amely támogatja a Windows RT-t, az az Imagination Technologies. Sajnos a PowerVR IGP-k terméktámogatásáról nem lehet túl sok jót mondani. Nem is épül erre a rendszerre Windows RT-s tablet, hiszen a gyártók számára csak probléma lenne belőle. Az Intel azonban az Atom Z2760 esetében PowerVR SGX 545-ös IGP-t használ, amin sajnos nagyonis meglátszik a grafikus driver kiforratlansága. Erről már sokszor írtunk, így most kifejezetten a DirectX támogatásra térünk ki. Az architektúra elméletben képes támogatni a D3D_FEATURE_LEVEL_10_1-et, de a meghajtó ebből csak a Windows 8 minimum követelményeként igényelt D3D_FEATURE_LEVEL_9_3 szintet teljesíti. A pixel shader programok feldolgozási precizitását is 16 bitre redukálták az elméletben támogatott 32 helyett. Erre valószínűleg azért volt szükség, mert a régebben megjelent PC-s játékoknak eleve nem fekszik a hardver működése, így felesleges tovább rontani az amúgy is gyászos sebességen.

Az Imagination Technologies minden reménye a PowerVR Series6 termékcsaládban van, amit már sok szempontból a DirectX API-hoz terveztek, így a D3D_FEATURE_LEVEL_11_0 szintet támogatja. Természetesen a szoftveres csapatnak is több figyelmet kell erre a területre fordítania. Ebből a szempontból pár rosszul sikerült Atom platform miatt nem írnánk le a céget, de a következő körben tényleg mutatni kell valami ütőset. Ezt persze már nem az Atomban fogják megtenni.

Valószínűnek tartjuk, hogy az ARM is megcélozza a Windows RT-t a saját Mali-T600-as sorozatú grafikus vezérlőivel. Ez a rendszer rendkívül fejlett, így teljesíti a D3D_FEATURE_LEVEL_11_0 szint követelményeit, és a feldolgozás precizitása is 32 bites lehet. Valószínűnek tartjuk, hogy az ARM azért nem lépett eddig, mert a Windows RT-t kiforratlannak tartották, így minden bizonnyal megvárják az első frissítést. Ez az eladások alapján jó döntésnek bizonyult.

Konklúzió

Direkten bírálni nem szeretnénk a DirectX 11.1-et, hiszen túl komplex dolog ez ahhoz, hogy egy plecsnivel eldöntsük az értékét. Az új API gyakorlatilag minden szempontból jobb, mint elődje, és értékes funkciók kerültek bele. Az egységesség is rendben van, már amennyire ez elvben megoldható a rendkívül eltérő hardverek támogatása szempontjából, a kiterjesztések visszahozásáért pedig jár a piros pont.

Összességében az API nagyon tetszetős képet fest, amire a fejlesztők is felfigyeltek, így már készülnek a DirectX 11.1-et is kihasználó játékok és programok.

Abu85