Az NVIDIA a GDC-n egy előadás során röviden bejelentette, hogy készítenek egy hatékonyabb DirectX drivert az érkező játékokra, illetve a mostani DirectX 11-es programok esetében is lesz ennek létjogosultsága, különösen akkor, ha az alkalmazás támogatja a deferred context funkciót. A bemutatóhoz használt StarSwarm új verziója, illetve a Thief ilyen program, bár előbbi tesztalkalmazás a deferred context bevetésével instabillá válik (különösen a ScenarioRTS mód alatt). Később persze ezeket a hibákat úgyis javítják, illetve maga a tesztfelállás alfa állapotú, és ilyenkor eleve nem biztosított a tökéletes stabilitás.

Az NVIDIA a részletekről meglehetősen szűkszavúan nyilatkozott, illetve erről a kép sem ad részletes beszámolót. Az eredmények ugyan leolvashatók, de a beállítások már nem. A GDC-ről származó információk szerint úgy tudjuk, hogy a StarSwarm a rajzolási parancsok szempontjából alacsony terhelésű ScenarioFollow módot használta, míg a Thief Full HD-nél is nagyobb felbontásban (2560x1440 vagy 2560x1600 pixel) futott maximum beállításon, még az SSAA-t is a legjobb opcióra állítva. A Thief grafikonján nincs feltüntetve az AMD Radeon R9 290X DirectX-ben mért sebessége, de az előbbi beállításokon nagyjából ugyanúgy teljesít, mint Mantle módban – alig 1-2 képkocka/másodperccel lehet rosszabb a tempója.

[+]

A legfőbb kérdés, ami felmerül, hogy lehetséges-e? Igazából vannak olyan optimalizációk, amelyekkel megvalósítható. Már évekkel korábban is meg lehetett volna ezeket írni, de nem biztos, hogy megéri a befektetett erőforrást. Az NVIDIA szerint bevállalható, míg az AMD – a vezető fejlesztők könyörgésének eleget téve – inkább egy újraindítást szorgalmazott a piac számára.

Ami biztos, hogy az aktuális DirectX API a működése tekintetében nem éppen úgy használja a modern erőforrásokat, ahogy kellene. A driver viszont ezt valamilyen mértékben képes korrigálni. Csodát persze nem tud tenni, de vannak tipikusan olyan szűk keresztmetszetek, amelyekre lehet optimalizálni. A fejlesztők legfőbb gondja a mai játékok kapcsán, hogy a motorokat úgynevezett job rendszerűre tervezik, ami biztosítja azt, hogy igen nagy hatékonysággal használhassák ki akár a nyolc, vagy több maggal rendelkező processzorokat is, de ezt nem tehetik meg, mert a DirectX működési modellje ebbe beleszól. Nem is a többszálú leképzés a legnagyobb gond, hanem az, hogy a grafikus driverek rengeteg úgynevezett szerver szálat futtatnak a programmal párhuzamosan, amelyeket ráadásul a fejlesztő nem is lát, miközben elveszik az erőforrást az alkalmazástól. A PC-s fejlesztés során nagyon tipikus helyzet, hogy a jobb párhuzamosítás hozzáadásával a program egyszerűen elkezd lassulni, a probléma forrása pedig, hogy a driver szerver szálak és a programszálak elkezdenek versengeni az erőforrásért. Ez ugyan programon belül is előfordul, de a fejlesztő ilyenkor látja a nem tökéletes működést és segít rajta, a driverre azonban nem tud optimalizálni. Ilyenkor a legjobb módszer, ha egy vagy két (deferred context esetében három is ajánlott) processzormag szabadon marad a driver számára.

A modern API-k szempontjából a DirectX 12-ben például ez már nem lesz probléma, mivel nagyon kevés driver szerver szál futhat majd, míg a Mantle ezt a működési koncepciót teljesen eliminálta, így a fejlesztőé az összes látható erőforrás. Az aktuális DirectX-ben viszont sajnos viszonylag sok szál fut, és ráadásul ezek igen sűrűn soros feldolgozásra kényszerítik a rendszert. A driverben viszont nagy kérdés, hogy mégis hány szál fusson, azok hogyan legyenek ütemezve, és hasonló problémák, amelyekre sajnos nincs ideális megoldás, de kellő erőforrás befektetésével lehet törekedni az egyensúlyra. Kellően gyors processzor mellett ez hozhat némi gyorsulást, különösen a deferred context funkciót használó játékokban, de olyan szinten nem lesz, mint a DirectX 12 vagy éppen a Mantle, tehát a gyengébb processzorokon a futtatás sebessége limitált marad, vagy rosszabb is lehet.

A driverek másik nagy optimalizálási területe a rajzolási parancsok agresszív pufferelése. Itt folyamatosan lehet sebességet nyerni, de ennek ára is van, mivel a jobb pufferelés növeli a késleltetést. Ezen a ponton sosem értettek egyet a cégek. Az NVIDIA szerint a késleltetés növelése nem gond, az Intel szerint pont az alacsony késleltetés a lényeg, míg az AMD szerint van egy ideális szint, ami még vállalható. Ez is mutatja, hogy mennyire eltérő az optimalizációs cél, de igazából jó döntés sincs, mert a jó sebességhez pufferelni kell. A késleltetés növelése viszont pár játékos számára kellemetlen jelenség is lehet, de az API nagyon korlátozott működése miatt valamennyit mindegyik cég bevállal. Az új driverekkel az NVIDIA többet enged meg, mint korábban, ami természetesen növeli majd a sebességet is. Az Intel lépése még kérdéses, de ugyanezt ők is megtehetik. Az AMD valószínűleg ezzel a módszerrel már nem él, mert a Mantle zéró driver oldali késleltetés mellett is tudja azt a sebességet, amit a DirectX. Ezen a gondon egyébként a DirectX 12 is nagyon-nagyon sokat segít majd, így a 2016-tól várhatóan minden vállalat a minimális késleltetésre törekszik majd, hiszen a Microsoft új API-ja sem teszi szükségessé a rajzolási parancsok agresszív pufferelését. Nem mellesleg a driver oldalán minimalizált késleltetés alapvető feltétele a virtuális valóság működésének.

Az NVIDIA koncepciója egyébként nem a DirectX 11 életben tartásáról szól. Azzal már nem lehet mit kezdeni, mert az API nem működik hatékonyan, az optimalizálások hátrányokat szülnek, így a sebességnövekedés kompromisszumot is hoz. A stratégia inkább az, hogy ki kell húzni a DirectX 12-ig, ami a problémák nagy részét megoldja. A GDC-ről származó adatok szerint addig nagyjából másfél-két tucat Mantle játékot kell átvészelni, és ezekre akár direkten optimalizálni a drivert. Ez a játék megjelenésétől számolva beletelhet egy-két hónapba, de a sebességet bármi áron növelni kell. A GDC-n az is kiderült, hogy a DirectX 12 megjelenése után is érkeznek majd Mantle játékok, de onnantól már a szabványos API strukturális működése hozza az elegendő sebességet, mindenféle kompromisszum megkötése nélkül, tehát ebből gond nem lehet.