Október közepén írtunk arról, hogy még az idén hozza a DirectStorage API-t a Microsoft, annak is az 1.1-es verzióját, amely támogatja a GPU-s kitömörítést biztosító GDeflate formátumot. A redmondi óriáscég most élt a bejelentéssel, és ennek keretében az AMD, az Intel és az NVIDIA is jelezte, hogy teljes mértékben támogatják a DirectStorage 1.1-et. Ehhez ráadásul új meghajtót sem adtak ki, mert igazából speciális követelménye nincs az új API-nak, a korábbi shader modell 6.0-t támogató eszközillesztők megfelelnek, noha ajánlott a legújabb publikus kiadást használni, mert azzal már tesztelték a működést.
A korábban ismertetett, előző bekezdés elején linkelt hírben összefoglalt működés nem változott, de pár extra adat van a lehetőségekkel kapcsolatban. Többek között a shader modell 6.0-n keresztül működő, GPU-s kitömörítés a gyártói oldalról kiegészíthető úgynevezett metaparancsokkal. Ezeket nem kell külön a programkódon belül támogatni, az adott eszközillesztő tudja, hogy mikor és hogyan kell bevetni őket, viszont az feldolgozást gyorsító metaparancsok még egy gyártón belül is lehetnek architektúraspecifikusak. Ezzel a Microsoft külön nem foglalkozik sokat, mert a fejlesztői oldalon láthatatlanok, de az AMD megjegyezte a saját weboldalán, hogy már rendelkeznek metaparancsokat biztosító meghajtóval, amit igényelhetnek a partnereik. Az NVIDIA és az Intel külön ezt nem emelte ki, de megtudtuk, hogy ezeket a lehetőségeket ők is kihasználják, tehát az AMD-hez hasonlóan tudnak biztosítani megfelelő csomagokat.
A működés tekintetében a Microsoft felkínálja a CPU-s kitömörítés kényszerítését is, és ezzel kapcsolatban nagyon ajánlják a fejlesztőknek, hogy tegyék az adott program beállítások menüjében opcionálisan bekapcsolhatóvá, mivel függ a konfigurációtól, hogy a CPU-s vagy a GPU-s kitömörítés lesz-e a gyorsabb. Ilyen formában a felhasználónak lehetősége lenne az adott gépen jobb teljesítményt biztosító működést választania. Szintén lehetőség van egyedi kitömörítést kérni, aminek elsődlegesen az lehet a haszna, hogy egy-egy GDeflate munkafolyamatot kötelezően a CPU-n lehet általa végrehajtani. Ez azért fontos, mert nem minden adat kerül a VRAM-ba, némelyik a rendszermemóriában lesz tárolva, és azt jobb, ha a processzor kódolja ki.
Pár dolog megjegyzendő a gyártói oldalakkal kapcsolatban is. Az NVIDIA újra beszél az RTX IO-ról, amely kapcsán felmerülhet a kérdés, hogy miben különbözik az AMD és az Intel implementációjától. Nos, semmiben. Az RTX IO egyszerűen csak a GDeflate implementáció neve, de ettől még pont ugyanúgy működik, ahogy a többi, GPU-s kitömörítést biztosító eszközillesztő. Hasonló ez ahhoz, hogy a DLSS-t is valamiért az RTX-hez sorolja az NVIDIA, egyszerűen ez a három betűt marketingre használják, és mindenre ráaggatják amire csak tudják. Ilyen formában minden shader modell 6.0-t legalább támogató GeForce-hoz használható az RTX IO jelzés, mert ez végül nem különálló technológia lett, hanem csak a szoftveres háttér elnevezése, utóbbi pedig adott a teljes termékskálán.
Az AMD oldalán a korábban bejelentett SmartAccess Storage kapcsán is lehetnek kérdések. Ezzel kapcsolatban megtudtuk, hogy ez nem kifejezetten egy DirectStorage kiegészítés lesz, hanem egy teljesen külön rendszer, amely magát a DirectStorage-et teszi hatékonyabbá. Viszont ahhoz, hogy ez működjön nemcsak a DirectStorage-et kell külön támogatni a játékban, hanem extraként magát a SmartAccess Storage-et is. Információink szerint a működtetése a fejlesztők oldalán egyszerű lesz, viszont nem kifejezetten egy grafikus meghajtóhoz szabott konstrukcióról beszélünk, ugyanis specifikus NVMe szoftverkörnyezetet igényel, ami peer-to-peer DMA eléréssel próbálja optimalizálni az SSD és a GPU közötti adatmozgást, ezzel megkerülve a rendszermemória használatát. Ennek az a nehézsége, hogy az adott NVMe eszközt a CPU és a GPU is közvetlenül érné el, vagyis megvan az esélye, hogy egymás munkafolyamatait megszakítják, és ennek elkerülése érdekében szükség van egy olyan szoftveres háttérre, amely képes ezt a problémát direkten kezelni, de ehhez rendszerszintű módosítások szükségesek.
Végül az egyik legfontosabb optimalizálási paraméter DirectStorage esetében az úgynevezett staging puffer mérete lesz. Erre vonatkozóan a Microsoft 128 MB körüli értéket javasol kiindulásnak, és a lényeg, hogy az IO stack teljes telítettsége könnyen elérhető legyen. Az Intel, illetve az NVIDIA is hasonló szintre gondol, előbbi cég konkrétan 128 MB-ra, míg utóbbi kifejti, hogy a kisebb GPU-ik kevesebb, míg a nagyobbak méretesebb puffert igényelhetnek. Az AMD külön javaslatot nem tett, ami azt szokta jelenteni, hogy a Radeonok számára a Microsoft ajánlásai optimálisak.
