Manapság a PC-s játékosok számára teljesen világos, hogy az alacsony szintű hardverelérést biztosító grafikus API-k jelentik a jövőt, hiszen érkezik a Microsoft DirectX 12, illetve elérhető az AMD Mantle is, tehát a PC-piacot sújtó hardveres kihasználásra vonatkozó problémáknak hamarosan vége. Ezeket a gondokat korábban részletesen elemeztük, így nem ismételnénk meg újból, de az kétségtelen tény, hogy az alacsony szintű hardverelérés mindenképp egy megoldás a mai limitációkra. Ezt az is bizonyítja, hogy 80-nál több fejlesztő rendelkezik a Mantle SDK-val, illetve a Microsoft is utalt rá, hogy a DirectX 12 már több tucat érdeklődő aktívan teszteli. A fejlesztők szerint tehát ez a jövő, így az új API-k létjogosultságáról nincs értelme beszélni, mert ezt már eldöntötte a piac.
A Radeon R9 285 megjelenésével azonban felmerül pár érdekes kérdés is, amelyet korábban nem elemeztünk, pontosabban elméleti szinten nem volt róla szó, hogy probléma lesz. Mint ismeretes az AMD az új hardver esetében már a Tonga cGPU-t használja, amely lapka a legújabb, GCN V.I. nevű architektúrára épül. Az eredeti GCN S.I. és az előző C.I. opcióhoz képest a V.I. verzió lényeges módosításokat vezet be, amelyek növelik a rendszer hatékonyságát, ám az újítások nem feltétlenül kedveznek a régebben megírt, alacsony szintű Mantle kódoknak. A Tonga ugyanis a Battlefield 4 és a Thief Mantle módja alatt rendre 6-8 és 10-15 százalékkal teljesít rosszabbul, mint DirectX 11-ben – feltételezve persze, hogy nincs processzorlimit. Ez a jelenség a többi GCN architektúrára épülő hardverhez képest is feltűnő, kiemelve mondjuk a szintén 2 GB-nyi memóriával rendelkező Radeon R9 270X-et, hiszen utóbbi termék például még processzorlimit nélkül sem lassul Mantle alatt. A jelenség furcsamód nem érinti a Plants vs. Zombies: Garden Warfare című játékot, így ott a Mantle mód mindegyik hardverre kedvező hatással van.
Az AMD szerint a probléma forrása az, hogy amikor a Battlefield 4 és a Thief Mantle módja készült, akkor a Tonga még nem volt elérhető a fejlesztők számára, így nem tudtak rá optimalizálni. A Plants vs. Zombies: Garden Warfare című játékot ez a jelenség tehát azért nem érinti, mert májusban már szinte minden érintett kapott egy mérnöki mintát a termékből. A fejlesztőktől származó információink szerint a Tonga teljesítményét a memóriavezérlés hátráltatja, amelyet a Battlefield 4-ben és a Thiefben nem tudtak a GCN V.I. architektúrára optimalizálni. Ugyanakkor az érintettek kiemelik, hogy a Mantle által kifejtett hatás a processzorlimit csökkentésére továbbra is ugyanúgy él, vagyis a vásárlók nagy százaléka így is gyorsulást fog érzékelni, mert DirectX 11-ben alapvetően processzorlimitbe ütköznek majd – főleg a Battlefield 4 többjátékos módjában. Ezt az AMD is megerősítette, és tulajdonképpen logikus is, hiszen a nem teljesen optimális memóriavezérlés az API hatékonyságából eredő szoftveres előnyökön nem változtat. Mindemellett egyik érintett sem zárkózik el attól, hogy egy később érkező frissítésben a GCN V.I. architektúrára is optimalizálják a memóriavezérlést az említett két játékban, míg az új programokban ez eleve meg lesz oldva.
Az alkalmazástól a hardverig [+]
Bár itt tényleg csak két programról van szó, tehát reális lehetőség ezekhez készíteni egy javítócsomagot, de óhatatlanul ott motoszkál bennünk a kérdés, hogy ez állandó jelenség lesz-e. Ennek érdekében több érintettet is megkérdeztünk, és nem túl kedvezők a válaszok. Azt tudni kell, hogy a DirectX 12 és a Mantle működése nagyon hasonló. Gyakorlatilag abban módosítanak a mostani modellhez képest, hogy a grafikus meghajtó nem igazán lesz több, mint egy shader programok futtathatóságát lehetővé tevő réteg. A többi funkciók persze nem tűnik el, csak amíg a DirectX 11-ben ezek a grafikus meghajtóban voltak, addig a DirectX 12 és a Mantle alatt átkerülnek magába az alkalmazásba. A fejlesztők szerint ez a modell valóban tökéletes kompatibilitást biztosít több architektúrához is, így a gyártóknak csak követniük kell az adott API előírásait. Ugyanakkor az alacsony szintű elérés következtében a kód teljesítménye már nem portolható hatékonyan. Ez azt jelenti, hogy az adott videojáték-motor alacsony szintű grafikus API-hoz szabott leképzője optimalizált lesz pár architektúrára, míg a többi architektúrán – kiemelve a program kiadása után érkezőket – már nem fut olyan jól. Ugyanakkor a fejlesztők szerint itt nem kell extrém különbségekre gondolni, így maximum 20-30%-os deficitről lehet szó, amit bőven kárpótol az alacsony szintű hozzáféréssel elérhető hatékonyság.
A piac egyébként ezt nem tekinti olyan jelentős problémának, mint aminek így első ránézésre látszik. A legtöbb érintett úgy áll hozzá, hogy mindenképp lesz egy domináns architektúra, amit célozni kell, míg a többi gyártón egyszerűen elég, ha a kód lefut valamilyen sebességgel. Ennek megfelelően előfordulhat olyan szituáció, hogy amíg ma a DirectX 11-ben két eltérő gyártótól származó, de azonos sebességű hardver szinte minden programban egymás nyakán van, addig a DirectX 12-ben az alacsony szintű elérésre vonatkozó kód az egyik architektúrának optimális, míg a másiknak nem, így az egymás mellett csatázó két hardver között az új API-val már komoly teljesítménykülönbség lesz. Ez tisztán abból ered, hogy a szoftvert nem fogják minden architektúrára a végletekig optimalizálni, tehát a két hardver elméleti teljesítménye nem változik, de az egyik szoftveres oldalról egy nem szándékos büntetést könyvel el.
A fejlesztők szerint nagyon fontos lesz, hogy az új érában mindenki dokumentálja az architektúráit. A programozóknak pontosan tudniuk kell, hogy ezek mire képesek, hiszen csak így lehet rájuk optimális kódot írni. Amennyiben ez nincs meg, akkor nem tudnak bizonyos nem dokumentált architektúrákra optimalizálni, mert egyszerűen nem ismerik azok működését. Márpedig alacsony szintű hardverelérés mellett ez kritikus tényező lesz. Mindemellett kiemelendő, hogy bár az érintett stúdiók otthon érzik magukat az alacsony szintű grafikus API-kban, hiszen évek óta programoznak hasonló környezetben a konzolokra, a több architektúrán futtatható alacsony szintű elérés teljesen új terep. A fejlesztők úgy gondolják, hogy bizonyos, ma még teljesítményesést okozó kódrészletekre van orvosság, hogy a jövőben ez ne következzen be egy-egy új architektúrára épülő hardver érkezésekor. A probléma csupán az, hogy még senkinek nincs elég tapasztalata ezzel kapcsolatban, tehát a kutatások a fenti jelenség enyhítésére vonatkozóan csak most indulnak be. Teljesen egyértelmű, hogy alacsony szintű eléréssel sokkal egyszerűbb egy fix hardvert célozni a konzolokban, míg sok PC-s konfigurációnál szimplán nincsenek konkrét elemzések több architektúra hatékony programozásáról. Ez azonban az elkövetkező két-három évben mindenképpen egy vezető kutatási irány lesz.
