A Microsoft bejelentette, hogy elkészült a shader modell 6.9, amely első ránézésre nem hoz forradalmi változásokat, inkább előkészíti a terepet a neurális leképezéshez tervezett shader modell 6.10-nek. Ebből már sejthető, hogy az előző évben leleplezett kooperatív vektor nem került bele végleges formában az aktuális specifikációba, sőt, ezt majd egy másik megoldás fogja váltani, ami csak a következő körben érkezik, de jobb alapokra építkezhet majd a most kötelezővé tett képességek által.
A shader modell 6.9 legnagyobb újítása ugyanis az, hogy mostantól alapvetően megköveteli a shader modell 6.0-val befutó wave operation intrinsics funkciókat. Ezen túlmenően érkezik még az úgynevezett Long Vector képesség, amelynek hála a HLSL-ben már nem csak 4, hanem akár 1024 elemű vektorokkal is lehet dolgozni. Utóbbi a gépi tanulás terjedésével számít hasznos képességnek, és később érkező, még be nem jelentett technika kifejezetten sokat profitálhat belőle.
Hirdetés
A Microsoft a DirectX Raytracing 1.2-t is véglegesítette, amely két újítást kínál majd. Az egyik az opacity micromaps (OMM), amivel gyorsítható az átlátszóságra vonatkozó információt hordozó felületeken a sugárkövetés, míg a másik a shader execution reordering (SER), amely képes a futó shadereket úgy rendezni, hogy az javítsa a koherenciát.
Az OMM-et a Microsoft úgy alakította ki, hogy ne legyen szükség hardveres támogatásra hozzá, bár manapság is könnyen lehet olyan szoftveres optimalizálásokat írni, amelyek segítik a sugárkövetést a célzott munkamenetekben, és a legtöbb fejlesztő inkább ezt csinálja az OMM támogatása helyett. Mindemellett a SER is átgondolt specifikációt kapott, mivel a DXR 1.2-es API olyan működési módot is megenged, amely csak befogadja, de nem rendezi át a futó shadereket, és ez akkor hasznos, ha az adott GPU specifikus célhardvert implementált a probléma kezelésére. Ilyen formában az AMD úgy tudja támogatni a SER-t, hogy közben emiatt nem kell lemondaniuk az RDNA 4-be épített hardverük képességeiről.
A fentieken túl a DirectX 12 kiegészült pár olyan képességgel, amelyeket a Microsoft ügyfelei igényeltek, amelyek gyakorlatilag szoftveres funkciók, tehát elvben bármelyik modern hardver képes a támogatásukra. Az újítások közül a legfontosabb a Resource View Creation API-k átalakítása, így az úgynevezett Revised opció bájtalapúvá teszi a rendszert, ami jobban illeszkedhet a modern grafikus motorok igényeihez.
A másik extra a CPU Timeline Query Resolves, ami a profilozást fogja segíteni, méghozzá olyan módon, hogy anélkül ki lehet majd olvasni a GPU-ból azt, hogy mennyi ideig futott egy adott shader, hogy ezzel terhelnénk magát a GPU-t. Ezzel tehát pontosabbá válnak az alkalmazásoptimalizáláshoz szükséges adatgyűjtési lehetőségek.
Érdekes képesség még a Periodic Trim Notification, ami lényegében kernel szintű figyelmeztetést biztosíthat az alkalmazás számára arról, hogy lassal elfogy a GPU memóriája, így ideje a régebb óta nem használt adatokat törölni. Ráadásul ez a funkció még meghajtótámogatást sem igényel, bár azt a gyártók egyénileg eldönthetik, hogy élnek-e vele. Utóbbit specifikus tényezők határozhatják meg, mert hasonló jellegű technikákkal már kísérleteztek az érintettek, és nem kizárt, hogy jobban bíznak a házon belüli eljárásban, vagy esetleg jobban működik a Microsoft általános megoldásánál. A Periodic Trim Notification célja viszont elsődlegesen az, hogy a futtatási környezet szintjére emelje a probléma kezelését, egyszerűbbé téve a programfejlesztők dolgát.
Végül az 1D Dispatch Limit kiterjesztése egy sokak által igényelt funkció, ugyanis a compute shader indításkor használt hívások paraméterei meghatározzák, hogy hány munkacsoport indítható a GPU-n egyetlen dispatch paranccsal. Ez a limit jelenleg compute és mesh shaderek esetében is 65535, ami nem rossz, de lehetne több. Az Intel és az NVIDIA jelezte, hogy a jövőben emelni fogják a szóban forgó számot, de nem határozták meg, hogy pontosan mennyire, az AMD pedig a compute limitet 4 294 967 295-re állította át.
A Microsoft pár tervezett funkció előzetes támogatását is bejelentette az Agility SDK 1.719-es preview kiadásában, így tesztelhető a Fence Barriers és a VPblit 3DLUT képesség. Előbbi a DirectX 12 szinkronizációs lehetőségeit bővíti, míg utóbbi lehetővé teszi, hogy a multimédiás hardver végezze a 3DLUT-alapú tone mappinget.
Ezeknél is fontosabb előzetes funkció a DirectX 12 kiterjesztésrendszerének tesztelése. Ez egy olyan mechanizmust biztosít a gyártók számára, amivel az érintett cégek megfelelően strukturált gyártóspecifikus funkciókat tudnak hozzáadni az API-hoz. Ez hasonló a Vulkan API kiterjesztésmodelljéhez.
