A DirectX 12 alapfeltételei
A Microsoft az elmúlt héten mutatta be a DirectX 12-t, melynek eddig ismert képességeiről cikkben számoltunk be, de a hardverek támogatására vonatkozóan nem volt túl sok adat akkor még. A korábbi információ továbbra is áll abból a szempontból, hogy amelyik grafikus vezérlő támogatta a DirectX 11-et, képes támogatni a DirectX 12-t is. A friss adatok azonban ezt egy kicsit felforgatják, mivel megtudtuk, hogy az új API csak akkor működik hatékonyan, ha MMU (memória menedzsment egység) is található az adott grafikus vezérlőben. Maga a rendszer azonban kínál egy alternatív megközelítést, így az API-ban van egy úgynevezett soft MMU elérés, ami tulajdonképpen emulál egy MMU-t a régebbi grafikus vezérlők számára.
Információink szerint a Microsoft a gyártókra bízta a végső döntést, hogy mely hardvereket támogatják a DirectX 12-höz készült meghajtókkal. Elvi szinten úgy van kialakítva az API, hogy az MMU-val rendelkező hardverek és az emulált MMU-s működés funkcionálisan ne különbözzön, tehát a program oldali kompatibilitás garantált, de az MMU emulálása sebességvesztéssel fog járni, esetenként nem is kevéssel. Jelen helyzetben tehát a DirectX 12-t hivatalos bejelentéssel támogató hardverek tekintetében az Intel Gen7.5, illetve az NVIDIA Fermi architektúrája korlátozott sebesség mellett fog működni, míg az MMU-val rendelkező NVIDIA Kepler és Maxwell, valamint AMD GCN architektúra, illetve a Qualcomm Adreno 400-as GPU IP családja a hardveres támogatásnak is megfelel, ami nagyobb tempót jelent majd.
A támogatással kapcsolatban az AMD a TeraScale 2 architektúrára vonatkozóan valószínűleg úgy gondolja, hogy az MMU emulálása túl nagy sebességvesztéssel jár, ez pedig nem érné meg a beleölt pénzt. Az Intel a Gen7 és Gen7+ IGP-kre szintén megoldhatná az új API kezelését, hiszen a soft MMU elérést támogató eszközillesztő a Gen7.5-re elkészül, de a következő év végére valószínűleg már az úgynevezett legacy szinten is befejezik az Ivy Bridge és a Bay Trail processzorgeneráció terméktámogatását.
A DirectX 12-vel kapcsolatban egyetlen lényeges információ hiányzik még. Azt tudni lehet, hogy a D3D_FEATURE_LEVEL_11_0 és D3D_FEATURE_LEVEL_11_1 szint megmarad, de a készülő új szintről nincs adat, illetve az érkező extra funkciókról sem lehet sokat tudni. Annyit az elmúlt héten kiderítettünk, hogy a D3D_FEATURE_LEVEL_11_0 szint pár funkcióval kiegészül, amit persze minden hardver képes majd támogatni, így tulajdonképpen ez a változás nem okoz majd problémát.
Hirdetés
A D3D_FEATURE_LEVEL_11_1 szint extrái változatlanok maradnak, de érkezik egy új opcionális funkció, ami előzetesen a BAS (buffer access serialization) kódnevet viseli. Jelen információink szerint ezt az Intel Gen7.5-ös architektúrája esélyes, hogy támogatja, hiszen elvi szinten a PixelSync szabványosításáról van szó. A pufferek megfelelő sorrendben és időben történő elérése azonban mutex-alapú zárolási sémával is lehetséges, ami lényegében azt biztosítja, hogy több versengő folyamat közül csak az egyik férhessen hozzá az adott erőforráshoz. Ez már a DirectX 11 esetében is használható, de nem stabil és nem is biztonságos funkció, a DirectX 12-ben viszont erre vonatkozóan tovább lehet fejleszteni a rendszert. Nem mellesleg ezzel a módszerrel az Xbox One is támogathatja az újítást.
Nehéz lesz az erőforrások egységesítése
A program számára elérhető erőforrások szempontjából már közel sem ilyen egyszerű a helyzet. Mindegyik gyártó nagyon másképp látja a jövőt, miközben a Microsoft koncepciója az aktuális limitek teljes feloldása. Utóbbi érthető, hiszen az Xbox One konzolba épített AMD GCN architektúra úgy lett megtervezve, hogy végtelen mennyiségű erőforrást kezeljen, ami természetesen átmenthető PC-be is. A többi gyártó véleménye azonban lehet, hogy nem egyezik a korlátok feloldása szempontjából, hiszen egy ilyen radikális újítással bonyolultabb hardverekre lenne szükség, ami természetesen a fogyasztás növeléséhez is vezetne, miközben a világ épp az ultramobil irányba mozdul el.
Ebből a szempontból a Microsoft lehet, hogy könnyelmű lesz, ami tulajdonképpen azzal érne fel, hogy nem vesz részt a gyártók elvi csatározásában, csak olyan opcionális funkciókat biztosít az API-ban, amit a konzolokon is elérnek a fejlesztők. Ez ugyanakkor egy PC-s ökoszisztémában nem ideális, hiszen az egyes szabványos effektek nem futnának minden DirectX 12-t támogató hardveren.
A kritikus szempontot az UAV-k, SRV-k és RT-k száma jelenti. Ahogy fentebb írtuk, a konzolokon ezekre nincs korlát, annyi érhető el, amennyit a fejlesztő akar. Ez a PC-ben is igaz a GCN architektúrára vonatkozóan, hiszen ugyanaz az alap. Az NVIDIA már másképp dolgozik, és az összes architektúrájuk esetén a fő parancsprocesszorban tartják számon, hogy hány erőforrást használhat még a program. Az UAV-k és az RT-k szempontjából 8-8 darab bejegyzésre van lehetőség, ami megegyezik a D3D_FEATURE_LEVEL_11_0 szint követelményével. Az SRV-k esetében a Fermi a szabványos 128 bejegyzésre vonatkozó erőforráslimitet tartja be, de a Kepler és a Maxwell architektúra ezt kiterjeszti egymillió fölé (egészen pontosan 1 048 576 bejegyzésre).
Az Intel Gen7, Gen7+ és Gen7.5 architektúrája már megint eltérően működik, mivel általános bekötési táblát használnak az erőforrások nyomon követésére, amiben 256 bejegyzésre van lehetőség. Ebből egy slot debug célra van fenntartva, míg a maradék 255 megfelelően el lesz osztva minden igényelt erőforrás között. Technikai értelemben az Intel 255 UAV-t vagy 255 SRV-t vagy 255 RT-t tud támogatni, de egyszerre ezekből ekkora mennyiség nem használható fel, mivel összesen 255 slot van. Nem egyszerű tehát a helyzet, és a Microsoftnak ebből kellene valami közösen elfogadott koncepciót kidolgozni.
Megtudtuk még, hogy a DirectX 12 újításai között szerepel az ASTC szabvány LDR verziója. Ezt jelenleg a PC-s grafikus hardverek nem támogatják, de a Qualcomm Adreno 400-as GPU IP család már igen. Viszont a textúratömörítés emulálható, tehát kezdeti támogatást így is lehet rá építeni, illetve szinte biztos, hogy később mindenki hardveres támogatást kínál majd erre. A korábban már említett fixfunkciós JPEG dekódoló is felmerült újból. Ez nyilvánvalóan az Xbox One IGP-jében található hardvert célozza, de az Intel Haswell processzor Gen7.5-ös architektúrájú IGP-je is tartalmaz ilyen egységet. Azt viszont még nem tudni, hogy a Microsoft megfogalmaz-e a hardver sebességére egy alapvető követelményt, vagy csupán a részegység megléte is elég. Utóbbi esetében az Intel erre biztosan képes támogatást írni.
Egyszerűbb meghajtók jönnek
A DirectX 12 legjobb része, hogy a grafikus meghajtókat jelentősen egyszerűsíteni lehet, illetve kell is, hiszen a relatíve alacsony szintű elérést biztosító API-k egyik lényeges eleme, hogy átcsoportosítja a kontrollt a hardver felett. Eddig rengeteg tényezőért maga az API, illetve az adott grafikus driver felelt, ami nem feltétlenül rossz, hiszen az alkalmazás hibáit a meghajtóval korrigálni tudja, de ugyanakkor vannak olyan szituációk, amikor a rendszer lényegében sokszoros munkát végez, hiszen ugyanazt a feladatot megcsinálja a program motorja, az API és a driver is (például render state-ek szűrése), ami egyszerűen felesleges.
A DirectX 12-vel az API lényegében egy nagyon vékony interfésszé változik, ami igazából nem tesz egyebet, mint biztosítja az alkalmazás és a driver közti kapcsolatot. Ezen belül is leginkább a shader programok futtatását oldja meg, és igazából más fontosabb dolgot nem is. A driver is nagyon vékony lesz, hiszen az API működésének egyszerűsítése kevesebb beépített rutint igényel. Viszont az adott program motorja lényegében teljesen átvesz olyan feladatokat, amelyeket eddig az API és a driver látott el, vagy legalábbis nagyrészt feleltek ezekért.
Ennek a koncepciónak az eredménye az lesz, hogy leginkább az alkalmazás határozza majd meg az adott hardveren a teljesítményt, hiszen a fejlesztőnek meg kell írnia azokat a funkcionális rutinokat, amelyek eddig az API-ban vagy a driverben voltak. Egy-egy új grafikus driverrel ugyan valamennyire kontrollálható a sebesség, de igazán lényeges gyorsulásokat nem lehet majd elérni.
A DirectX 11 és 12 terhelése. Utóbbi esetben a driver szerverszálak szinte nem is dolgoznak. [+]
A DirectX 12 tehát a megírt kód hossza szempontjából több munkát igényel a fejlesztőktől, de a GDC-s vélemények alapján ezzel mindenki nagyon boldog. A végeredmény tekintetében ugyan rövidebb kódot lehet írni a DirectX 11-re, viszont annyira kiszámíthatatlan az API működése, hogy a végső verzió eléréséig ugyanazt többször is újraírják, tehát effektíve sokkal több időt fektettek a fejlesztésbe a kevesebb kódsor ellenére is.
A fentiek mellett a Microsoft szándékosan támogatja az új API-val az Xbox One-t, mivel a konzolhoz írt kód nagy része direkten átmásolható PC-re. Sőt, technikailag az egész újrahasznosítható, alig pár sor módosításával, de figyelembe kell venni, hogy PC-n nem csak GCN architektúra létezik, így a fejlesztés során optimalizálni kell a többi hardvergyártó megoldására is. Márpedig a fentiekből kiderülhetett, hogy leginkább a fejlesztőn múlik a teljesítmény, így a driver nem igazán tud segíteni, ha a program kódja nem elég jó az adott architektúrának.
Információink szerint a Microsoft tart majd előadást a DirectX 12-ről az április elején megrendezendő Build 2014 konferencián is, de azt nem tudni még, hogy milyen további részleteket árulnak el az API-ról.
Abu85
