Mit lehet tenni a DirectX-ért?
Az előbbi oldalon tárgyaltak alapvetően szoftveres korrekciók, tehát nincs igazából lényeges követelményük a hardverre vonatkozóan. Ugyanakkor nem lehet elmenni amellett szó nélkül, hogy a mai modern grafikus processzorok már sok helyen teljesen másképp működnek, mint a DirectX API. Többek között az AMD GCN és az NVIDIA Kepler architektúrája támogatja a bindless modellt, ugyanakkor a szabványos API-k ezt képtelenek kihasználni. Ez nem kis probléma, mivel a DirectX úgy tekint a GPU-kra, mint egy CPU-nak kiszolgáltatott buta szolgára, holott a mai grafikus vezérlők már annyit tudnak, mint egy központi processzor.
A Microsoft API-ja a működést tekintve számos slotot biztosít a fejlesztőknek, amelyek logikailag a virtuális utasításarchitektúra regisztereinek foghatók fel. Amikor a program beköt egy slotot, akkor a driver rengeteg munka elé néz, ugyanis a textúraadatokat olyan adatstruktúrába rendezi, amit a hardver megért. Ez kifejezetten sok erőforrást igényel a processzortól, pedig a modern GPU-kon erre nem lenne szükség. A bindless modellel ugyanis a grafikus vezérlő egy pointert kap, amit követve megtalálja a szükséges textúrainformációt. Persze ehhez tényleg AMD GCN és az NVIDIA Kepler architektúrájú hardver kell, de írható lenne egy olyan DirectX 11.1-es kiterjesztés, ami enyhe korlátozások mellett ugyan, de kihasználná az említett két rendszer működését. Nem is igazán értjük, hogy ezt a Microsoft miért nem lépte meg eddig.
Hirdetés
Az occlusion query technikán is lehetne javítani. Mint ismeretes, ez az eljárás jelzi, hogy melyik objektum van más objektum által takarásban a feldolgozandó képen. Amennyiben az eltakart objektum nem látszik, felesleges erőforrást pazarolni rá, így azt a rendszer kivágja még a leképzés megkezdése előtt. Az előzetes leképzést megoldja a grafikus processzor, de az így generált adatokat csak a központi processzor képes olvasni. A DirectX-ben tehát a GPU által kreált eredményt vissza kell másolni a CPU-nak, amely eldönti, hogy mit kell kirajzolni és mit nem, de az adatok másolása önmagában több időt vesz igénybe, mintha a processzor egy szoftveres futószalaggal átvenné az előzetes leképzés munkáját, és úgy értékelné ki a végső képkocka szempontjából fontos objektumokat. Viszont a kiértékelést el tudnák végezni a modernebb GPU-k, tehát egy fejlettebb API-val nem kellene a processzornak visszaírni semmit, hiszen minden helyben eldőlne a grafikus vezérlőn belül.
Szintén javítható lenne a DirectX 11-ben bevezetett deferred context funkció, ami megpróbálta a rajzolási parancsok többszálú feldolgozását megoldani. Ez nem sikerült túl jól, hiszen máig egyetlen ember volt képes hatékony implementációt készíteni, és ő is elégedetlen volt a rendszer működésével. De annak igazából nincs sok akadálya, hogy az egyes szálakon parancspuffereket kreáljon a rendszer, amit a parancslistákba betöltve rá lehet engedni a hardverre. Ráadásul ezek a parancspufferek újrahasznosíthatók is lehetnének. Önmagában ez tisztán szoftveres kérdés. Persze a Microsoft újra felrúgná a DirectX visszafelé kompatibilitását, ahogy azt tették a DirectX 10 esetében, de legalább hatékonyabb lenne a rendszer.
Az aszinkron feldolgozás előnyei a Nixxes szerint [+]
Végül megjegyezzük, hogy nagyon hasznos lenne, ha a szabvány API-k aszinkron feldolgozást is támogatnának. Ehhez persze tényleg modern hardver kell, mint az AMD GCN architektúrája, illetve az NVIDIA Kepler megoldásai közül a GK110-es és a GK208-as GPU. Ezekkel megoldható az, hogy a grafikus API egymás mellett adjon át grafikus és compute parancsokat a GPU-nak. A DirectX-ben ez nem ilyen egyszerű, mivel az API csak szinkronizált munkafolyamatot tölt be a parancslistába. Persze vannak tipikus szituációk, amelyekre a drivereket ki lehet gyúrni, így a háromszögek rajzolása valamennyire átlapolható az általános számításokkal, de ez csak tűzoltásra jó.
Sajnos tipikus eset a mai játékokban, hogy az árnyéktérképek leképzése mellett a grafikus vezérlők számítási kapacitása kihasználatlan. Aszinkron ütemezéssel azonban az előbbi számítás mellé be lehet tölteni olyan szimulációs feladatokat, mint a TressFX. A két számítás külön hardverelemeket terhel, tehát jól elvannak egymás mellett. Ennek hála tulajdonképpen mondhatjuk azt is, hogy a TressFX szimulációja kvázi ingyenessé vált. Persze ez csak egy példa, számos más szituációt el lehet képzelni, de mindenképp fejleszteni kell az API-n.
Véleményünk szerint a Microsoft túl lassan halad a DirectX fejlesztésével, ami az előbbiek mellett tisztán látszik. Persze az is világos, hogy ha nem ragaszkodnánk a visszafelé kompatibilitáshoz, akkor igazából számos területen előrébb tartana a DirectX, és az újítások nagy többsége az aktuális hardvereken is kihasználható lenne, de az AMD GCN és az NVIDIA Kepler architektúrájával biztos. Márpedig a hardcore játékosoknak igazából ez számít. Mindez csak elmélet, de a színfalak mögött biztosan nincs minden rendben, különben számos vezető fejlesztő nem rohanna egy gyártóhoz segítségért.
Ez igazából senkinek sem előnyös, még magának a piacnak sem, de önmagában többet ártana a PC-nek, ha a két új generációs konzol grafikában elhúzna a jóval drágább konfigurációktól. Vajon a Microsoft erre pályázik az Xbox One-nal? Vagy egyszerűen csak arról van szó, hogy a gyártók nem tudnak igazán megegyezni a jövőben követendő irányról? Nehéz lenne ezeket a kérdéseket megválaszolni, de úgy gondoljuk, hogy a Microsoftnak erélyesebben kellene fellépni az újítások bevezetésével, még akkor is, ha nem mindenkinek ugyanaz a jövőképe. Mivel az utolsó szó a Microsofté, így amennyiben egy új funkció nagy előnyt jelentene, akkor azt igenis írják elő, és aki komolyan gondolja a PC-s játékpiacot, az úgyis támogatni fogja.
Abu85
