A Microsoft a következő nagy dobásnak a shader modell 6-ot szánja, amely alapjaiban újítja meg a shader nyelvet, illetve a hozzá tartozó reprezentációs szintet, ezen belül is a DXBC-t felváltja a DXIL. A változás rá is fér a DirectX 12-re, ugyanis az aktuális shader modell alapjai rendkívül túlkorosak, egyáltalán nem illeszkednek a mai hardverek igényeihez, ami esetenként jelentősen rontja a feldolgozás hatékonyságát. A shader modell 6 célja ezáltal ismert, az alapvető reform mellett a fő extra a wave operation intrinsics bevezetése, ami a mai SIMT párhuzamosítási formát használó GPU-khoz igazodik.
Van azonban egy tényező, amin még szeretne javítani a Microsoft a shader modell 6 év végi tényleges bevezetésével. Az elmúlt időszakban láthatóvá vált, hogy növekszik az igény a gyártók shader kiterjesztéseire. Az aktuális nyelvet AMD az AGS, míg az NVIDIA az NVAPI szervizkönyvtáron keresztül egészíti ki. Ez ugyan működik, de alapvetően nem ideális irány, ugyanis a programnak tartalmaznia kell szabványos és speciális shadereket is a kiegészített funkciók számára. A probléma ott üti fel a fejét, hogy a speciális shaderek esetében a fordítás kívül esik a Microsoft hatáskörén, vagyis a fejlesztőknek folyamatosan reagálniuk kell a meghajtókban előállt esetleges változásokra. Emiatt is van az, hogy sokszor a szervizkönyvtárak bizonyos verzióit inkább érintetlenül hagyják, hogy a kompatibilitást megőrizzék a már kiadott programokkal. A fejlesztők számára tehát nem egyszerű ezeket a kiegészítéseket használni, de az utóbbi időben ráfanyalodtak, ami részben a Microsoft hibája is, mivel rendkívül lassan fejlődött a shader modell.
A redmondi óriáscég az érkező főbb újítások mellett gondolt a fejlesztői igényekre is, így a shader modell 6-ot már egyszerűen kiterjeszthetőre tervezték, amiben a nyílt forráskódú fordító nagyon sokat segít. Ezáltal a fejlesztőknek nem feltétlenül szükséges a szervizkönyvtárak használata, hiszen maga a shader nyelv is kiegészíthető, méghozzá anélkül, hogy speciális fordítóinfrastruktúrát kellene a nem szabványos kódokra kidolgozni. Persze a gyártókkal így is együtt kell működni, hiszen a változásokat a meghajtó oldalán támogatni kell, de végeredményben ez akkor is kedvezőbb alapot ad, mint a szervizkönyvtáras megoldás.
A cél ezzel főleg az, hogy maga a shader nyelv gyorsabb fejlődjön, ugyanis a beépített újításokat meg kell osztani a Microsofttal, ezáltal ezek hamarabb lehetnének a HLSL nyelv részei, így felgyorsulna a szabványosítási procedúra is. Ez azért is lényeges tényező, mert az érintett cégek egy része elkezdte rendkívül nyíltan kezelni a grafikus architektúrák dokumentálását, így rengeteg olyan fejlesztői ötlet merül fel manapság, amelyekre korábban se a Microsoft, se a gyártók nem gondoltak. A fenti lépéssel tehát az új irányok kutatását részben megkapja a fejlesztői közösség.
A változásokkal módosul némileg a nyelv szerkezete is. Az alapvetően igényelt funkciók mellett megjelennek a potenciálisan hardverfüggő képességek. Ezek ugyanúgy a nyelv részei, de az adott képesség futtatása előtt ellenőrizni kell, hogy a hardver egyáltalán meg tudja-e oldani a feladatot. Amennyiben nem, akkor az adott shadert az API nem engedi lefuttatni. Az ellenőrzési procedúra egyébként eléggé egyszerű lesz, a program indításának elején a meghajtó ad egy felvilágosítást arról, hogy mit tud az adott fordítóimplementáció, és eszerint működhet majd a rendszer. Itt meg kell jegyezni, hogy a Microsoft egy úgynevezett kísérleti módot is beépített az API-ba, főleg azért, hogy a prototípus kódokat ilyen formában ellenőrizni lehessen. Ezáltal a meghajtó normál és kísérleti mód mellett más választ adhat az egyes képességek elérhetőségére. Nyilván normál módban a már beépített, de még nem stabil vagy nem végleges funkciókat nem jelzi elérhetőnek, míg kísérleti módban igen, így ezeket lehet tesztelni.
Az új fejlesztési modellben a HLSL is sűrűbben fog változni, amivel a Microsoft el akarja kerülni, hogy évekig csak egy helyben toporogjon a piac ebből a szempontból. Éppen ezért a HLSL nyelvre vonatkozó projekteket a jövőben évszámokkal fogják jelölni a korábbi verziószámok helyett. A terv az, hogy minden esztendőben érkezzen frissítés, de persze az nincs meghatározva, hogy a változások mekkorák lesznek. Erősen valószínű, hogy a menedzselési procedúra hasonló lesz ahhoz, amit a Khronos Group is csinál, vagyis a szükséges fejlesztések mellett az értékesnek tűnő gyártói kiegészítések lesznek időről-időre átemelve vagy átdolgozva szabványos formába.
