Hirdetés

Már a kisebb fejlesztőknek is elérhetők a WDDM 2.0-s grafikus meghajtók

A DirectX 12 és az API-hoz szükséges a WDDM 2.0 sok nagyobb fejlesztőnek jó ideje elérhető, amihez természetesen léteztek igencsak előzetes állapotú grafikus meghajtók is. Az iparágban mondhatni bevet szokás, hogy a kisebb fejlesztők csak később kapják meg az új szoftveres implementációkat, ami persze nem akkora tragédia, mivel ezekkel az elején sok szenvedés van, így el kell érniük egy bizonyos készültségi szintet, hogy reálisan használhatók legyenek.

A DirectX 12 és a WDDM 2.0 bár még nem végleges, de már lényegében használható, így az AMD, az Intel és az NVIDIA az elmúlt héten elérhetővé tette a kisebb fejlesztőknek is a legfrissebb WDDM 2.0-t és ezzel a DirectX 12-t is támogató grafikus meghajtókat.

Megtudtuk, hogy ezek a meghajtók már az aktuális állapotukban is igen jól működnek, ami persze nem csoda, hiszen a WDDM 2.0 a korábbi modellekhez képest elképesztő egyszerűsödésen ment keresztül, ahogy a DirectX 12 API is, vagyis mostantól a grafikus meghajtókba is jóval kevesebb funkció szükséges, mint korábban. Lényegében a shader fordító az egyetlen olyan elem, amelyet továbbra is komolyan fejleszteni kell, míg a hardver menedzsmentjéért felelős rész majdnem teljesen eltűnt, így ezekkel többet nem kell foglalkozniuk a gyártók rendszerprogramozóinak. A grafikus kernel meghajtó is rendkívül leegyszerűsödött. Ezt formailag már nem is kernel meghajtónak nevezik, mivel a programfuttatás nagy részében nem csinál semmit, így csak nagyon alapvető menedzselési munkái vannak, és azokat sem a DXGI-on (DirectX Graphics Infrastructure) belül végzi el, tehát a programfuttatáshoz közvetlenül nincs köze.

Persze tévedés ne essék a rendszer logikai szinten elemezve nem működik jelentősen másképp, mint korábban, csak a hardver menedzsmentjének nagy része átkerült az alkalmazásba, de erről és az alapvető különbségekről egy korábbi cikkünkben részletesen írtunk.

A Windows 10 komplett, előzetes technikai csomagja (amely tartalmazza a WDDM 2.0-t, a DirectX 12-t és a szükséges grafikus meghatók aktuális verzióit) mellé a Microsoft felhívta a piac figyelmét arra, hogy a DirectX 12-vel bevezetett új modellekben az alkalmazásba épített direkt optimalizálástól függ az adott hardver és architektúra teljesítménye. Ha a fejlesztők ezt nem veszik figyelembe, akkor bizonyos hardverek tempója nagyon gyenge lehet, akár az elméletben elérhető sebesség fele vagy harmada.

A redmondi óriáscég szerint az új modellben a gyártók képtelenek a grafikus meghajtókban lényeges mértékben befolyásolni az alkalmazás működését. Ebből a szempontból csak a shaderek cseréjére lehet építeni, így kiemelten fontos, hogy az adott program az összes architektúra képességeit figyelembe véve jól válassza meg az alkalmazott render target és textúraformátumokat. Az egyes architektúrák ugyanis eltérő exportálási és mintavételi teljesítménnyel dolgoznak az eltérő formátumokon, és a gyártóknak a DirectX 12-ben ezeket nincs lehetőségük lecserélni egy jobb formátumra a grafikus eszközillesztőkben. Emellett az anizotropikus szűrés és az élsimítás sem kényszeríthető többet a grafikus meghajtókból, vagyis ezekre is direkt támogatás kell magába az alkalmazásba. Még a driverekbe épített utófeldolgozásos élsimítási technikák (AMD MLAA, NVIDIA FXAA, Intel CMAA) sem fognak működni, mivel a grafikus eszközillesztő nem fogja tudni, hogy a memóriában hol található a képkockapuffer.

A Microsoft kiemelten felhívja a figyelmet arra, hogy a videomemória adatelrendezésre vonatkozó információi csak az adott alkalmazásnak lesznek a birtokában, vagyis notebookokban alkalmazott szoftveres átkapcsolásra épülő grafikus rendszerek csak akkor fognak működni, ha a program fejlesztője direkt támogatást ír ezekre. Ehhez a képkockapuffert magának a programnak kell átmásolnia a rendszermemóriába, ahonnan az integrált grafikus vezérlő meghajtója már képes az adatokat olvasni. Ha ez a program oldalán nem történik meg, akkor a képkockapuffert lehetetlen kinyerni a videomemóriából. Szerencsére a DirectX 12 tartalmaz erre egy biztonsági protokollt, így a fejlesztőnek a programindításkor kell jeleznie az API felé, hogy az alkalmazás fel van-e készítve a szoftveres átkapcsolással dolgozó grafikus rendszerek kezelésére. Ha ezt nem jelzi, akkor az API csak az integrált grafikus vezérlőt fogja figyelembe venni és arra hozza létre az erőforrást, míg a mellette lévő dedikált grafikus vezérlőt vagy vezérlőket figyelmen kívül hagyja.

A Microsoft a fentiek mellett a gyártókat is arra kéri, hogy segítsék a fejlesztők munkáját kezdve azzal, hogy részletesen dokumentálják a piacon lévő, DirectX 12 API-t támogató architektúráik működését, mivel enélkül a legtöbb programozó nem fogja tudni, hogy a megírt kód optimálisan fut-e vagy sem. A redmondi óriáscég szerint a fejlesztőstúdiók nagy részének nincs meg az anyagi fedezete arra, hogy kutatás céljából visszafejtsék az összes elérhető grafikus architektúra működését, így minden segítség jól jön számukra. Ez az együttműködés abszolút a piac érdeke, így az egész iparágnak össze kell fognia a szebb jövőért.

Azóta történt

Előzmények

Hirdetés