Már készül az új 3DMark verzió, amely elhozza a PC-sek számára a Dandia kódnevű tesztet, amely hivatalosan a Time Spy nevet viseli és a Galax GOC 2015-ös rendezvényen látni is lehetett egy rövid részletet a DirectX 12-n futó tesztprogramból.
A Time Spy által használt eljárásokról az elmúlt napokban érdeklődtünk és az egyik legérdekesebb dolog, amit megtudtunk, hogy az DirectX 12 egyik leghasznosabb képességét nem valószínű, hogy hasznosítani fogja. Nevezetesen az aszinkron shaderről vagy más néven aszinkron compute-ról van szó. Bár a kód teljes mértékben támogatja a DirectX 12 multi-engine funkcióját és lesz aszinkron DMA is, a párhuzamosan futtatott grafikai és compute futószalagok használata azonos kódbázissal nagyon nehézkes.
Azzal természetesen mindenki tisztában van az iparágon belül, hogy az aszinkron compute lesz az új játékok leginkább használt képessége a DirectX 12 esetében, mivel kvázi ingyenessé teszi a compute shaderek használatát, amitől például a nem publikus Fable Legends tesztprogram alatt az LPV globális illumináció 50, míg a fényszimulálás 69 százalékot gyorsul, miközben az eredmény ugyanaz. Ez a különbség a végleges sebességre levetítve is 5-20% közötti extrát jelent az említett alkalmazásba – persze hardvertől függően. Ugyanakkor a Fable Legends inkább játék, mint tesztprogram, így a fejlesztők az egyes hardverekre más optimalizálásokat alkalmaztak, hogy mindenen a lehető legjobb sebességet érjék el.
Egy 3DMark esetében azonban a különálló optimalizálást nem szokás alkalmazni, mivel az egyik alapja a tesztprogramnak az azonos kódbázis megléte. Mondhatni így tisztességes. Ez persze felfogás kérdése, illetve lehetne vitázni azon, hogy ez jó vagy rossz, de a 3DMark ilyen felfogásban születik meg.
Itt jön elő az aszinkron compute problémája. Ha nem lehet hardverspecifikus optimalizálásokat bevetni, akkor hogyan legyen alkalmazva a grafikai és compute futószalagok párhuzamos futtatása? Többször is leírtuk már, hogy a DirectX 12 multi-engine specifikációi meglehetősen szigorúak, mivel minden parancsprocesszortól megkövetelik, hogy támogassák az úgynevezett erőforrás-korlátozást. Ma ez nem gond, mivel a fő parancsprocesszor, vagyis legalább egy egység minden hardveren belül megfelel ennek a követelménynek. Számos hardver azonban már több parancsprocesszort alkalmaz, elsődlegesen azért, hogy a compute aszinkron formában is futtatható legyen, és itt már viszonylag sok az eltérés. A DXKG (DirectX Kernel Graphics) specifikációit figyelembe véve aszinkron compute-ot támogató architektúrának tekinthető az AMD-től a GCN1, GCN2 és GCN3, illetve az NVIDIA-tól a második generációs Maxwell. Ugyanakkor eltérés, hogy amíg a GCN architektúrákon belül minden egyes parancsprocesszor támogatja az erőforrás-korlátozást, addig a második generációs Maxwell esetében erre csak a fő parancsprocesszor képes. Az aszinkron compute-hoz ugyanakkor ez is megfelel, mivel a Microsoft csupán azt kéri, hogy a hardverben legyen legalább egy erőforrás-korlátozást támogató parancsprocesszor, de az eltérő alapok miatt az optimalizálást is eltérően kell alkalmazni.
A fentiekkel kapcsolatban megtudtuk, hogy az aszinkron compute-ot a második generációs Maxwell architektúrára úgy érdemes optimalizálni, hogy grafikai és a compute feladatok lehetőség szerint a lehető legtovább fussanak, észben tartva persze a megfelelően gyors preempció hiányát. Ez elsődlegesen azért fontos, mert az NVIDIA legmodernebb architektúrájának az ütemezője radikálisan egyszerűsödött a korábbi generációkhoz képest, és emiatt egy üzemmódváltás beiktatása borzalmasan drága lett, vagyis ezeket a helyzeteket ritkítani kell. Az aszinkron compute-ot végeredményben leginkább a többletterhelés csökkentésére lehet alkalmazni a második generációs Maxwell architektúrán, és ebből 3-8%-os előnyt lehet kovácsolni. Ugyanakkor ez a fajta optimalizálás az AMD GCN architektúráinak a teljesítményét 2-6%-kal ronthatja.
Az AMD GCN architektúrái esetében az aszinkron compute-ot eltérően érdemes használni. A legjobb módszer a hosszú ideig futó compute futószalagok kiszervezése a dedikált compute parancslistákba. Ezek a grafikai futószalagok mellett minden beállítható üzemmódban futhatnak, tehát üzemmódváltásra egyáltalán nincs szükség. A robusztus ütemező lehetővé teszi a compute futószalagok magasabb prioritását is, így a fejlesztők élhetnek ezzel az optimalizálással, ha a végeredményt tekintve előnyös. A GCN architektúrákon leginkább a compute futószalagokat érdemes kiszervezni, amennyit csak az adott körülmények között meg lehet engedni, és így végeredményben 10-60%-os előnyt lehet kovácsolni. Ugyanakkor ez a fajta optimalizálás az NVIDIA második generációs Maxwell architektúrájának a teljesítményét a töredékére csökkentheti, mivel ez a rendszer a beállítható üzemmódok nagy többségében nem képes egyszerre futtatni grafikai és compute feladatot, ami gyakori üzemmódváltást eredményez.
Bár a játékok szempontjából a fentiekből nincs gond, mert az AMD és az NVIDIA hardverei is kaphatnak megfelelően optimalizált aszinkron compute-ot. Ezeket ráadásul nem is nehéz működésre bírni, így mindkét vállalat felhasználóbázisa élvezheti a könnyen beépíthető specifikus optimalizálások előnyeit, legyenek azok nagyok vagy kicsik. Viszont egy tesztprogram esetében azonos kódbázis mellett valamelyik gyártó rosszul járna. Mivel a 3DMarknak a legkevésbé sem hiányzik egy újabb GeForce FX-es időszak, végeredményben célszerű lemondani az aszinkron compute-ról.
