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:
| Opcionális DirectX 11/11.1 funkciók | AMD Radeon | NVIDIA GeForce | Intel HD Graphics |
|---|---|---|---|
| SAD4 támogatás | van | nincs | nincs |
| Conservative depth támogatás | van | emuláció | emuláció |
| Dedikált atomi számláló | van | nincs | nincs |
| Dupla pontosság támogatása | hardverfüggő | hardverfüggő | nincs |
| Sztereó 3D támogatása | van | van | van |
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.
A cikk még nem ért véget, kérlek, lapozz!
