Ez lett a Microsoft DirectX 12
A Microsoft hivatalosan is lerántotta a leplet a korábban már beharangozott DirectX 12 előzetes képességeiről. Minden részlet nem került a helyére, mivel az API még tervezés alatt áll, így olyan dolgok is hozzá lesznek rakva, amelyekről a vállalat jelenleg nem beszél, de az alapokat azért tisztázták. A GDC-n tartott előadás során a redmondi óriáscég elmondta, hogy a rendszert a fejlesztői visszajelzések alapján tervezték, így a DirectX 12 kiszámítható, konzisztens teljesítményt kínál, jól skálázódik, illetve az aktuálisnál alacsonyabb hozzáférést biztosít a hardverekhez.
A fő paraméterek szempontjából a DirectX 12 több helyen másolja a Mantle API-t, míg más területeken a DirectX 11-ben alkalmazott koncepció alapos továbbfejlesztéséről van szó. Ha a Microsoft úgyis a fejlesztők igényeit hozta fel, akkor először vegyük a legnagyobb problémájukat. A mai szabványos API-k egyszerűen nem kínálnak gyakorlatban működő koncepciót a többmagos processzorok kihasználására. Ezt az előadás során is elismerték, azaz burkoltan bevallották, hogy az erre használható deferred context funkció a parancslistával egy totális bukás. Ez persze nem újdonság, hiszen az előbbieket minden fejlesztő elmondja, aki foglalkozott vele, de jó hallani, hogy a szabvány alkotója is realista, mivel a hibákat felismerve új koncepciót építhetnek fel.
Tulajdonképpen ezt tette a Microsoft is. A DirectX 12 új végrehajtási modellje nagyon hasonlít a Mantle API működésére, hiszen a grafikus vezérlő logikai részeihez több parancslista tartozhat, melyekkel párhuzamosan etethető a hardver. Ez lehetőséget ad a parancsok aszinkron végrehajtására, de ez a funkció nem tartozik az alapvető követelmények közé, viszont opcionálisan támogatható, ha az adott gyártó terméke képes rá.
Információink szerint az új végrehajtási modell segítségével képkockánként ötvenezer rajzolási parancs gond nélkül kiadható, ami az aktuális DirectX API kétezres ajánlott szintjéhez képest őrületes előrelépés, de a Mantle százezres szintjét azért nem hozza. Viszont a DirectX 12 újítása a csomag nevű koncepció, ami lényegében az instancing kiterjesztésének vagy továbbgondolásának tekinthető. Tulajdonképpen a csomagok lehetőséget adnak az addig betöltött objektumok lemásolására, viszont a másolatok tulajdonságai lényegesen nagyobb mértékben módosíthatók, mint az instancing 2.0-val. Erre a fejlesztőknek persze több erőforrást kell befektetni, mintha képkockánként több rajzolási parancs hatékony feldolgozását engedne meg az API, de végeredményben a csomagok bevetésével a DirectX 12 minden probléma nélkül képes hozni a Mantle teljesítményét.
A CPU erőforrásainak felszabadítása szempontjából jó hír, hogy a DirectX 12 jelentősen javít az eddig alkalmazott binding modellen. Ez ugyan még mindig nem bindless elvű, így ebből a szempontból a Mantle API, illetve az OpenGL 4.4 a specifikus kiterjesztéseivel előrébb jár, viszont olyannyira sikerült redukálni a bekötésekkel járó processzorhasználatot, hogy ez elvileg nem okozhat majd gondot. Ezen a ponton az új API nagyon épít arra, ahogy az Xbox One IGP-je működik, és nem mellesleg a mai modern grafikus architektúrák is ezzel a modellel dolgoznak.
A DirectX 11-ben az volt a fő gond, hogy például a program létrehozza az erőforrásokat, majd ezeket beköti számos slotba a futószalag különböző shader lépcsőin. A shaderek ezekből a bekötött slotokból olvassák az adatokat, ami nem szerencsés, mert ha a program különböző erőforrásokból szeretne rajzolni, akkor újra be kell kötni a különböző látképeket a különböző slotokba, és újra ki kell adni a rajzolási parancsot. Itt több probléma is fennáll. Egyrészt a rajzolási parancs nagyon nincs ingyen, és tulajdonképpen ezzel pazaroljuk az erőforrást, emellett a bekötés processzorigényes, ami szintén pazarlás.
A DirectX 12 lényeges változtatása, hogy bevezeti az úgynevezett leírótáblákat, amelyek reprezentálják egy részét a teljes leíróhalmaznak. A leírótáblák módosítása rendkívül olcsó művelet, és az új API ezt használja ki. A program számos látképet készít az erőforrásokról, így pedig kiválasztható, hogy mely erőforrások használata szükséges az adott rajzolási parancshoz. Az előnyök egyértelműek. Csak annyi rajzolási parancs lesz, amennyi feltétlenül szükséges, illetve a bekötések száma is jelentősen redukálódik.
Lényeges változás még, hogy csökkent az állapotváltások többletterhelése is, illetve a shader és a futószalag állapota gyorsítótárazható, amivel meg lehet akadályozni a valós idejű shader újrafordítást. Utóbbit a fejlesztők mindig is utálták az aktuális DirectX API-ban, mivel képtelenek voltak meghatározni ennek bekövetkeztét, így arra is képtelenek voltak, hogy megszüntessék az ebből eredő mikroakadásokat.
A fő kérdés a DirectX 12-vel kapcsolatban előzetesen az volt, hogy a VRAM elérését hogyan oldja meg a Microsoft. A Mantle esetében az AMD rendkívül egyszerű modellt választott, hiszen odaadta a kontrollt a fejlesztők kezébe és ennyi. Vitathatatlan, hogy ez a legegyszerűbb és leghatékonyabb megoldás, ha a fejlesztők megbízhatók, de egy ténylegesen szabványként kigondolt API esetében ez nem kifizetődő. A Microsoft továbbra sem ad teljesen explicit elérést a VRAM-hoz, de jelentősen javítják a sokat kritizált WDDM felületet, hogy a fejlesztők munkája könnyebb legyen. Az alkalmazás megkapja a kontrollt, hogy menedzselje a memóriahalmazokat, és a memóriaallokáció, az erőforrások létrehozása, illetve ezek megsemmisítése rendkívül olcsó lett (amiről egy új driver modell gondoskodik majd). Utóbbi nagyon fontos előrelépés, mert a DirectX 11-ben sok fejlesztő csak a legvégső esetben semmisít meg egy létrehozott erőforrást, így amíg van szabad memóriakapacitás, addig azt használni kell, mert annak felszabadítása vállalhatatlanul költséges.
Végül két érdekes extra, hogy az API-ban megjelent pár speciális erőforrás. Ezek jelenleg az Xbox One IGP-jében található Swizzle Copy motorokhoz valók, de nyilván opcionálisan elérhetők PC-n is, ha valamelyik gyártó készít megfelelő architektúrát kihasználásukhoz.
A cikk még nem ért véget, kérlek, lapozz!
