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.

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