Már a DirectX 12 megjelenése óta állandó téma az aszinkron compute helyzete az egyes architektúrákon. Erre már a megjelenéskor születtek különböző szintetikus tesztprogramok, és a félreértések miatt mi is írtunk egy elemzést arról, hogy most mi is a helyzet ezzel a funkcióval. Látszatra lecsillapodtak a kedélyek, de az Ashes of the Singularity új verziója újra felfűtötte az internetet. Utóbbi az első program, amely ténylegesen megjelenő játéknak tekinthető, továbbá nem is szintetikus tesztet tartalmaz, és ráadásul olyan aszinkron compute implementációval rendelkezik, amely fut az AMD és az NVIDIA erre alkalmas hardverein.
A helyzetet viszont bonyolította, hogy az NVIDIA szerint az aszinkron compute nem aktivált funkció a meghajtóban, és nem is mondták meg, hogy mikor lesz bekapcsolva, ugyanakkor a DirectX 12-ben nem is a grafikus meghajtó dönt arról, hogy milyen parancslisták állnak a program rendelkezésére. Ez kissé ellentmondásos, de valójában ennél sokkal komplikáltabb a helyzet. Ugyanakkor az sem jó magyarázat, hogy az NVIDIA modernebb hardverei nem támogatják az aszinkron compute-ot, mint ahogy azt egyre többen állítják a világháló fórumain.
A rejtély megoldásához mindenképpen értelmezni kell azt, hogy a DirectX 12 olyat, hogy aszinkron compute direkten nem definiál. Az API-nak a kapcsolatos funkciója multi-engine és szinkronizáció névre hallgat, és minden gyártói implementációnak kötelező támogatnia. Ez azt jelenti, hogy egy programot szabványosan úgy meg lehet írni, hogy a grafikai futószalagok mellé, külön parancslistákban betölthetők legyenek a compute és copy futószalagok. Ezt a fenti elemzésünk első oldalán részletesen kitárgyaltuk, így erre nem fordítanánk több energiát. Amit viszont nem elemeztünk, hogy lehet-e ezt másképp csinálni. Többek között a nemrég megjelent Vulkan API szintén specifikálja a multi-engine és szinkronizáció funkciót – nem ilyen néven persze, de ez lényegtelen, a működés ténye a fontos.
Ilyen formában egy kicsit szélesebb látóteret is kaptunk az elemzéshez, mivel a multi-engine és szinkronizáció funkció a működés szempontjából mindkét új explicit API-val hasonló, de a követelmények szempontjából már vannak eltérések. Többek között, amíg a DirectX 12 esetében egy univerzális DXKG modul ellenőrzi a hardverben az elérhető parancsmotorokat és azok parancslistáit, addig a Vulkan API ebből a szempontból a grafikus meghajtótól kér adatokat. Elvi szinten ez nem tűnik nagy dolognak, hiszen miért is lenne ugyanolyan hardverrel más az eredmény, de valójában hatalmas a különbség.
Amíg ugyanis a DXKG modult a Microsoft szállítja, és ennek a hardver nem tud hazudni, addig a Vulkan esetében az ezt lekérdező rendszer a grafikus meghajtóban van, aminek a hardver szintén nem hazudik, de az eszközillesztő már hazudhat az API-nak. Sőt, nem csak hazudhat, hanem konkrétan hazudik, ugyanis amíg az AMD Vulkan implementációjával mindegyik GCN architektúrára épülő Radeonon három parancslistát ad vissza a lekérdezésnél, addig az NVIDIA Vulkan implementációja az összes támogatott hardveren csak egyet tesz elérhetővé. Bár a Vulkan multi-engine és szinkronizáció funkciója mindkét esetben aktív, több parancslista nélkül a rendszer úgynevezett single-engine-re korlátozott hardverként lesz kezelve, vagyis mindegy egyes futószalag a fő parancsprocesszorba megy, függetlenül attól, hogy az alkalmazás esetleg nem oda címezi.
A DirectX 12 esetében az a fő gond, hogy a DXKG modul nem tud hazudni az API-nak. Egyszerűen a létrehozott erőforrásnak csak a tudása alapján dönt, és nem veszi figyelembe, hogy esetleg létezik olyan hardver, amely a több parancslistán betöltött futószalagokat ne tudná minden esetben hatékonyan futtatni. Itt is van a kulcstényező, ugyanis az NVIDIA DirectX 12-ben nem tudja single-engine működésre korlátozni a hardvereit, amitől a DXKG bizonyos szoftverimplementációk mellett helytelenül tölti fel a parancslistákat.
Az NVIDIA problémája egyébként nem az, hogy az újabb GeForce-ok nem rendelkeznek dedikált compute parancsprocesszorokkal, ahogy arra egyre többen utalnak, hanem az, hogy a beépített compute parancsprocesszorok nem támogatják az erőforrás-korlátozást, amit a DirectX 12 alapértelmezettként megkövetel. Tehát bármilyen compute futószalag, amely tartalmaz erőforrás-korlátozást nem tölthető be csak a fő parancsprocesszorba. A fő parancsprocesszort azonban a DirectX 12-ben már nem grafikus meghajtó, hanem az operációs rendszer vezérli, vagyis előjön egy olyan probléma, hogy ezeknek az egységeknek a máig beépített, és DirectX 11-ben jellemzően használt extrái gyakorlatilag nem érnek semmit a Microsoft új API-jával.
Szerencsére megoldás lehet az, hogy az NVIDIA az erőforrás-korlátozást nem tartalmazó compute futószalagokat betöltse a dedikált compute parancsprocesszorokba, ezeket ugyanis a meghajtó vezérli az operációs rendszer kizárásával. Ugyanakkor ez csak elvben hangzik egyszerűen, mivel az eszközillesztő nem tudja előre, hogy melyik futószalagban van erőforrás-korlátozás és melyikben nincs, tehát pokolian nehéz lesz ezt a problémát megoldani. Erre az egyetlen reális lehetőség az lehet, hogy a fejlesztők minden kiadott program esetében az NVIDIA tudtára hozzák, hogy miket tartalmaznak a futószalagok, és meghajtó minden alkalmazáshoz kapna egy olyan profilt, amely egy belső adatbázis alapján képes lehet dönteni a futószalagok betöltéséről.
A fentiek mellett óhatatlanul is felmerül az a kérdés, hogy túl kemény specifikációkat szabott-e meg a Microsoft. Erre viszont nincs egyértelmű válasz. Redmondban az elmúlt évek során többször is hoztak elsőre furcsának tűnő döntéseket, különösen akkor, amikor a DirectX API-ról volt szó. Emlékezhetünk például a D3D bájtkódra, amit a kezdetekkor sokan feleslegesnek tartottak, de végül a Microsoft legnagyobb húzása volt. A DirectX 10-nél is kritizálták páran a caps bitek elhagyását, de ma már áldjuk a vállalat döntését. A mostani húzás mögött valószínűleg egyfajta egységesítési kísérlet húzódik. Mivel a multi-engine és szinkronizáció egyáltalán nem egyszerű funkció, így a Microsoft jobbnak látta, ha a specifikáció szempontjából rendkívül egyértelműek és kíméletlenek, ezzel biztosítva egy értékes alapot, amelyre nagyon hasonló parancsmotorokat lehet tervezni a jövő hardvereiben. Ezek érkezhetnek más gyártóktól, de a képességek tekintetében ugyanazt kell kínálniuk, és ha belegondolunk, akkor ez a fejlesztők munkáját alaposan meg fogja könnyíteni.
