Ha visszatekintünk a múltra, és kifejezetten a játékfejlesztőknél lerakott eredményeket szemléljük, akkor az OpenGL csúnyán kikapott a DirectX-től a Windows operációs rendszeren belül. Ennek több tényezője volt, és messze az tekinthető az elsődleges oknak, hogy a Microsoft lefizetett mindenkit. Ha az OpenGL saját problémáit figyelmen kívül hagyjuk, akkor is az egyik kritikus tényezőt a HLSL jelentette. A Microsoft képes volt általánosan elterjeszteni a saját shader nyelvét, ami már lekorlátozta a fejlesztők választási lehetőségeit, hiszen az OpenGL API használatához GLSL nyelvben kellett írni a shadereket.
A röpke múlt után ugorjunk a jelenbe, és azt kell mondani, hogy ez még ma is probléma, mivel a Vulkan API sem eszi meg közvetlenül a HLSL shadereket, mivel a hivatalos shader nyelve a SPIR-V. Utóbbi azonban egy reprezentációs szint, vagyis megfelelő fordítóval bármilyen magas szintű nyelvről fordítható rá kód, tehát sokkal kellemesebb a Khronos Group helyzete, mint régebben. Annál is inkább, mert bejött a számításuk, és számos olyan projekt született, amely a HLSL-ről SPIR-V-re való fordítást szorgalmazza. Ez kritikus fontosságú tényező, ugyanis rengeteg fejlesztőnek vannak HLSL-ben a kódjai, és elképesztő mennyiségű munka lenne ezeket utólag átírni GLSL-re.
A Vulkan API sikeréhez az egyik recept tehát egy megfelelő fordítóinfrastruktúra kidolgozása a HLSL-hez. Nem véletlen, hogy a Khronos Group az idei SIGGRAPH-on ennek is szentelt egy kis időt, és felvázolták a lehetőségeket, amelyek igen kedvezőek most is.
Az egyik opció a közösségi projektnek tekinthető Glslang, ami már be van teszteltve, hiszen a Dota 2 Vulkan portja ezzel készült el, illetve az Oxide Games is ezt használja a Ashes of the Singularity érkező Vulkan módjához. A shader modell 5.0 majdnem össze lehetősége elérhető, ahogy pár funkció is a shader modell 5.1-ből. A másik lehetőség a Google által fejlesztett Shaderc, amely nagyrészt a Glslangre épül, így a képességei lényegében megegyeznek. A Shaderc esetében opcionálisan használható a spirv-opt eszköz a fordítási folyamat részeként.
A jövő szempontjából azonban nagyon fontos a Google és a Microsoft projektje, ugyanis a HLSL a shader modell 6.0-tól jelentősen megváltozik, ami azzal is jár, hogy a Microsoft eddigi D3BC köztes rétegét is leváltja a jóval modernebb DXIL. A jó hír, hogy a redmondi óriáscég a nyílt shader fordítóra szavazott, ami a dxc nevet kapta, és ehhez a Google készít egy spiregg kódnevű kiegészítést. Ennél a projektnél a kritikus szempont, hogy be lesz építve a dxc-be, vagyis tulajdonképpen az a végső cél, hogy a fejlesztő az új specifikációk szerint írt HLSL kódoknál eldönthesse, hogy DXIL-t fordít belőlük, vagy SPIR-V-t. A Google és a Microsoft közösen dolgozik azon, hogy az egyes új dxc verziók azonnal képesek legyenek mindkét IR-re megfelelő kódot fordítani.
A fentiek miatt a Vulkan API helyzete a shader modell 6.0-tól kezdve rendkívül kedvezővé válik, ugyanis az új HLSL specifikációk gyakorlatilag már a kiadás napján le lesznek kezelve. Ebből már kitalálható, hogy a Vulkan nem lesz olyan egyszerűen legyőzhető a Microsoft számára, mint az OpenGL, ami alapvetően jó a piacnak, mivel innovációra kényszeríti egymást a két fél.
