A Microsoft még idén tavasszal leplezte le a Shader Model 6.0-t, amelyről természetesen be is számoltunk. Az új konstrukció végre háttérbe helyezi az elavultnak tekinthető D3D bájtkódot, és a helyére egy modern reprezentációs formátum kerül DXIL néven. Az átalakításoknak hála a fejlesztők a programfordítás viszonylag nagy részét láthatják, illetve korlátozott mértékben kontrollálhatják, így több lehetőségük adódik a teljesítmény optimalizálására.
A változások azonban új lehetőségeket is hoznak, és ezek között lesz a wave operation intrinsics, amely a Shader Model 6.0 egyik nagy újítása. A HLSL eddig is tartalmazott különböző intrinsics, azaz beépített függvényeket, de maga a feldolgozási modell alapvetően egyszá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, 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) is képes ilyen formában dolgozni, noha egyértelműen nem ez fekszik neki. És akkor még nem beszéltünk az ultramobil piacról, ahol ez az átállás szintén zajlik, bár viszonylag lassan.
A váltás szükségességét az adja, hogy SIMT-re optimalizálni nagyságrendekkel egyszerűbb, mint klasszikus SIMD-re. Bár maga a HLSL igen magas szintű nyelv ahhoz, hogy ez problémát ne okozzon a fejlesztőknek, a rendszerprogramozók számára már egyáltalán nem ilyen egyszerű a helyzet, így a gyártók máig küzdenek azzal, hogy a D3D bájtkód elavultságát a hardver felé való fordítási rétegeknél leküzdjék.
A fenti változásokkal a HLSL már olyan operációkat is megenged, amelyek definiálják a wave terminológiát, ami ismert lehet az AMD wavefront és 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 DirectX terminológiájával élve lane – explicit korlátozások nélkül futhat. 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.
Az új lehetőségeket kihasználva jönnek a beépített wave operációk, amelyek között ott van a konzolokon jellemzően használt Ballot (WaveBallot), ReadFirstLane (WaveReadFirstLane), ReadLane (WaveReadLaneAt), LaneId (WaveGetLaneIndex) és OrderedCount (GlobalOrderedCountIncrement).
Az új lehetőségek exkluzívan a Shader Model 6.0 részei lesznek, vagyis elsődlegesen olyan hardver kell hozzájuk, amely ezt az új shader modellt támogatja. A Microsoft korábban elmondta, hogy minimum D3D_FEATURE_LEVEL_12_0 hitelesítést kér ahhoz, hogy egyáltalán a Shader Model 6.0-ra is vizsgálja az adott implementációt. Ennek megfelelően az AMD GCN2, GCN3 és GCN4, az NVIDIA második generációs Maxwell és Pascal, valamint az Intel Gen9 architektúra minimum szükséges az adott hardveren. Támogatást azonban ez még nem garantál, ugyanis a Shader Model 6.0-n belül a wave operation intrinsics egy külön opció, vagyis az adott gyártó szabadon eldöntheti, hogy támogatja-e vagy sem. Ez ugyanakkor az említett architektúráknak elvileg nem lehet probléma. Ráadásul a Microsoft még a wave operation intrinsics függvényekre vonatkozó támogatás szempontjából is megkülönböztet egy alapvető szintet, illetve egy kiterjesztettet, amely kiegészített compute erőforrás-állapotot vezet be. Utóbbinak a jelenlegi specifikációk szerint már csak az AMD GCN2, GCN3 és GCN4 felel meg, illetve az Xbox One konzol.
A Microsoft hozzáállása egyébként érdekes, ugyanis wave operation intrinsics függvényeket legalább alapvető szinten például képes lenne támogatni az első generációs GCN az AMD-től, illetve biztosan megfelelne az első generációs Maxwell, valamint a Kepler is az NVIDIA-tól. De ezekhez a hardverekhez nem lehet támogatást írni, mert a Shader Model 6.0 kezelését, a D3D_FEATURE_LEVEL hitelesítésre vonatkozó korlátjai miatt a Microsoft nem is veszi számításba. A fő cél egyébként itt nem pont az, hogy a felhasználó rosszul járjon, még akkor sem, ha ez látszatra annak tűnik. A redmondi óriáscég pusztán csökkenteni akarja a célarchitektúrák számát, ugyanis ez segít a fejlesztőknek abban, hogy kevesebb hardverre kelljen optimalizálni a kódjaikat. Mondhatni a Microsoft felvállalja a rosszfiú szerepét, annak érdekében, hogy a piac hosszabb távon egyszerűsödjön.
