Titkolt részletek
A DirectX 12 a multi-engine funkció támogatását két formában tekinti hitelesnek. Egyrészt léteznek olyan hardverek, amelyek egyszerre csupán egy parancslistából fogadnak feladatokat, ami nyilván a grafikai parancslista, így a multi-engine kód ugyan támogatható, de a grafikus meghajtónak minden copy és compute parancsot a grafikai parancslistába kell betöltenie. Itt válik a DirectX 12 fentebb említett hierarchiája kulcsfontosságúvá, miszerint a grafikai parancsmotor tudja a copy és a compute motorok képességeit. Ez a multi-engine funkció szoftveres formában történő támogatása, ami arra elég, hogy hibátlanul futtassa a kódot, de teljesítményelőnyt nem kovácsol majd az aszinkron munkavégzésből, mivel a feladatokat a meghajtó sorba köti.
A DirectX 12 hardveres támogatásra is lehetőséget ad. Ilyenkor a grafikus meghajtó a copy, compute és grafikai parancsokat szépen betölti a copy, compute és grafikai motorokba, vagyis lehetőséggé válik a hardveren belül az aszinkron munkavégzés. Ez azt jelenti, hogy az adatfeltöltéssel párhuzamosan futhat egy grafikai és egy compute feladat is. Nyilván ennek az előnyei egyértelműek, hiszen párhuzamosan minimum három feladat fog futni egy eleve masszív párhuzamosságra tervezett grafikus vezérlőn, míg enélkül az ominózus három feladat egymás után futna le soros feldolgozás mellett.
Hardveres szempontból a DirectX 12 egy dolgot követel meg. Az adott grafikus vezérlőnek képesnek kell lennie fogadni minimum egy copy, egy grafikai és egy compute feladatot párhuzamosan. Természetesen nem baj, ha esetleg képes több compute feladatot is fogadni az egy copy és grafikai mellett, de erre vonatkozóan az említett API csak minimum igényeket fogalmaz meg. Más követelménye a multi-engine funkció hardveres támogatásának nincs, és itt van egy apróbb gyakorlati probléma. Attól, hogy egy hardver képes egy grafikai és egy compute feladatot párhuzamosan fogadni, még nem biztos, hogy azok a lapkán belül is képesek párhuzamosan futni.
Ez több dologtól függhet. Egyrészt nyilván ügyelni kell a regiszterekre, mivel azok száma nem végtelen, illetve bizonyos feladatok a hardveren belül bizonyos hardverállapothoz vannak kötve. Utóbbi azt jelenti, hogy például egy árnyéktérkép számítása esetleg más hardverállapot beállítását igényli, mint valamilyen compute feladat. Ilyen formában teljesen mindegy, hogy a lapkán belül az árnyéktérkép számítása mellett a shader feldolgozók nagyrészt kihasználatlanok, azon a tetszőleges compute feladat még a párhuzamos beérkezés mellett sem futhat le, mert nincs beállítva az a hardverállapot, ami ehhez szükséges. Emiatt kontextusváltásra lesz szükség, ami rengeteg úgynevezett büntetőciklussal jár. Ez persze csak egy példa, és nem egy konkrét utalás a hardverek működésére, viszont ez alapján könnyebben meg lehet érteni, hogy mi történik.
Multi-engine nélkül a feladatokat sorban, egymás után kellene futtatni [+]
Mivel a DirectX 12 specifikációja a hardverállapotra vonatkozóan semmilyen követelményt nem fogalmaz meg, így az fog történni, hogy a multi-engine kód nem feltétlenül hoz majd gyorsulást azokon a hardvereken, amelyek elméletben támogatnak különálló copy, compute és grafikai parancsmotorokat, és ezeken képesek is párhuzamosan feladatokat fogadni. Esetenként még lassulás is érheti a rendszert, ami egyrészt a szükséges kontextusváltás jelentős időigényére vezethető vissza, másrészt a mai hardvereket viszonylag magas órajelre tervezik, úgynevezett turbó képességekkel, és a jelentősen megnövő belső terhelés a turbó órajelet erőteljesen csökkentheti.
Itt azonban még mindig nincs vége az elemzésnek, mivel a multi-engine és szinkronizáció funkció kapcsán az API oldali rendszer csak a teljes kép egyik eleme, egészen pontosan az, ami látszik a fejlesztők felé. Nem szabad azonban megfeledkezni arról, hogy az említett funkciót vezérelni is kell, és itt jön képbe a WDDM 2.0, ezen belül is a DXKG (DirectX Kernel Graphics). Mint ismeretes, a DirectX 12 megszüntette a grafikus kernel meghajtót, vagyis mostantól a gyártók képtelenek ilyet szállítani az implementációba. A grafikus kernel azonban nem szűnt meg teljesen, csupán átalakult. Mostantól minden olyan feladatot, amely nem kezelhető a fejlesztők programkódjában vagy a felhasználói módban futó grafikus meghajtó által, a Microsoft egy univerzális kernel meghajtóval old meg, amelynek a különlegessége, hogy rendkívül kevés erőforrást igényel a processzor oldaláról.
Itt jön elő egy olyan probléma, amelyről nem sokat beszél az ipar, mert a programozók és tulajdonképpen a felhasználók számára is lényegtelen tényezőről van szó, ám a hardvergyártók számára nem az. Mivel a DXKG egy univerzális réteg, így univerzálisan is kezeli az elérhető grafikus architektúrákat. Viszont ez csak leírva ilyen egyszerű, valójában mindenképpen egy architektúrához kell igazodni az alapvető működés szempontjából. Ez egy olyan utat jelöl ki a piac számára, amelyet a Microsoft jónak tart a jövő szempontjából. A funkcionális működést természetesen nem befolyásolja, tehát az adott programkód mindig minden architektúrával tökéletesen kompatibilis, de a hatékonysággal már komoly problémák lehetnek.
A DirectX 12 elsődlegesen az Xbox One konzolhoz készült, ahogy a WDDM 2.0 is, annak minden elemével, emiatt a teljes csomag olyan architektúrát igényel a tökéletes hatékonysághoz, mint az AMD GCN-je. A félreértések elkerülése végett viszont nagyon fontos kiemelni, hogy nem GCN-es Radeont igényel a rendszer, hanem megegyező elvi működésű architektúrát. Tehát idővel, ahogy fejlődnek a gyártók architektúrái, azok hozzá lesznek igazítva az új API-hoz és az új WDDM-hez, vagyis a rendszer egészét tekintve az új feldolgozási modellhez. A hatékonysághoz kötődő problémák tehát mindenképpen átmenetiek, amelyek sajnos nem feltétlenül kerülhetők el egy olyan iparági váltásnál, amit az új alapokra épített grafikus API-k bevezetése jelent.
Az átmeneti időszak azonban nem problémamentes, és a DXKG-hez igazodni kell. Utóbbi ugyanis ad némi lehetőséget a paraméterezhetőségre, függetlenül attól, hogy a csomagot a Microsoft szállítja a Windows 10 operációs rendszeren belül. Ugyanakkor a pontos működésről még nincs sok adat, mivel a DXKG-nek nincs nyílt formában elérhető specifikációja. Gyakorlatilag a szabvány megalkotóin kívül senki sem tudja, hogy miképpen működik, így azt is nehéz róla kideríteni, hogy miben ad szabad paraméterezési lehetőséget a hardvergyártóknak, hogy valamennyire azért áthidalhatók legyenek az egyes architektúrák közötti elvi különbségek.
A cikk még nem ért véget, kérlek, lapozz!
