Minden, amit a DirectX 11.1-ről tudni kell

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 cikk még nem ért véget, kérlek, lapozz!

Azóta történt

Előzmények

Hirdetés