Continuing this week’s GDC-2015 fueled blitz of graphics API news releases, we have Khronos, the industry consortium behind OpenGL, OpenCL, and other cross-platform compute and graphics APIs. Back in August of 2014 Khronos unveiled their own foray into low-level graphics APIs, announcing the Next Generation OpenGL Initiative (glNext). Designed around similar goals as Mantle, DirectX 12, and Metal, glNext would bring a low-level graphics API to the Khronos ecosystem, and in the process making it the first low-level cross-platform API. 2014’s unveiling was a call for participation, and now at GDC Khronos is announcing additional details on the API.

First and foremost glNext has a name: Vulkan. In creating the API Khronos has made a clean break from OpenGL – something that game industry developers have wanted to do since OpenGL 3 was in development – and as a result they are also making a clean break on the name as well so that it’s clear to users and developers alike that this is not OpenGL. Making Vulkan distinct from OpenGL is actually more important than it would appear at first glance, as not only does Vulkan not bring with it the compatibility baggage of the complete history of OpenGL, but like other low-level APIs it will also have a higher skill requirement than high-level OpenGL.

Naming aside, Vulkan’s goals remain unchanged from the earlier glNext announcement. Khronos has set out to create an open, cross-platform low-level graphics API, bringing the benefits of greatly reduced draw call overhead and better command submission multi-threading  – not to mention faster shader compiling by using intermediate format shaders – to the entire ecosystem of platforms that actively support Khronos’ graphics standards. Which these days is essentially everything outside of the gaming consoles. This is also Khronos’s unifying move for graphics APIs, doing away with separate branches of OpenGL – the desktop OpenGL and the mobile/scaled-down OpenGL ES – and replacing it with the single Vulkan.

Being announced this week at GDC are some additional details on the API, which given the intended audience is admittedly a bit developer centric. Vulkan is not yet complete – the specification itself is not being released in any form – but Khronos is further detailing the development and execution flows for how Vulkan will work.

Development tools have been a long-standing struggle for Khronos on OpenGL, and with Vulkan they are shooting to get it right, especially given the almost complete lack of hand-holding a low-level graphics API provides. For this reason the Vulkan specification includes provisions for common validation and debug layers that can be inserted into the rendering chain and used during development, allowing developers to perform in-depth debugging on the otherwise bare-bones API. Meanwhile conformance testing is also going to be heavily pushed and developed, having been something OpenGL lacked for many years and something that was a big help in developing Khronos’ more recent APIs such as WebCL. This being Khronos, even the conformance testing is “open” in a way, with developers able to submit new tests and Khronos encouraging it.

The actual Vulkan API itself has yet to be finalized, however at this point in time Khronos expects it to behave very similar to Mantle and DX12, so developers capable of working on the others shouldn’t have much trouble with Vulkan. In fact Khronos has confirmed that AMD has contributed Mantle towards the development of Vulkan, and though we need to be clear that Vulkan is not Mantle, Mantle was used to bootstrap the process and speed its development, making Vulkan a derivation of sorts of Mantle (think Unix family tree). What has changed from Mantle is that Khronos has gone through a period of refinement, keeping what worked in Vulkan and throwing out portions of Mantle that didn’t work well – particularly HLSL and anything that would prevent the API from being cross-vendor –  replacing it with the other necessary/better functionality.

Meanwhile from a shader programing perspective, Vulkan will support multiple backends for shaders. GLSL will be Vulkan’s initial shading language, however long-term Khronos wants to enable additional languages to be used as shading languages, particularly C++ (something Apple’s Metal already supports). Bringing support for other languages as shaders will take some effort, as those languages will need graphics bindings extended into them.

As for hardware support for Vulkan, Khronos tells us that Vulkan should work on any platform that supports OpenGL ES 3.1 and later, which is essentially all modern GPUs, and desktop GPUs going some distance back. To be very clear here whether a platform’s owner actually develops and enables their Vulkan runtime is another matter entirely, but in principle the hardware should support it. Though this comes as something of an interesting scenario, as a bare minimum of OpenGL ES 3.1 implies that tessellation and geometry shaders will not be a required part of the standard.  As these are common features in desktop parts and more recent mobile parts that are Android Extension Pack capable, this means that these will be optional features for developers to either use (and require) or not at their own discretion.

Wrapping up our look at the API, Khronos tells us that they’re on schedule to release initial specifications this year, with initial platform implementations shortly behind that. Given the fact that Khronos tends to do preliminary releases of APIs first, this puts Vulkan a bit behind DirectX 12 (which will see its shipping implementation this year), but not too far behind.  By which time we should have a better idea of what platforms and GPUs will see Vulkan support added, and what the first games are that will support the API.


