A hónap elején írtunk egy cikket arról a jelenségről, amely végeredményben azt eredményezi, hogy lassabb CPU-kkal furcsán viselkednek a GeForce driverek, és ezen belül is a DirectX 12 implementációt kell érteni. Utóbbi azért érdekes, mert egy explicit API-ról van szó, vagyis a többletterhelés inkább az alkalmazás oldalán keletkezik, ugyanakkor utánakérdeztünk pár fejlesztőnél a lehetőségeknek, ami segít jobban megérteni a helyzetet.
Az egyik érdekes információ, hogy bár a DirectX 12 esetében nincs kernel meghajtó, tehát a driver nem futtat egyetlen kernel szerver szálat sem. Ezzel együtt a Microsoft az API implementációjánál elég nagy szabadságot ad a gyártóknak, vagyis amíg egy megfelelő meghajtó képes teljesíteni a hitelesítési tesztet, addig igazából a redmondi óriáscéget nem nagyon zavarja, ha bizonyos funkciókat egy DirectX 12 implementáció csak emulál. A lényeg az, hogy az említett API-ra írt programok hibátlanul fussanak.
A Microsoft a bekötési modell kezelése szempontjából enged meg viszonylag nagy szabadságot, és ezt azért teszik, mert a DirectX 12-t eleve úgynevezett pure bindless API-nak tervezték. Ebből a szempontból ez az API sokkal jobban hasonlít az AMD Mantle-jére, mint a Vulkan, aminek ugye konkrétan a Mantle adta az alapját. A Khronos Group ugyan az AMD kódját nagymértékben újrahasznosította, de pont a bekötési modellt lecserélték. Erre a konzorcium anno ki is tért egy régebbi előadáson. A Mantle bekötési modelljének a problémája az volt, hogy egészen specifikus igényei voltak a hardverre vonatkozóan, ami abból eredt, hogy az AMD kizárólag a saját GPU-architektúráira tervezte. A Vulkan ugyanakkor egy iparági szabványnak készült, tehát ki kellett alakítani egy olyan specifikációt, ami nem csak az AMD GPU-inak optimális, hanem alapvetően még az ultramobil megoldások is elvannak vele.
A Khronos Group döntése tökéletesen érthető volt, de a Microsoft API-jához viszonyítva két hátrányt eredményez. Az egyik, hogy van némi deficit ahhoz viszonyítva, mintha pure bindless bekötés lenne alkalmazva. Ugyanakkor a program oldalán így is elhanyagolható többletterhelés keletkezik csak, tehát a negatívumokat jelentősen ellensúlyozza az a pozitívum, hogy egy rakás hardverre igen optimálisan rátervezhető egy kompatibilis implementáció. A másik gond a továbbfejleszthetőség. Ebből a szempontból a DirectX 12-ben lényegesen több a potenciál, amit a Microsoft hamarosan ki is használ majd a shader modell 6.6-tal. Errefelé lépdelni a Vulkan API-nak sokkal nehezebb lesz. Ugyanakkor fontos megérteni, hogy a nagyjából hét éve jobb döntésnek tűnt az elérhető hardverekhez igazodni, mint egy évtizedes távlatban esetleg jónak tűnő jövőképet kergetni, ahogy a Microsoft csinálta. Akár az is közrejátszhatott a döntésben, hogy ha az eredetileg tervezett bekötési modell elkezdi a végét járni, majd hoznak egy újat egy frissített Vulkan API-ban.
A Microsoft tehát a pure bindless bekötés lehetőségével egy csöppet előreszaladt az előző évtized első felében, és ezt kezelték is, ugyanis a DirectX 12 bekötési modelljében három szint van megkülönböztetve. Alapvetően a hardver képességei határozzák meg, hogy melyik szintet támogathatja az adott gyártó implementációja, de a redmondi óriáscég engedékeny volt, így ha az adott GPU-nak vannak architekturális korlátjai, akkor azok opcionálisan kezelhetők emulációval. Utóbbiért már a meghajtóimplementáció felel, és nyilván egy olyan tényezőről van szó, ami a host processzorra nézve extra terhelést jelent, de nem gond az alkalmazása, a Microsoft számára csak az program hibátlan futtatása a fontos, a hogyan sokszor a partnerekre van bízva.
Ha visszaemlékezünk, akkor az NVIDIA volt az a gyártó, amely az eredeti DirectX 12-es implementációján változtatott. Kezdetben a cég a bekötési modell TIER_2-es szintjét támogatta, amit a Microsoft direkt az akkori GeForce GPU-k limitjeihez igazított. A 384.76-os eszközillesztő azonban ezt módosította, és elkezdte támogatni a bekötési modell TIER_3-as szintjét, aminek elsődleges előnye az volt, hogy leírótáblák száma nem volt többet limitálva az NVIDIA DirectX 12-es meghajtóján, illetve a UAV-k maximális száma az összes shader lépcsőn, valamint a CBV-k maximális száma shader lépcsőnként megegyezhetett a teljes leíróhalmaz méretével, ami minimum 1 048 576 bejegyzést jelentett. Erre azonban nem volt meg a hardveres alap, így a GeForce driver a támogatott GPU-architektúrák erre kialakított fix slotjai helyett a grafikus vezérlő fedélzeti memóriájába mentette el a szükséges információkat, és a bekötést a host processzor segítségével oldották meg. Utóbbi szempontból számít emulációnak ez a módszer, mivel az eredetileg pure bindless architektúrák is a fedélzeti memóriába dolgoznak, viszont a bekötéshez nem veszik igénybe a processzor segítségét, ugyanis pure bindless dizájn esetén a multiprocesszorok eleve arra lettek tervezve, hogy ezt a feladatot önállóan is megoldják.
A probléma ott van, hogy némi extra terhelése lesz a processzorra nézve ennek a működésnek, és ez nagymértékben függ ám az adott játéktól, de közel sem biztos, hogy ezzel annyit veszít az NVIDIA, mint azt az első bekezdésben linkelt, véleménytesztünkben szereplő Hardware Unboxed videó mutatja. Az AMD meghajtójával való összehasonlítás itt pont nagyon torz lehet, mivel már a DirectX 12 implementációk felépítésében is egészen nagy különbségek vannak a két cég között.
Mint ismeretes az AMD első körben a saját Mantle API-ját támogatta a meghajtón belül. Erre terveztek egy úgynevezett PAL, azaz platformabsztrakciós réteget, és maga a Mantle kliensimplementáció erre a rétegre van felhúzva. Amikor jött a DirectX 12, majd a Vulkan API, akkor az AMD nem tett mást, mint húztak egy DirectX 12, illetve később egy Vulkan kliensimplementációt a PAL-ra. Ennek a módszernek az előnye, hogy elképesztően egyszerűvé teszi a meghajtó fejlesztését, mert alapvetően csak a PAL karbantartásával kell törődni, itt dől el a teljesítmény, tehát a vörös oldal két szabványos explicit API-t is támogat közös rétegezéssel, ráadásul utóbbit lassan tíz éve fejlesztik.
Az NVIDIA Vulkan és DirectX 12 implementációja a fentiekkel szemben teljesen különálló a meghajtón belül, ami annak is köszönhető, hogy a Microsoft API-jára egészen egyedi megoldásokat használnak a zöldek, ahogy azt fentebb kifejtettük. A gondot az jelenti, hogy két szabványos API meghajtóját különálló formában nehezebb karbantartani, illetve az NVIDIA jelenleg használt DirectX 12 implementációja alig öt éves. Utóbbi egy lényeges tényező, mivel effektíve feleannyi idő sincs benne, mint az AMD saját csomagjában. Az idő pedig fontos, mert rendszerprogramozóból ugyan fel lehet venni sokat, de tapasztalatot nem lehet vásárolni.
Adódik a kérdés, hogy ezek tényleg ennyit számítanak-e. Ezzel kapcsolatban megpróbáltunk informálódni a fejlesztőknél, és a válaszok alapján arra jutottunk, hogy egyik felvetett gondot sem lehet úgy kiemelni, hogy egyértelműen jelentős CPU-limitet okozna a GeForce-okon gyengébb teljesítményű processzorok mellett. Ellenben a különböző tényezők (Radeonokon való alkalmazásfejlesztés, bizonyos szintű emuláció alkalmazása a DirectX 12 bekötési modelljére, a DirectX 12 meghajtóimplementáció komplexitása, valamint ennek az optimalizálásába fektetett idő relatív módon értékelt rövidsége) hatása esetlegesen összeadódhat, és ezek már okozhatnak olyan limitációt, ami erősebben visszafoghatja a GeForce-ok tempóját bizonyos CPU-kon. Sőt, egyes gondok felerősíthetik egymást. Például a meghajtóimplementáció komplexitása kellemetlen bugokat szülhet a driverben, ami jelentősen megnehezítheti a GeForce-okra való alkalmazásoptimalizálást. Ha ezeket az NVIDIA javítja is, és nyilván javítani fogják, akkor sem biztos, hogy egy programfejlesztő újra leprofilozza a játékot a zöldek hardvereire. Egyszerűen anyagilag nem feltétlenül éri meg.
A végére hagytunk még egy érdekes felvetést, amivel nem foglalkozik a média, de több fejlesztő erre is felhívta a figyelmünket. Mivel a GeForce hardverek működését eléggé titkolja az NVIDIA, így nem lehet biztosan megmondani, hogy tapasztalt működés rendellenes-e. Csak annyiból indul ki a Hardware Unboxed, hogy a Radeonok bizonyos CPU-k mellett jobban teljesítenek a DirectX 12-es címekben, de ez nem jelenti automatikusan azt, hogy valami gond lenne a GeForce driverekkel. Sőt, jó eséllyel a zöldek is kihoztak már a saját implementációjukból igen sok teljesítményt, csak az eltérő szoftveres és hardveres háttér miatt máshol vannak a határok.
