Október második felében biztos megérkezik a Windows 10 őszi frissítése, ami Fall Creators Update néven fut, és sok újítás mellett végre bevezeti a shader modell 6.0-t. Ez már benne volt a Creators frissítésben is, de csak az úgynevezett fejlesztői módban volt elérhető, viszont ősztől véglegessé válik.
A végleges verzió némileg különbözik majd a tesztelésre biztosított konstrukciótól, ugyanis az elmúlt hónapokban voltak panaszok, hogy több meglévő kód nem jól fordul le, és emiatt a Microsoft módosításokat volt kénytelen alkalmazni, de végeredményben egész kedvező döntések születtek, ami jelzi, hogy nem volt hiábavaló a fél éves publikus tesztelési időszak.
Mint ismeretes, a shader modell 6.0 az első jelentős váltás azóta, hogy a Microsoft bevezette a HLSL-t. Korábban az fxc nevű fordítóval születtek meg a D3D bájtkódok (D3BC), amelyeket a programban szállíthattak a fejlesztők. A D3BC azonban mára nagyon elavult, egyáltalán nem veszi figyelembe a modern hardverek működését, vagyis a gyártók számára nehéz olyan fordítót írni, ami hatékony bináris kódot generál az aktuális reprezentációs formátumból. Emiatt a Microsoft bevezeti a DXIL-t, amely egy modern alternatívája a D3BC-nek, tipikusan igazodva a mai igényekhez. Az új shader fordító ráadásul a Clang/LLVM keretrendszerre épül és még nyílt forráskódú is.
A változást a Microsoft viszonylag fájdalommentesen oldja meg végül. A DXIL 1.0 ugyanis legacy módban elfogadja a shader modell 4.0, 4.1, 5.0 és 5.1 specifikációknak megfelelő kódokat, illetve natív módban lefordítja a 6.0-t. Ez azért kellemes döntés, mert így a meglévő kódokat is hordozni lehet, és bár legacy módban a funkcionális újítások elérhetetlenek, de a kód lefordítható és működni fog. Ezzel a vállalat arra akarja sarkalni a programfejlesztőket, hogy az D3BC-t felejtsék is el, elég DXIL kódokat szállítani, amelyek kezelhetők a meglévő modernebb hardvereken, a Fall Creators Update telepítése után. Ráadásul ez igazából meg is éri, ugyanis az újabb hardverekhez sokkal jobban illeszkedő reprezentációs formátumból egyszerűen gyorsabb bináris kódot képesek fordítani a gyártók, méghozzá anélkül, hogy az eredeti shadert módosítania kellene a fejlesztőknek. Persze különféle optimalizálásra mindig van lehetőség, ezzel a végeredmény még gyorsabb lehet.
A natív mód tartalmazza az igazi újításokat, ugyanis ilyenkor elérhetővé válnak a shader modell 6.0 funkcionális extrái. Az egyik ilyen a 64 bites integer adattípusok támogatása (int64 és uint64), míg a másik az úgynevezett wave intrinsics. Utóbbi tekinthető igazából a nagy újításnak. A HLSL ugyan eddig is tartalmazott különböző intrinsics, azaz beépített függvényeket, de maga a feldolgozási modell alapvetően egy szálú volt a GPU-n belül, vagyis egyértelmű korlátozásokat kellett megszabni ahhoz, hogy a szálak a hardverben párhuzamosan dolgozhassanak. Ez a modell leginkább a tipikus SIMD hardvereknek kedvezett. Az egész jó okkal alakult így, ugyanis amikor a HLSL-t bevezették még ilyen hardverek voltak a piacon. Ugyanakkor látni kell, hogy az iparág egyre inkább a SIMT konstrukciók felé tereli a fejlesztéseket. Ilyen rendszert alkalmaz az AMD (GCN) és az NVIDIA (Fermi, Kepler, Maxwell, Pascal), illetve az Intel fejlesztése (Gen7.5-től kezdve) is képes hasonló formában dolgozni.
Az új HLSL nyelv már olyan operációkat is megenged, amelyek definiálják a wave terminológiát, ami ismert lehet például az AMD wavefront, vagy az NVIDIA warp által. Ez lehetőséget ad a modern GPU-kba tervezett szálszintű párhuzamosság rendkívül hatékony kihasználására, így egy bizonyos számú szál – a shader modell 6.0 terminológiájával élve lane – explicit korlátozások nélkül futhat, ellentétben a korábbi lehetőségekkel, ahol ezt gyakorlatilag képtelenség volt normálisan elérni. Ahhoz hogy ez hatékonyan működjön, a hardvernek vissza kell jeleznie a programindítás elején, hogy minimum és maximum mennyi lane lehet egy wave-ben, illetve mennyi az adott feldolgozótömb által kezelt konkurens lane-ek maximális száma.
A Microsoft első körben 14 wave intrinsics operációt épített be, amelyeket kötelező támogatni. Az eredeti tervekhez képest ez csökkentést jelent, mivel az úgynevezett global ordered append függvénycsoport teljesen kikerült. Ennek az oka az lehet, hogy az Intel és az NVIDIA nem igazán tudott felmutatni használható sebességet a tesztidőszak alatt, de sokkal valószínűbb, hogy azért lettek elmeszelve a wave-ek feldolgozási sorrendjét meghatározó függvények, mert az említett két cég érkező architektúrái sem remekeltek volna benne. Ugyanakkor a shader kiterjesztések létrehozása mostantól sokkal egyszerűbb lesz, így az AMD beépítheti magának a kimaradt függvényeket. Végeredményben rosszul nem jár az ipar, mivel a kötelezően támogatandó wave intrinsics operációk tekintetében legalább nagy lesz az egység a gyártók között, az opcionális funkciók, illetve esetlegesen a kiterjesztések tekintetében pedig kellően szabadok az implementációs lehetőségek.
A támogatás tekintetében a DXIL-ről való fordítás minimum WDDM 2.1-hez írt meghajtókat igényel. A hardveres támogatás szintjén még kevés teljes információ van. Annyi biztos, hogy az AMD GCN2, GCN3, GCN4 és GCN5 biztosan támogatja az összes kötelező és opcionális funkciót. Ez igazából nem meglepő, a shader modell 6.0-t a Microsoft bevallottan az Xbox One-ra szabta. A többi gyártó szempontjából garancia még csak a kötelező újításokra van, amelyeket az NVIDIA oldalán a második generációs Maxwell és Pascal, míg az Intel tekintetében a Gen9 és Gen9.5 architektúrák kezelnek. A végleges támogatás ugyanakkor kibővülhet a megjelenésre, tehát a fentiek csak egy aktuális állapotot tükröznek. Valószínűleg a Pascal és a Gen9/9.5 megfelel az opcionális újítások döntő többségének. Talán még az MSAD lehet némileg problémás, ugyanis erre az AMD dedikált utasítást használ, de a Microsoft mindenhol megengedi az emulációt, tehát az Intel és az NVIDIA is tud írni egy megfelelő bináris kódot a meghajtóba, ami megoldja az említett funkciót.
Az első körben egyébként tipikusan jellemző lesz, hogy a programok az opcionális funkciókhoz nem nyúlnak hozzá, tehát egy viszonylag nagy felhasználóbázis célozható azonnal a támogatott architektúrák alapján.
A Microsoft a jövőben a DXIL-t a visszafelé kompatibilitás megőrzésével fejleszti. Már létezik az 1.1-es és az 1.2-es specifikáció, amelyek a shader modell 6.1 és 6.2 támogatására vonatkoznak. Ezek még nincsenek kész, de a shader modell 6.1 nagyon közel áll a véglegesítéshez, így tavasszal akár bevethető is lesz. Ezzel elérhetővé válik az SV_ViewID, aminek hála egyetlen rajzolási paranccsal a teljes geometria átküldhető több nézőpontra, és ez kifejezetten hasznos a virtuális valóság szempontjából, hiszen így a sztereó 3D-s megjelenítés nem igényli majd két képkocka teljes kiszámítását. További lényeges újítás lesz még az SV_Barycentrics bevezetése, ami tulajdonképpen lehetővé teszi a fejlesztőknek, hogy valamilyen formában kiolvassák a baricentrikus koordinátákat, amelyeket aztán bármire fel lehet használni. A shader modell 6.2 készültségi szintje még nem nevezhető túl kedvezőnek, de ennek a fő újítása az lesz, hogy a lebegőpontos operációk viselkedése már a függvények szintjén is meghatározható lesz.
