Az elmúlt hetekben több olyan felhasználói teszt is készült, amelyek arra utaltak, hogy az első generációs GCN-es Radeonokon eltűnt az aszinkron compute. Persze ennek a rendszernek az ellenőrzése igen nehéz, de utánanéztünk annak, hogy mi igaz az egészből, illetve gyakorlatilag mi is történt, vagy történik itt.
A GPUView programmal ténylegesen kideríthető, hogy az adott program futtatása során lesz-e compute queue vagy sem. itt függetlenül a sebességtől gyorsan kideríthető, hogy az aszinkron compute aktív-e. A GCN2, GCN3 és GCN4 architektúrával a teszthez használt nBody DirectX 12 sample esetében mindig volt compute queue, de a GCN1-nél már nem. Ugyanez volt igaz a Hitman című játékra is, tehát valami változás tényleg történt, és az aszinkron compute nem aktív a legelső GCN-nél. Ugyanakkor elővettünk egy nem publikált hobbiprogramot is, amely gyakorlatilag egy nagyon egyszerű DirectX 12-es példa, amivel viszont már volt compute queue az összes GCN verzión. Ezek egymásnak eléggé ellentmondó információk, így muszáj volt utánanézni, hogy mikortól történt valami változás, és persze, hogy miért.
A meghajtókat végigpróbálva a 16.4.2-es Radeon Software volt a váltópont, ami után a GCN1-es Radeonokon számos alkalmazásra limitációk lettek bevezetve. Mint ismeretes a DirectX 12-ben olyan, hogy aszinkron compute nem igazán van. Az API multi-engine és szinkronizációnak nevezi az egyes eltérő parancslisták párhuzamos futtathatóságát. Emiatt a Microsoft megköveteli, hogy a gyártók DirectX 12-es implementációi támogassák a multi-enginet és szinkronizációt, ami tulajdonképpen csak arra szolgál, hogy maga az eszközillesztő minden beérkező parancsot elfogadjon. Ezeket a főleg compute és copy parancsokat azonban nem kötelező továbbítani a hardvernek, mivel elképzelhető, hogy grafikus vezérlő nem tudná hatékonyan megoldani a futtatásukat, így a meghajtó dönthet úgy, hogy visszaküld mindent az operációs rendszernek, ami aztán berakja a parancsokat a fő parancslistába.
Effektíve tehát általánosan nem lehet letiltani az aszinkron compute funkciót, csupán annyit lehet meghatározni, hogy egy parancs melyik parancslistán keresztül fusson be a hardverbe. Ezt alkalmazásszinten kell vezérelni, ami rákényszeríti a gyártókat arra, hogy minden programot leteszteljenek és döntsenek arról, hogy az aszinkron compute az adott programon belül az adott hardvernek előnyös-e. Ha igen, akkor a meghajtó elfogadhatja a parancsokat, ha pedig nem, akkor visszaküldheti az operációs rendszernek. Úgy néz ki, hogy az AMD meghajtója a tavaszi fordulópontig az egyes kiadott programokra mindig elfogadta a compute parancsokat és a meghajtó továbbította azokat a hardver felé, de a 16.4.2-es Radeon Software után több programnál is inkább visszaküldi őket az operációs rendszernek, ha a hardveren belül az architektúra GCN1-es. Ez azt is megmagyarázza, hogy egy nem publikált példaprogramon belül miért működik az aszinkron compute, erre nyilván nem tudtak írni profilt, hiszen nem lett beküldve elemzésre.
További kérdezősködéssel kiderítettük az okokat is. Az AMD rendszerprogramozói még az év elején találtak néhány esetet, amikor a GCN1-es Radeonok a programok aszinkron compute implementációjára nem úgy reagáltak, ahogy kellett volna. Ez ugyan a sebességre nem volt hatással, de kellemetlen akadásokat eredményezhetett az alkalmazások futtatása közben. Tavasszal az AMD úgy döntött, hogy az érintett programoknál úgy állítják be a meghajtóba épített profilokat, hogy a compute parancsokat inkább küldjék vissza az operációs rendszernek, ami gyakorlatilag egyenlő azzal, hogy nem lesz compute queue, így nem fog működni az aszinkron compute. Ez azonban nem végleges állapot, mivel a cég próbál specifikus kerülőutakat találni megoldásképpen, amelyeket lassan beépíthetnek a programokhoz tartozó profilokba, és apránként vissza lehet kapcsolni a funkciót. Erre vonatkozóan azonban nincsen konkrét dátum.
A Rise of the Tomb Raider esetében is a specifikus problémák miatt döntöttek úgy a fejlesztők, hogy már az alkalmazás oldalán single-engine működésre kényszerítik a GCN1-es Radeonokat, így a meghajtó sosem kap compute parancsot, amit esetleg vissza kellene küldenie.
Érdemes megjegyezni, hogy a Vulkan API-t a fentiek jelenleg nem érintik. Bár maga a probléma potenciálisan előjöhet egy Vulkan API-ra írt alkalmazás alatt is, ugyanakkor eddig egyetlen ilyen program sem született, így az AMD jelenleg nem látja szükségesnek a compute queue letiltását a GCN1-es Radeonokon.
A fentiek mellett megtudtuk azt is, hogy a DirectX 12 és a Vulkan API modellje a multi-engine és szinkronizáció működése tekintetében nagyon hasonló, ami egyrészt jó, ugyanakkor a tervezésnél a Microsoft és a Khronos Group nem igazán vette számításba az elérhető hardvereket. Egyszerűen kreáltak egy relatíve hatékony elgondolást, aminek igazából ma csak a GCN2, GCN3 és GCN4 architektúrára épülő Radeonok tud maradéktalanul megfelelni. Ez persze nem jelenti azt, hogy a GCN1-es Radeonok, illetve a Maxwell és Pascal architektúrára épülő GeForce-ok ne tudnák támogatni az API-kba épített konstrukciót, de – architektúrától függően – kevés vagy esetleg sok körülmény mellett a hardverek nem reagálnak jól az igénybevételre, ami teljesítménycsökkenéshez, illetve akadásokhoz vezethet. Ilyen esetben érdemes megfontolni a compute parancsok meghajtóból történű visszautasítását DirectX 12 alatt, míg Vulkan esetében megkérni a fejlesztőket, hogy kényszerítsenek egy single-engine kódot az adott architektúrára. Rövidebb távon ez mindenképpen kellemetlen a piacnak, de hosszabb távon jobb volt egyből nagyot lépni előre, mint később foltozgatni az API-t.
