Bár sok felhasználó azon aggódik, hogy az API-k reformja gondokat fog okozni a fejlesztőknek, a valóság az, hogy sokkal nagyobb bajnak tűnik az az irány, amiben szimplán túl sok shader nyelvvel kell számolni. Joshua Barczak, a Firaxis motorprogramozója a napokban írta a Twitteren, hogy inkább támogatna 5-6 gyártóspecifikus API-t, mint három teljesen különálló shader nyelvet.
Az API-k reformja szempontjából valóban ez tűnik a legnagyobb problémának, hiszen a Microsoft DirectX 12 és az AMD Mantle HLSL (High-Level Shading Language), az Apple Metal MSL (Metal Shading Language), míg a Vulkan GLSL (OpenGL Shading Language) nyelvet támogat. Ez gyakorlatilag azt jelenti, hogy az az ideális, ha minden shader programot háromszor ír meg a fejlesztő, persze ha a programot egyaránt ki szeretnék adni Windowsra, Linuxra és Mac OS X-re. Ezt már ma sem teszik meg egyébként, így sok érintett például konvertálja a GLSL kódot a HLSL kódból, de ennek azért megvannak a maga korlátjai, és sok esetben nem tesz jót a teljesítménynek sem.
Ezzel kapcsolatban érdeklődtünk a fejlesztőknél és megtudtuk, hogy vannak opciós megoldások a problémára, de valóban sokkal jobb lenne, ha egyetlen shader nyelv létezne. Az iparágban érintettek szerint az sem számítana, ha tényleg lenne 5-6 gyártóspecifikus API, mert a mai multiplatform videojáték-motorok struktúráját úgy készítették fel, hogy az adott API-t támogató back-end réteg könnyen cserélhető legyen. Ez alapvető igény egy olyan stúdiónál, amely PC mellett konzolokra is dolgozik, és innen már nincs különösebb jelentősége annak, hogy PC-n mennyi API-t kellene támogatni. Ha van egy kész alacsony szintű hardverelérést biztosító grafikus API-ra vonatkozó back-end, akkor onnan egy másik API-t beépíteni csupán egy ember nagyjából egy hónapos munkája. Persze számít az is, hogy melyik API-ról mire vált a stúdió. Például a Mantle API-ról Vulkan API-ra áttérni a legegyszerűbb, mivel a két rendszer nagyrészt megegyezik, így a meglévő kód közel 80-90%-a teljesen újrahasznosítható.
A fentiekkel kapcsolatban megtudtuk azt is, hogy az adott API lényeges mértékben nem változtat az optimalizáláson sem, így elég egyszer jó alaposan átolvasni a célzott architektúrákhoz készített gyártói dokumentációkat (már ha elérhető), és abból több back-endre is megírható az optimalizált vezérlés. Emiatt nem is lesz gond abból, hogy a kernel grafikus meghajtó feladatait az alkalmazás veszi át.
A shader nyelvek problémája azonban tényleg jelentős, és nincs igazán optimális megoldás rá. Nyilván az világos, hogy háromszor senki sem fogja megírni a programokat, így jelen formában a legcélszerűbb alternatívának a saját shader nyelv tűnik. Hasonló koncepcióval már ma is több fejlesztő dolgozik, és a jövőben ez nagyon elterjedt lehet. A saját shader nyelv előnye, hogy egyetlen kódot kell írni, majd azt szintén saját fordítóval le kell fordítani az API-k köztes nyelvére. Egy ilyennel a Metal API is kiegészül, hiszen mostantól nem csak egyetlen grafikus architektúrát kell kiszolgálni.
A fejlesztők szerint az LLVM fordítóinfrastruktúra ezekhez a projektekhez kifejezetten hasznos lesz, mivel komoly nyílt kutatást végez a közösség például az LLVM IR-ből való D3D bájtkód (a DirectX köztes nyelve) generálásával kapcsolatban. A SPIR-V (a Khronos Group köztes nyelve) a Vulkan API-ban is nagyon egyszerűen célozható, hiszen a Khronos Group már alapból úgy építette fel a rendszert, hogy megkönnyítse az egyéni shader nyelvek támogatását. Ezzel kapcsolatban jó hír, hogy a SPIR-V-hez disassembler is készül, tehát alapvetően a Vulkan API kínálja a legjobb lehetőséget a fejlesztőknek az efféle projektekhez. Nyilván a Khronos Group pontosan látja merre halad a piac, és egy nyílt koncepció a megfelelő fejlesztőeszközökkel megtámogatva gyorsabb kódokat eredményezhet.
Úgy néz ki tehát, hogy a jövőben nem is igazán a több API támogatása lesz a problémás, hanem a shader programok oldalán a megfelelő, több platformra levetített támogatás, ezt ugyanis láthatóan megnehezíti a sok eltérő shader nyelv.
