A DirectX 11 újításai
A DirectX 11 újításai
Shader Modell 5.0
Az elmúlt verziókban elképesztő mértékű fejlődésen ment keresztül a Shader Modell szabvány és a HLSL (High Level Shader Language) programnyelv. Az 5.0-ás verzió nem igazán bővíti tovább a lehetőségeket, hiszen a mérce már amúgy is igen magasra lett tolva. Ellenben egyszerűsíti a programozók feladatát, hiszen objektumorientált lett a nyelv. Ez a változás a felhasználóknak jelentéktelennek tűnhet, de érdemes belegondolni, micsoda előrelépés a fejlesztőknek. A mai programok rengeteg eltérő kódot alkalmaznak az adott fényhatást figyelembe véve a különböző paramétereknek megfeleltethető felületekre (legyen az virtuális fém, műanyag, fa, üveg vagy szövet). A szekvenciális alapokon nyugvó, korábbi verziójú HLSL nyelvekben ezeket a fény-anyag kölcsönhatásokat kétféleképpen kódolhatták le a programozók. Az egyik megoldás, hogy a grafikus motor összes lehetséges árnyalási metódusára egy külön shader programot kell futtatni. A mai, korszerű grafikát kezelő rendszerek mellett azonban ez nagyon sok kis programot eredményez, hiszen tucatnyi megkülönböztethető felület létezik, emellett az eltérő fényhatásokból is bőven akad. A fentebb említett öt, anyagokra vonatkozó példa három fénytípussal kiegészítve (például: körsugárzó, pont és direkt) rögtön 15 darab programot generál, ami már elég ahhoz, hogy az esetleges hibák kereséséhez és javításához aránytalanul magas időigény járuljon. Arról sem szabad megfeledkezni, hogy shader programok folyamatos generálása a hardver szempontjából is időbe telik. Ennek elkerülésére alkalmazták eddig a fejlesztők az übershadernek gúnyolt programokat, mint alternatív megoldást. A helyzet azonban alig átláthatóbb, mivel egy shader programba kell az összes kódot írni, nem kevés feltételes elágazás használatával. Az objektumorientáltság azonban jelentősen egyszerűsíti a fejlesztők dolgát, hiszen a programegységeket egy előre megtervezett hierarchiának feleltethetik meg. Interfészként megadható a felület és a fényhatás, melyben a tagfüggvények, azok tulajdonságai és bemenő paraméterei találhatók. Az osztályok pedig a függvényeket és a változókat tartalmazzák. Ennek megfelelően a hibakeresésre fordított idő jelentősen redukálódhat.
Textúratömörítés
Két új textúratömörítési eljárás került az új API-ba. Ennek nagy jelentősége van a mai programok mellett, hiszen a nagyfelbontású textúrák komoly helyigénnyel rendelkeznek a memóriára nézve. Ezen kívül a DirectX 11 már megköveteli a hardveres kitömörítést is az összes támogatott formátumra.
A BC6 (Block Compression) a HDR (High Dynamic Range) alkalmazása mellett használható. Ilyen esetekben ugyanis a fejlesztők sokszor alkalmaznak Tone mapet a kép színátviteli görbéjének állítása miatt. A BC6 6:1 arányban tömöríti a képkocka HDR adatait, ami némi veszteséggel jár ugyan, de a végső eredmény rendkívül meggyőző.
BC6 textúratömörítés a gyakorlatban [+]
A BC7 az úgynevezett LDR (Low Dynamic Range) formátumú textúrák alkalmazása mellett lehet alternatíva. Nagyon jó képminőséget eredményez az eljárás 3:1-es RGB (vörös, zöld, kék), illetve 4:1-es RGBA (vörös, zöld, kék, átlátszóság) tömörítési arány mellett.
A fenti két textúratömörítési eljárást lehetőség van a driver szintjén emulálni, így a támogatás kiterjeszthető a DirectX 10-es hardverekre is. Természetesen a hardveres kitömörítés itt nem lesz alkalmazható, így a sebességre nézve negatívan ható felárat kell majd érte fizetni.
Többszálúság támogatása
Nem nevezhető meglepetésnek, hogy a DirectX API is rálépett a Multi-Threading, azaz a többszálú feldolgozás kissé döcögősen járható útjára. Szerény véleményem szerint ennek már hamarabb meg kellett volna történnie, hiszen meglehetősen problémás, hogy a piac legelterjedtebb grafikus API-ja a többmagos processzorok korában még mindig csak egy programszálon renderel. Az új API-ban az objektum megrajzolásához szükséges rajzolási parancs és az effektek létrehozásánál bekövetkező állapotváltások már több szálon lesznek kezelve. Ahhoz, hogy ez működésben megfelelően ki legyen használva, a Direct3D 11-es erőforrást az azonnali és a halasztott tartalom szintjére kell felosztani. Az azonnali tartalom egy programszálat takar, és olyan kész objektumokat tartalmaz, melyek sorrendben átadhatók a grafikus processzornak. A halasztott tartalom központi processzor által történő feldolgozása már több szálon történik. Minden egyes ilyen szál tartalmaz egy listát a saját objektumairól, így lesz ellenőrizve, hogy a számítás elvégzése megtörtént-e. Amint kész a feladat, a halasztott tartalom behívásra kerül az azonnali tartalomba. Jó hír, hogy a rendszer működése az API szintjén változott meg, így nem szükséges hardveres módosítás a problémamentes feldolgozáshoz. Ez azt jelenti, hogy a Windows Vista operációs rendszerben bemutatkozó WDDM (Windows Display Driver Model) és a megfelelően felépített eszközmeghajtók mellett bármelyik, minimum DirectX 10-kompatibilis grafikus kártyával használható az új feldolgozási elv. Azt persze érdemes megemlíteni, hogy a fő feldolgozási szál továbbra is túlterhelhető, tehát a tökéletes eredmény eléréséhez a fejlesztőnek is optimalizált eljárásokat kell alkalmaznia.
További változás még a DirectX 11-ben, hogy a maximum alkalmazható textúraméret akár 16384x16384 pixeles is lehet. Ezenkívül a Conservative oDepth eljárás segítségével akkor is lehet a Depth Bufferbe írni, ha az Early Z check és más, úgynevezett Z gyorsítási funkciók nincsenek kikapcsolva.
A cikk még nem ért véget, kérlek, lapozz!
