A Hardware Unboxed egy friss videóval örvendeztette meg a nézőit, amelyben bemutatták, hogy a GeForce VGA-k meglehetősen furcsa módon reagálnak arra, ha egy nagyobb teljesítményű, Ryzen 5 5600XT processzor helyére valamivel lassabb modell kerül, például Ryzen 5 1600X, 2600X és 3600X, illetve Core i3-10100. A mérések alapján a GeForce-ok nem úgy reagálnak a váltásra, ahogy az elvileg várható lenne, értve ez alatt, hogy a lassabb CPU-k hatására a teljesítményük lényegesen visszaesik a Radeonokhoz viszonyítva. Többek között a Watch Dogs: Legion és a Horizon Zero Dawn játékokban az is előfordulhat, hogy egy fenti processzorokból leglassabbnak számító Ryzen 5 1600X-en, Full HD-s felbontás és közepes részletesség mellett egy Radeon RX 5600XT is hasonló tempóra képes, mint egy GeForce RTX 3090. Persze a részletesség növelésével egyértelműen a csúcs-GeForce kerül előnybe, vagyis egy ponton túl elkezd helyreállni a világ rendje még a legidősebb Ryzenen is.
A Hardware Unboxed a számos elvégzett mérés után arra a következtetésre jut, hogy a GeForce driverek többletterhelése nagyobb a Radeon Software-hez viszonyítva, és ez okozza azt, hogy a GeForce VGA-k skálázódása egy adott paraméterezéssel, illetve egy adott konfiguráción elkezd erős limitekbe ütközni, miközben a Radeonok még elég jól érzik magukat. Szó se róla, amit látunk az valóban CPU-limit, de lényeges kiemelni, hogy az összes tesztben szereplő játék DirectX 12-es módban futott. Ennek azért van jelentősége, mert ez egy explicit API, vagyis pont az a lényege, hogy a meghajtótól elvegyen számos olyan feladatot, ami például a DirectX 11-nél jelentős többletterhelést eredményezett, és ezekről innentől kezdve az alkalmazás gondoskodik.
A fentiek persze nem azt jelentik, hogy a DirectX 12-es meghajtóimplementációknak egyáltalán nincs szerepük a végleges teljesítmény kialakításában, de a Microsoft legújabb API-jával pont azért menedzselheti az alkalmazás a parancsátadást, hogy az program számára optimális időpontoknál kerüljenek a GPU-hoz az egyedi, szintén alkalmazásspecifikus konfiguráció alapján csomagolt rajzolási parancsok, ráadásul mindezt akár explicit párhuzamos formában is el lehet végezni. A DirectX 12 esetében tehát klasszikus értelemben nem igazán lehet a meghajtó többletterheléséről beszélni. Ugyan létező jelenségről van szó, de egyáltalán nem olyan jelentős mértékű, mint például a DirectX 11-es API-nál, és pláne nem okozhat ilyen extrém különbségeket, amiket a fenti tesztben lehet látni.
A potenciális gondokat sokkal inkább maga az alkalmazás generálhatja. Azzal ugyanis, hogy az explicit API lehetőséget ad a hardverek közvetlenebb programozására, a meghajtót is megfosztja a korábbi API-kban jellemző munkafolyamatok egy jó részétől. Ezek ugyanakkor nem tűnnek el teljesen, csak az alkalmazás gondoskodik róluk. Következésképpen nagymértékben a programkód fogja meghatározni, hogy egy hardver bizonyos körülmény mellett mire képes, és ezt igen limitált módon tudja csak befolyásolni egy DirectX 12-es meghajtóimplementáció.
Az előbbiek miatt a tesztcímek limitált száma nem jelent előnyt, ugyanis lényegében a Hardware Unboxed azokat a játékokat mutatta be, amelyeknél fellép a részletezett probléma. Ez itt a kulcstényező, mivel az érintett alkalmazások, bizonyos körülmények mellett nem futnak elég optimálisan a GeForce-okon. Itt jön képbe az, hogy az explicit API-k nem számítanak csodának. Sokkal inkább úgy érdemes tekinteni rájuk, hogy segítenek a korábbi, erős limitációkat okozó problémák leküzdésében, cserébe néhol megnehezítik a fejlesztők dolgát. Ennek hatására azok a hardverek előnyben lehetnek, amelyeken konkrétan zajlott magának a programnak a fejlesztése, és ez azzal magyarázható, hogy ezekkel van az adott stúdiónak a legtöbb tapasztalata. Ha a tesztjátékok között főleg nagyobb stúdiók címei szerepelnek, akkor az nem túl szerencsés, mert azok zömét AMD Radeonokon fejlesztik, illetve fejlesztették. Ennek három oka van: egyrészt az újabb Xbox és PlayStation konzolokról így a legegyszerűbb a portolást megkezdeni, másrészt az AMD biztosít PC-re olyan profilozót, amely hardveres nyomkövetést használ, harmadrészt pedig az AMD kínál memóriaelemzőt PC-s környezetben. Utóbbi két fejlesztőeszköz igen fontos a portolás kezdeti szakaszaiban, hiszen az explicit API-t használva bizonyos, programkódban megbúvó hibák hardveres nyomkövetéssel dolgozó profilozó, illetve teljes memóriaelemző nélkül egyszerűen nem térképezhetők fel. Más profilozókban előfordulhat, hogy szimplán nem látszódnak, következésképpen nagyon specifikus eszközöket kell használni a javításukhoz, és ezek a programok egyelőre csak Radeonon működnek.
A fenti fejlesztési modell magával hoz egy olyan gondot is, hogy a felfedezett programhibákat az AMD fejlesztőeszközeiben ellenőrzött eredmények alapján javítják. Ez önmagában még nem lenne baj, mert magáról a hibáról tudomást szereztek a programfejlesztés során, tehát később, amikor a GeForce hardverekre is megkezdik az optimalizálást, akkor ugyanúgy le lehet ellenőrizni, hogy az AMD javaslatai alapján elvégzett, és Radeonokon jónak tűnő változtatások mennyire befolyásolják az NVIDIA hardvereinek teljesítményét. Ha nagyon, akkor azt relatíve könnyen lehet korrigálni, mert a hiba már ki lett javítva, csak a megoldást kell optimalizálni a GeForce-okra is. Nem biztos azonban, hogy ezt minden stúdió ellenőrzi. Azt is mondhatják, hogy Radeonokon működnek a javítások, elvileg jónak kell lenniük máshol is. Elvi feltevésre azonban nem mindig érdemes építeni, és így elszigetelt esetekben maradhatnak kisebb limitációk azokon a VGA-kon, amelyek arányaiban kevesebb optimalizálásban részesültek az alkalmazás fejlesztése során. Mindez régebben, a DirectX 11-es érában is előfordulhatott, csak akkor rengeteg dologért maga a grafikus meghajtó felelt, tehát a gyártók tudták korrigálni a problémákat. Most azonban a programkódnak van döntő szerepe, abba pedig nem lehet a driveren keresztül belenyúlni.
A fentieken alapján tehát nem feltétlenül a GeForce meghajtót érdemes bűnösként emlegetni. Talán lehet valamennyit nyerni az adott API implementációjának oldalán is, de ahol az igazi limit keletkezik az a programkód, amit alkalmazásfrissítésekkel lehet módosítani. Persze kérdés, hogy ez mennyire fontos, mert közel sem biztos, hogy olyan sok alkalmazást érint a bemutatott jelenség, és az sem túl életszerű, hogy egy erősebb GeForce-on a felhasználók Full HD-s felbontást, illetve közepes részletességet állítanak be, nem beszélve a processzorválasztásról. Ez innentől kezdve egy fejlesztői döntés is, mert a projektbe fektetett erőforrások esetlegesen limitáltak lehetnek, ami olyan döntéseket is eredményezhet, hogy bizonyos ismert, de nem kritikus fontosságú problémákra sosem lesz javítás. Egy program ezek mellett is képes funkcionálisan hibátlanul futni, csak nem feltétlenül olyan teljesítménnyel, ami elméletben kivitelezhető lenne.
Az, hogy mennyire fontos ez a probléma a piac számára leginkább attól függ, hogy hány játékot érint pontosan, viszont erre a kérdésre nem ad választ a Hardware Unboxed tesztje. Ezzel együtt maga a gond bemutatható kiválasztott címeken, de ha mellette még teszem azt tíz DirectX 12-es programban nem jelentkezik ugyanez a limitáció, akkor azt nehéz eladni egy általános többletterhelési meghajtóproblémának. Amúgy is, hiszen a DirectX 12 pont azért készült, hogy ezek a tipikus tényezők vissza legyenek szorítva, és a hardverek kezelése legyen sokkal közvetlenebb a fejlesztők számára.
