DirectX 11

A DirectX 11-be a Microsoft számos új funkciót épített be, melyekkel további sebesség nyerhető. A fejlesztők beszámolója szerint a tesszellátor a legfontosabb újítása a rendszernek, ám komoly lehetőségek vannak a compute shaderben is. Előbbi eljárást már a fentebb linkelt cikkben teljesen kiveséztük, így koncentráljunk az utóbbi funkcióra. A compute shader segítségével a programozók olyan programokat írhatnak, melyek a grafikus processzor erejét általános számításokra hasznosítják. Természetesen a programok és a fejlesztői platformok folyamatosan érkeznek majd a gyártófüggetlen rendszerre. A cikkünk fő témája azonban a grafika fejlődése, így elsősorban a funkció képminőségre vonatkozó hatásait vizsgáljuk.

A DirectX 11 futószalagján a compute shader a pixel shader úgymond független mellékágának tekinthető. Ez gyakorlatilag azt jelenti, hogy a grafika szempontjából a majdnem kész képen lehet vele módosításokat végrehajtani. Tulajdonképpen mondhatjuk azt, hogy az egyes pixel shader kódokat mostantól érdemes compute shaderben írni, hiszen maga a programnyelv számos előnyös újítást kínál, továbbá visszafelé kompatibilis egészen a DirectX 10-es kártyákig. Itt azonban meg kell jegyezni, hogy az egyes funkciók között különbségekkel kell számolni. Erről az alábbi táblázat ad felvilágosítást:

A compute shader 5.0 legnagyobb előnyének a helyi feladatmegosztás (Local Data Share) számít, ami a különböző folyamatszálak közötti memóriamegosztást teszi lehetővé. Ezzel a megoldással a textúrázó csatornák több esetben is felmenthetők a munka alól, hiszen jó esély van rá, hogy a szükséges adat egy korábbi mintavételezés alkalmával létrejött. A felesleges munkától megkímélve a rendszert az algoritmusok számítási sebessége akár a háromszorosára is gyorsítható. Ez a teljes képkockára levetítve 15-25%-os gyorsulást jelenthet a DirectX 10.1-es módhoz képest. Itt fontos megjegyezni, hogy a compute shader 4.1 és 5.0 támogatja a Gather4 utasításokat is, amelyekről már tudjuk, hogy egy mintavételből négyszer annyi adatmennyiséget generálnak. Ez majdnem négyszeres gyorsulás a DirectX 10-es kódhoz képest, ami a gyakorlati tapasztalatok alapján 20-25%-kal sebesebb képkocka-feldolgozást eredményez. A párhuzamosan futtatott szálak száma is megnőtt a DirectX 11-ben, így ezen a fronton is lehet nyerni némi teljesítményt.

A compute shader természetesen nem csak sebességben előnyös. Az atomi műveletek alkalmazása nagymértékben megkönnyíti a fejlesztők munkáját, továbbá rengeteg programszál problémamentes futtatását teszi lehetővé. Az atomi műveletek bevezetésére már régóta várnak a programozók, ugyanis a grafikus processzorok rengeteg, mondhatni több száz programszálat futtatnak párhuzamosan. Ilyen körülmények mellett aránylag sűrűn előfordulhat az az eset, amikor egy vagy több programszál ugyanazt a változót próbálja kezelni, vagy azonos memóriacímet kísérel meg elérni. Ezek a problémák természetesen hibás feldolgozást eredményezhetnek az úgynevezett korrupt adatok miatt. Ilyen esetben a programozónak át kellett alakítania az egyik algoritmust, hogy elkerülje a jelenséget, rosszabb esetben pedig soros műveletvégzést kellett alkalmazni a megosztott változók, illetve a memória eléréséhez. Utóbbi elgondolás természetesen hatalmas probléma, hiszen kiüti a párhuzamos feldolgozást, ami esetenként komoly teljesítményveszteséget eredményez. Az atomi műveletekkel lehetőség van az előbbi problémát úgy kezelni, hogy a párhuzamos feldolgozás megfelelően legyen végrehajtva.

Aminek mindenki örülni fog

A DirectX 11 az első API, amelyik támogatja a többszálú feldolgozást, azaz az objektum megrajzolásához szükséges rajzolási parancsok és az effektek létrehozásánál bekövetkező állapotváltások már nem csak egyetlen processzormagon lesznek végrehajtva. Az új rendszer természetesen a régebbi, minimum DirectX 10-es grafikus kártyák mellett is működik, csupán egy szoftveres frissítés szükséges. A funkciót az AMD és az NVIDIA már korábban beépítette a Windows 7 és Vista operációs rendszerekre telepíthető driverekbe. Érdemes megjegyezni, hogy a többszálú feldolgozást a DirectX 11-es kódhoz optimalizálták, így a hatékonyság szempontjából a régebbi rendszerek némi hátrányt szenvednek.

Nincs ellenérv

A Microsoft szerint a DirectX 10-nek egy hibája volt: nem kompatibilis a DirectX 9-cel. Ennek köszönhetően a fejlesztőnek gyakorlatilag két API-t kellett támogatnia. Ezenkívül érdemes megjegyezni, hogy az API nem volt elérhető a jó öreg Windows XP-re, és a Vista sem terjedt megfelelő mértékben, ami a legtöbb programozót választás elé állította. Nos, a DirectX 11 a WDDM (Windows Display Driver Model) hiányában továbbra sem telepíthető XP-re, azonban a fejlesztők problémáját megoldotta a redmondi óriáscég. Az új API ugyanis hat futtatási szintet támogat:

• D3D_FEATURE_LEVEL_11: értelemszerűen ez a szint mindent tud, így nincsenek korlátozások.
• D3D_FEATURE_LEVEL_10_1: DirectX 10.1-es kártya esetén jön létre.
• D3D_FEATURE_LEVEL_10: a DirectX 10-es kártyával ebben a módban fut a kód.
• D3D_FEATURE_LEVEL_9_3: a shader modell a 3.0-s kártyákat támogatja, azaz ideális a GeForce 6 és 7, valamint a Radeon X1000 szériához.
• D3D_FEATURE_LEVEL_9_2: speciális szint, kifejezetten a shader modell 2.0-s Radeon termékekhez.
• D3D_FEATURE_LEVEL_9_1: az összes fentebb nem említett DirectX 9-es grafikus chip ide tartozik, beleértve a GeForce FX-et is.

Az előbb tárgyalt hat erőforrás automatikusan, a program indulásakor jön létre a számítógépben talált hardvernek megfelelően. Ez azt jelenti, hogy a programozónak elég a DirectX 11-es kódot megírni, és az API minden mást kezelni fog, azaz a kódban szereplő nem kompatibilis utasításokat és funkciókat egyszerűen nem futtatja. Ezzel a módszerrel a fejlesztők mindenkinek az igényét kielégíthetik, és még a befektetett munka is jelentősen csökkenthető.

A cikk még nem ért véget, kérlek, lapozz!