Az NVIDIA Turing architektúrájáról másfél hete készítettünk egy bővebb elemzést, amelyben részleteztük, hogy a hardver alapjai hogyan is néznek ki, de arra is választ kerestünk, hogy a DirectX 12 implementációja szempontjából mi változott a Pascal és a Volta architektúrához képest. Ugye utóbbi nem sokat újított, leszámítva persze a konzervatív raszterizáció legmagasabb szintjét, de ez kézenfekvő volt akkoriban, mivel a három támogatható szint közül csak ez ér valamit, hiszen csak itt érhető el a belső bemeneti lefedettség a HLSL nyelvben. Ez sokat segít a konzervatív raszterizáció reális használatán, és természetesen a képességet megörökölte a Turing is, de ennél fontosabb változás is beállt.
A zöldek mérnökei végre átdolgozták az architektúra erőforrás-kezelését. Ez a nyersen kiolvasott információkon nem látszik, ezért sem szentelt neki az NVIDIA túl sok figyelmet a marketing szempontjából. Érdeklődtünk viszont a változásokról, így megtudtuk, hogy ezek az adatok nyersen nem feltétlenül jelentik ugyanazt, mivel a Microsoft specifikációja szerint sokféle implementációt lehet biztosítani a DirectX 12 bekötési modelljére, amelyek látszatra ugyanolyannak tűnnek majd, de a motorháztető alatt már nagy lesz a különbség.
Mint ismeretes a Microsoft külön az NVIDIA számára tervezett egy speciális bekötési szintet a DirectX 12-be, ugyanis a korábbi GeForce-ok úgynevezett slot-alapú rendszerek voltak bizonyos erőforrásokra vonatkozóan, így például shader lépcsőnként maximum 8 vagy 64 UAV-nek, illetve 14 CBV-nek volt bennük szabad regiszter. Ezt még akkor szabták meg, amikor úgy volt, hogy a leírótáblák száma korlátozva lesz, de a végleges specifikáció kialakításánál a Microsoft úgy döntött, hogy a leíróhalmaz méretévvel egyezhet meg a leírótáblák száma is. Ennek azért volt jelentősége, mert így gyakorlatilag emulálhatóvá vált a legmagasabb bekötési szint, ugyanis az adott gyártó írhatott egy olyan kódot a meghajtóimplementációba, amely hasonló a Microsoft CPU-oldali binding API-jához, csak a hardver képességeihez igazodva a nem bindless módban kezelt erőforrásokra korlátozódik. Az NVIDIA esetében ez az UAV-ket és a CBV-ket jelentette, és terveztek is egy olyan meghajtót, ami már emulált bekötéssel kezeli ezeket, vagyis a hardverek nyers korlátjai megkerülhetővé váltak.
Ennek a módszernek viszont van némi hátránya, ami leginkább abban nyilvánul meg, hogy a processzor terhelése megnő, vagyis egy GeForce hamarabb futhat processzorlimitbe egy DirectX 12-es alkalmazás futtatásakor, illetve az NVIDIA esetében voltak olyan tényezők, amelyek miatt a vállalat kifejezetten ellenjavallta a Microsoft optimalizálási javaslatait, mivel azok nem feküdtek az architektúráiknak. Itt elsősorban arra kell gondolni, hogy a zöldek kritikus tényezőnek tartották azt, hogy a konstansokat és a CBV-ket, illetve ha lehetséges, akkor az UAV-ket és az SRV-ket is direkten root signature-be helyezzék el a fejlesztők. Ettől a GeForce-ok 10-30%-ot is gyorsulhattak, programfüggő keretek között, de a Microsoft például ezt a módszert csak a konstansokra ajánlotta, minden más erőforrás esetében egy leírótáblán keresztüli elérhetőséget tartottak optimálisnak. Utóbbi elsősorban azért lett így kialakítva, mert a legtöbb formátum esetében az UAV-ket és SRV-ket el sem lehet helyezni közvetlenül a root signature-ben, tehát ez egy olyan optimalizálási javaslat, ami lehet, hogy sokat segít a GeForce-ok pixel shader teljesítményén, de komolyan kell arra figyelni a szoftveres fejlesztések oldalon, hogy egyáltalán megvalósítható legyen. Technikai szinten viszont, ha a DirectX 12 bizonyos specifikációi nem tiltották, akkor maga az API lekezelte az NVIDIA javaslatait is, ráadásul ettől az Intel és az AMD hardvereinek sem változott a teljesítménye, tehát volt olyan fejlesztőstúdió, amely nem a Microsoft optimalizálási javaslatait vette irányadónak.
A fenti okokra vezethető vissza az, hogy bizonyos DirectX 12-es játékok egészen jól működnek a GeForce-okon, míg bizonyos címek nem igazán. A Turing ezt a problémát végérvényesen megoldja az erőforrás-kezelés átalakításával. Az NVIDIA szerint mostantól az UAV-k és a CBV-k szempontjából is bindless a hardver, méghozzá 1 048 576-os limittel. Utóbbi szám nem annyira fontos, csak informális jellegű (a Microsoft minimum egymilliót ír elő). A lényeg az, hogy mostantól a Turing úgy képes támogatni a DirectX 12 bekötési modelljének legmagasabb, TIER_3-as szintjét, hogy ahhoz nem kell meghajtóoldali emulációt alkalmazni bizonyos erőforrásokra. Emellett a hardver sokkal jobban igazodik a Microsoft ajánlásaihoz is, tehát alapvetően nem veszíti el a pixel shader teljesítményének egy jó részét, ha az egyes UAV-k és SRV-k nem közvetlenül a root signature-ben vannak elhelyezve. A nagy kérdés itt az, hogy az NVIDIA mostantól mit ajánl a fejlesztőknek, ugyanis komolyan tudnak ártani a Volta, Pascal, Maxwell és Kepler architektúráknak, ha innentől kezdve kiállnak a Microsoft javaslatai mellett. Mindeközben a Turingnak valószínűleg ugyanúgy nem fájnak majd az NVIDIA saját javaslatai, ahogy a konkurens Intel és AMD architektúráknak sem. Ha úgy vesszük, akkor logikus lenne továbbra is figyelembe venni a felhasználók gépeiben lévő GeForce-okat, elvégre tényleg alig jelent problémát a modern erőforrás-kezelési koncepciók szerint tervezett architektúráknak az, hogy miképpen kapcsolódnak a root signature-höz az UAV-k vagy a CBV-k, ellenben a régebbi GeForce-oknak ez egyáltalán nem mindegy.
További változás a Turing architektúrában az erőforráshalmaz szintje is, ami a korábbi GeForce-ok TIER_1-es opciója helyett már TIER_2-es szintű. Ennek köszönhetően a hardver már nem csak olyan halmazokat hozhat létre, ahol a flagek csak egy kategóriába sorolt típust engednek használni. Ez azt jelenti, hogy innentől kezdve többféle különböző erőforrástípus lehet ugyanazon a halmazon belül, ami jelentősen leegyszerűsíti az alkalmazás oldalán a memóriamenedzsmentet. Ez is egy olyan változás, ami sok kérdést eredményez, mivel innentől kezdve mindhárom nagy, PC-s GPU-kat fejlesztő cég rendelkezik az erőforráshalmaz legmagasabb szintjét kezelő hardverekkel, vagyis a fejlesztők számára igen reális eshetőség lehet erre optimalizálni a program memóriamenedzsmentjét, már csak azért is, mert sokkal egyszerűbb. Ez ugye nem azt jelenti, hogy innentől kezdve a régebbi GeForce-ok működésképtelenné válnak, mivel a DirectX 12 API úgy van felépítve, hogy a futtathatóság akármilyen szabványos kód mellett biztosított legyen a megfelelő hardvereken, de megint nem mindegy, hogy milyen hatékonyság mellett. Ennek megfelelően leginkább az NVIDIA jóindulatán múlik, hogy a Volta, a Pascal, illetve az idősebb GeForce architektúrákra mi vár.
A Turing egyébként már csak a pixel shaderből specifikált stencil referenciaértéket nem támogatja, amiben még az Intel és az AMD egyes architektúrái előrébb járnak, de ez egy kevésbé fontos funkció a DirectX 12-n belül. Persze ez nézőpont kérdése, ha egy fejlesztő szeretne pixelekre vagy mintákra lebontott kontrollt a stenciloperációk felett, akkor pont lényeges lesz ez a képesség.