Finally, no discussion of Vulkan can be complete without a discussion of its language frontend. Vulkan’s frontend will be powered by SPIR-V, the latest version of Khronos’ Standard Portable Intermediate Representation.

By basing Vulkan around SPIR-V, developers gain the ability to write to Vulkan in more languages, being able to feed Vulkan almost any code that can be compiled down to SPIR. This is similar to what SPIR has done for OpenCL – which is what SPIR was initially created for – allowing for many languages to work on OpenCL-capable hardware through SPIR. As a side benefit for Vulkan, this also means that Vulkan shaders can be shipped in intermediate format, rather than as raw high-level GLSL code as OpenGL’s shader compiler path currently requirements.

In putting together SPIR-V, what Khronos has done is essentially extended Vulkan’s graphics constructs into the API, allowing SPIR-V to service both compute and graphics workloads. In the short term this is unlikely to make much of a difference for developers (who will be busy just learning the graphics side of Vulkan), but in the long run this would allow developers to more freely mix graphics and compute workloads, as the underlying runtime is all the same. This is also where Vulkan’s ability to extend its shading language from GLSL to other languages comes from, as SPIR’s flexibility is what allows multiple languages to all target SPIR.

SPIR-V also brings with it some compute benefits as well, but for that we need to talk about OpenCL 2.1…

Comments Locked


View All Comments

  • keitaro - Tuesday, March 3, 2015 - link

    So will Vulkan be able to live long and prosper?

    Sorry, had to do it.
  • damianrobertjones - Tuesday, March 3, 2015 - link

    Probably longer than you or I!
  • Flunk - Tuesday, March 3, 2015 - link

    That's what people said about OpenGL and it looks like that's not going to happen. I'm sure Vulkan will be in turn, replaced by something else. It might take 10-30 years of course.
  • ddriver - Tuesday, March 3, 2015 - link

    Not necessarily. OpenGL is a high level abstraction, and as such had a lot of inherent shortcomings. Vulkan is a low level API to use GPUs and as such is far more flexible, and thus it will stay relevant much longer. The only "lower level" you can go is assembly, which will rarely be an attractive option for most developers, since it is not portable and actually increases the effort to support different architectures tremendously.

    Think of Vulkan as of C - it is 43 years old now and still very relevant, for exactly that reason - it hits the sweet spot, it is the lowest possible level language with least overhead that is still portable. A big chunk of the codebase today is still C, and the rest is in languages, build mostly with C.
  • Antronman - Tuesday, March 10, 2015 - link

    C isn't used in the development of present-day applications.

    Derivatives are.

    C# was released only 15 years ago, C++ was developed in '79 but only standardized 17 years ago.
  • dacostafilipe - Tuesday, March 3, 2015 - link

    If we then look at some Vulkan code, Vulkan is more Mantle then not!
  • TheJian - Tuesday, March 3, 2015 - link

    ROFL. Mantle was a waste of VERY valuable resources (that AMD doesn't have much of these days). But you just keep telling yourself mantle has merit. ;) DX12 and glNext were coming anyway, which is why there was no need for Nvidia to do anything (nor amd, but management screwed them again). After the flop that is Win8/8.1, MS had to do something with directX to sell windows 10, which is still win8 with lipstick. Heck they're trying so hard to put lipstick on this pig, it caused them to skip a whole win9...LOL.

    But hey, if it makes you feel good, what part of Vulkan code is Mantle? :) I think anandtech is blowing the mantle contribution out of proportion (as an AMD only portal site should I guess, they glorified this waste of money here on anandtech). Since Neil Trevett is running Khronos (and Nvidia's Mobile Ecosystem division), I'm sure NV has some code in there too...LOL.
  • dacostafilipe - Tuesday, March 3, 2015 - link

    You don't believe me? Then what about this :

    and this

    But hey, I certainly made that up, because, how could somebody like you be wrong ... no, never :P
  • heffeque - Tuesday, March 3, 2015 - link

    That was a very clear "in your face", my good sir.
    I tip my imaginary hat to you.
  • bwat47 - Tuesday, March 3, 2015 - link

    Yeah, its pretty clear that mantle heavily influenced the low level direction that glnext and dx12 took in the end.

    Mantle served as an important proof of concept that a low level api is viable on pc. Mantle did its job

Log in

Don't have an account? Sign up now