A grafikus API-k szempontjából izgalmas lesz az idén márciusban megrendezendő GDC, ugyanis a Microsoft és a Khronos Group is újításokon dolgozik. Az előbbi cég alapvető frissítést tervez a DirectX 12-höz, amely igazából inkább a jövőbe tekint. Ezen belül a Tiled Resources fog bővülni, méghozzá egy új TIER_4-es szinttel, illetve érkezik a shader modell 6.2 is. Utóbbi nagy újítása, hogy lehetővé teszi a 16 bites minfloat16, min16int és min16uint adattípusok memóriaoperációkon keresztüli használatát, de ez csak opcionális képesség, vagyis akkor is támogathatja egy implementáció a shader modell 6.2-t, ha maga a hardver erre nem képes. Ez nem jelent majd problémát a megírt kódok szempontjából, mivel a fordító képes lesz kezelni a hardverekből eredő limitációkat.
Érdekes, bár nehezen értelmezhető újítás még a Cross Node Adapter Sharing új, TIER_3-as szintje. Hivatalos megerősítés nincs róla, de valószínűleg a TIER_2-ben még nem engedélyezett operációkat, vagy legalább ezek egy részét is támogatja a node-okon keresztül.
A Vulkan API némileg nagyobb változáson megy majd keresztül, ugyanis az aktuálisan még KHX, azaz kísérleti fázisban lévő kiterjesztések végleges formát öntenek majd, ezzel pedig ténylegesen használható lesz a több GPU-s mód. Ez azonban csak az újítások egy kis része lesz, lehetővé válik még az API-k közötti interoperabilitás, így például egy Vulkan API-ban létrehozott puffer ugyanabban a programban felhasználható az OpenCL API-ból is, illetve több folyamat is használhatja ugyanazt a kontextust. Javulni fog még a renderpass, illetve szigorodnak majd a memóriamodellre vonatkozó követelmények.
Ha úgy vesszük, akkor a Vulkan és a DirectX 12 is egy alapvető frissítést kap, nyilván az új funkciók hasznosságát nem vitatva. Egy pontra azonban nagyon figyel most a Microsoft és a Khronos Group is, ugyanis a következő években ki akarják húzni a multiplatform fejlesztés egyik méregfogának tartott shader nyelvek problémáját. A gond az, hogy nemcsak a célozható gépek, hanem már az API-k szintjén is eltérő shader nyelvek támogatottak. A PC-n a HLSL az elterjedt, ahogy az Xbox One konzolokon is, míg a PlayStation 4 termékcsalád esetében a PSSL, a Nintendo Switch nevű masinán pedig a GLSL a legkedveltebb alternatíva. Ráadásul akkor se lehet nagyon boldog a piac, ha csak a PC-t és az Xbox One platformot nézi, ugyanis itt is mások a HLSL specifikációk, azaz valóságos rémálom ezt jól kezelni.
A Microsoft nyilván nem enged. Nekik jó a HLSL, sok pénzt fektettek abba, hogy a shaderek többsége ebben a nyelvben legyen írva. Ugyanakkor a redmondi óriáscég sem vak, és látja magát a problémát, ami ellen ha nem is engedményekkel, de más módon megpróbálnak tenni, méghozzá egy dxc nevű nyílt shader fordítóval. Utóbbi értékét a Khronos Group is meglátta, így a GDC-n külön előadást szentelnek majd a HLSL nyelv Vulkan API-ból történő támogatásának.
Végeredményben ez nagyon kedvező irány a fejlesztők számára, ugyanis a Microsoft eleve azon dolgozik, hogy egységesítse a HLSL specifikációit a PC és az Xbox One platformokon, aminek hála egyszerre célozhatók a rendszerek, méghozzá az új DXIL reprezentációs formátumon keresztül, ami leváltja a mára igencsak túlkorossá vált D3D bájtkódot. A Khronos Group ide úgy kapcsolódik be, hogy a nyílt forráskódú dxc-t kiegészítik a SPIR-V reprezentációs formátumra való fordítás lehetőségéve. Ennek megfelelően, ha a fejlesztők új specifikációjú HLSL kódokat írnak, akkor abból lehet fordítani a PC-n DirectX 12-re (DXIL) és Vulkan (SPIR-V) API-ra, illetve ugyanezek a kódok használhatók az Xbox One termékcsaládra (DXIL), valamint a Nintendo Switch (SPIR-V) konzolra is. Egyedül a PlayStation 4 marad a kakukktojás, ami még mindig nem szerencsés, de ahhoz a fragmentációhoz képest, ami ma uralkodik az előrelépés így is jelentős lesz.
