A Microsoft már jóval korábban bejelentette a shader modell 6.0-t, amely a Windows 10 Creators frissítésében meg is érkezett. Ezzel párhuzamosan befutott az alapul szolgáló DXIL 1.0-s verziója is, amelyről szintén beszámoltunk korábban.
Az látszik, hogy a Microsoft elképesztően rákapcsolt, és tulajdonképpen komolyan ténykednek azon, hogy a PC a DirectX 12 alól modern reprezentációs formátumot kapjon, és emellett az új Xbox és PlayStation konzolokban sűrűn használt függvények is elérhetők legyenek. A shader modell 6.1 tulajdonképpen egy kiegészítés lesz, amely kapcsán egyrészt frissül a DXIL, méghozzá az 1.1-es verzióra, másrészt jönnek a barycentric függvények.
A barycentric egyébként nem mondható elérhetetlennek PC-n, mivel a GPUOpen GCN shader intrinsics csomagjával az AGS 4.0-n keresztül elérhető DirectX 11-re és 12-re, illetve vannak SPIR-V kiterjesztések is, amelyek a Vulkan API-hoz biztosítják a támogatást. Ugyanakkor ezek a lehetőségek csak a GCN architektúrára épülő Radeonokra használhatók, tehát szabványos formában a barycentric máig nem férhető hozzá PC-n, pedig a konzolokon igencsak kedvelt megoldásnak számít.
A funkcióját tekintve a függvények tulajdonképpen arra szolgálnak, hogy a fejlesztők extra adatokat szerezzenek az interpolációs fázisból. Utóbbi jelen formában fix a hardvereken belül, vagyis egy program az interpolálásba nem tud beleszólni. A szabványon belül meg van határozva, hogy a hardvernek mit kell csinálnia, és ezt valamilyen formában elérik a gyártók. Itt vannak felfogásbeli különbségek a megvalósítások között, többek között az Intel és az NVIDIA a speciális ALU-kba épít áramköröket, amelyekkel elvégzik az interpolálást, kvázi fixfunkciós formában, míg az AMD úgynevezett manuális interpolációt használ már jó ideje, vagyis az általános ALU-kat használják erre a célra, mindenféle fixfunkciós rásegítés nélkül.
A barycentric tulajdonképpen lehetővé teszi a fejlesztőknek, hogy valamilyen formában kiolvassák a barycentric koordinátákat, amelyeket aztán bármire fel lehet használni. A konzolokon ezt a függvénycsoportot jellemzően speciális analitikai élsimításokra vetik be, így specifikusan lehet reagálni bizonyos mintavételezési problémákra. Valószínűleg PC-n is hasonlóra fogják majd használni, lévén a kutatás és fejlesztés a legtöbb stúdiónál egységesen zajlik, tehát a konzolos irányokat viszik PC-re is.
A Microsoft első körben lineáris interpoláció mellett teszi kiolvashatóvá a barycentric koordinátákat, tehát a perspektivikus interpolálás még nincs benne a shader modell 6.1-ben, ugyanakkor ez nem nagy hátrány, mert a legtöbb fejlesztő eleve a lineáris interpolációt igényli. Mindemellett, ha tényleg nagyon szükség lenne rá, akkor az AMD shader kiterjesztéseivel ez is elérhető PC-re, persze sajnos nem szabványos formában.
Az implementáció szempontjából a shader modell 6.1 tulajdonképpen támogatható minden gyártó számára. Az AMD-nek egyszerű a dolga, mert eleve manuális interpolációval dolgoznak, a hardver a szükséges adatokat a helyi adatmegosztásra fenntartott tárolók felére menti, ami 32 kB, így gyakorlatilag ezt kell kiolvashatóvá tenni és kész is. Nem véletlen, hogy a GPUOpen keretében már van erre a problémára saját megoldásuk. Az Intel és az NVIDIA esetében picit bonyolultabb a helyzet, mivel nem manuális interpolációra tervezték a hardvereiket, de elvi akadálya ennek a formának nincsen, ergo írni kell egy olyan meghajtót, amellyel a hardver az általános ALU-kon végzi el az interpolációt, és a helyi adatmegosztásra fenntartott tárolók egy részébe (blokkonként 32 kB-nak elégnek kell lennie) elmenti a szükséges adatokat. Ezeket aztán ki lehet majd olvasni.
Az Intel esetében ALU blokkonként bőven van ehhez a lapkán belül tárterület, mivel a unified return bufferjük 256 kB-os, amibe bármit menthetnek. Ez a praktikus implementációs forma, de az IGP L3 gyorsítótárából lecsippentett helyi adatmegosztások mérete is megnövelhető 32-32 kB-tal, ami megint elég a manuális interpoláció megvalósításához. Valószínűleg az Intel már tudja, hogy melyik megoldást választják, kívülről viszont ezt nehéz eldönteni.
Az NVIDIA is meg tudja oldani a problémát, de a második generációs Maxwell és a Pascal architektúra nagyon spórol a helyi adatmegosztással, így a többi architektúrával ellentétben nem rendelnek minden multiprocesszorhoz egy 32 kB-os szeletet. A szabvány ezt igazából megengedi, amíg logikailag szinten a program megkapja a szükséges minimális tárterületet, és ilyen formában az is egy megoldás, hogy bizonyos hardverállapotok mellett nem aktív az összes multiprocesszor a lapkán belül. A fizikai implementáció oldalán tehát sok lehetőség van a trükközésre, annak érdekében, hogy a fogyasztás csökkenthető legyen. Ugyanakkor itt figyelembe kell venni a sebességet is, mert például a manuális interpolációra elmegy blokkonként 32 kB, vagyis a korlátozott hardverállapotokban egy blokkon belül egyel kevesebb multiprocesszor lehet aktív, ami már radikálisan csökkentheti a compute shader lépcsőn leadott teljesítményt. Persze az NVIDIA valószínűleg sosem gondolta, hogy az aktuális hardvereik az életciklusuk alatt manuális interpolációra lesznek kényszerítve, tehát a tárterületekkel való spórolás logikus tervezői döntés volt régebben, hiszen nem kevés energiát takaríthattak meg vele, de benne van a pakliban, hogy az új lehetőségeknél a spórolás visszaüt.
A shader modell 6.1 a jelenlegi tervek szerint akkor kerül élesítésre, amikor a shader modell 6.0. Nagyon valószínű, hogy a verzió szinten történő szétválasztás egy stratégiai döntés volt a Microsoft részéről, hogy az Intel és az NVIDIA kapjon időt a manuális interpoláció megvalósítására, ami egyébként ha nem is nehéz feladat, de mindenképpen időigényes. Ilyen formában viszont a shader modell 6.0 újításaihoz már tudnak kínálni előzetes támogatást, míg a shader modell 6.1-re egy külön csoport ráér felkészülni.
