A Windows 10 Creators frissítés nagyjából egy hetes lesz, és a Microsoft sok információval látta el a felhasználókat is az újításokról. Vannak azonban olyan változások is, amelyeket a cég különösebben nem ver nagy dobra, elsődlegesen azért, mert csak a megcélzott réteg egy kis részét érintené. Ezekkel jórészt nem találkozik majd a felhasználó, legalábbis nem a hagyományos értelemben, ugyanis az újítások azt a célt szolgálják, hogy a rendszer zavartalanul működjön az új lehetőségekkel. Mindenesetre a frissítések részletei mindig érdekesek, így érdemes megvizsgálni, hogy milyen titkolt képességeket kapott a 1703-as verziójú Creators Update.
Ezúttal is javított a cég a DirectX 12 API-n, így új lehetőségeket kaptak a fejlesztők. Ezek közül a legfontosabb egy új metódus és új struktúra a PSO-k, azaz a Pipelines State Objectek kreálására, amellyel a Microsoft egységesítette a grafikai és a compute futószalagok létrehozásának interfészét. Szintén lényeges változás, hogy az API kapott még két új metódust az erőforrások alacsonyabb késleltetésű frissítésére is, amely különösen hasznos lehet a VR alkalmazásoknál, ahol a késleltetés kritikus fontosságú. Többek között ezekkel megváltoztatható a jelenetszámításnál használt kamerapozíció még a jelenethez tartozó képkocka kiszámítása előtt. Tulajdonképpen ez az AMD LiquidVR környezetében használt, Latest Data Latch funkció szabványosított formája.
Újítás még a depth bounds test, amellyel az AMD már korábban kiterjesztette a DirectX-et, de ez gyártóspecifikus volt, így csak a GCN architektúrára épülő Radeonok mellett tudták használni a fejlesztők. Jellemzően a Frostbite Team élt a lehetőséggel, de most ennek beépítette a Microsoft a szabványos megvalósítását, ami jó, mert ezzel a módszerrel gyorsítható a pixel shaderek végrehajtásának sebessége, ugyanis a specifikusan limitálható, hogy milyen pixeleket kell leképezni, így a futtatandó utasítások száma is csökken. A depth bounds testet az összes GCN architektúra épülő Radeon és a második generációs Maxwell vagy Pascal architektúrára épülő GeForce sorozat támogatja.
A másik újításnak a programozható mintapozíció számít, amivel a programozó meghatározhatja, hogy a pixelen belüli többszöri mintavételezés során a mintavételi pontok hol lehetnek. A DirectX API-ban korábban szabványos, előre konfigurált mintavételi pontok voltak meghatározva, amit a hardvereknek támogatni kellett, de az új módszerrel a programozói szabadság lényegében kiterjesztésre kerül. Magát a funkciót úgy néz ki, hogy alapvető TIER_1 szinten az összes DirectX 12-t támogató grafikus vezérlő képes kezelni, de az újítás több szintre osztja a képességek elérhetőségét, arról viszont még nincs adat, hogy a TIER_2-t milyen hardverek tudják kezelni. A legnagyobb esély erre a második generációs Maxwell és Pascal architektúrájú GeForce-oknál van.
Végül a shader modell 6.0 is tesztelhető a wave operation intrinsics mellett. Ehhez szükség van egy DXIL támogatással rendelkező meghajtóra is, de ezeket az AMD és az NVIDIA már biztosítja. A jó hír, hogy a tervekhez képest változtak a követelmények. Eredetileg a Microsoft minimum D3D_FEATURE_LEVEL_12_0 hitelesítést kért, de végül elfogadták azt, hogy majd a gyártók visszajelzik, hogy a hardver képes-e támogatni az új shader modellt. Ezzel kapcsolatban jön a rossz hír, ugyanis a wave operation intrinsics csoportba tartozó függvényeket a vállalat még mindig minimum a D3D_FEATURE_LEVEL_12_0-s szinthez.
A wave operation intrinsics esetén sem minden olyan kedvező, ugyanis a specifikációk nagyon kötöttek. Például a WaveBallot 64 bites maszkkal tér vissza, ami a GCN-en belüli 64 bites skalárregiszternek nagyszerű, de a többi architektúrának egyáltalán nem az. Ez persze csak egy apró tényező, rosszabb a WavePrefixSum esete, amely a GCN3 és GCN4 architektúrán csak egy utasításból megvan, míg a többi rendszernél a támogatásához komolyabb befektetésre van szükség. A probléma igazából ezzel az, hogy túl kevés idő van már ezeket az előzetes specifikációkat korrigálni, ha ez gyakorlatilag egy év alatt nem történt meg. Valószínű, hogy a Microsoftnak sokkal jobban számított, hogy az Xboxról könnyű legyen PC-re portolni a kódot, mint az, hogy a gyártók számára egy átfogó megoldást kínáljon a mai SIMT GPU-k többszálú programozására.
Különösen problémás lehet majd a global ordered append függvénycsoport, amelynél a meghajtó implementációja kezeli az atomi műveletek megfelel sorrendben történő végrehajtását. Ez addig nem gond, amíg a hardverben van erre egy gyors, globális adatmegosztásra szolgáló tároló, de ha ez nincs meg, akkor tulajdonképpen a VRAM-ot kell használni erre a célra. Maga a funkció tagadhatatlanul az Xbox One konzolon is elérhető ordered atomics képesség másolata, ami azért baj szabványos szinten, mert PC-n csak a GCN-ben van erre kialakított globális adatmegosztás a wave-ek közötti kommunikációra.
A Microsoft gondolkodása abból a szempontból megalapozott, hogy az Xbox One-ra megírt shadereket egy az egyben át lehessen hozni PC-re, hiszen az a fejlesztőknek nem munka, de global ordered append és hasonló függvénycsoportok mellett ez az egész csak illúzió, ugyanis az a kód a GCN architektúrára épülő Radeonokon kívül minden más hardveren rendkívül rossz hatásfokú lesz. Ergo csak annyi változik, hogy a GCN-re jók lesznek a konzolra használt shaderek, de a többi hardverre úgyis kell valami alternatív megoldás az egyes problémákra, tehát a befektetett munka szempontjából nagyjából ugyanott lesznek a fejlesztések ahol ma.
Az API kapott még pár további tesztfunkciót is, amelyeket a fejlesztők elérhetnek, de szállítani programot ezekkel még nem lehet.
