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

  • TEAMSWITCHER - Tuesday, March 3, 2015 - link

    Your absolutely right. Metal is available today for iOS devices running Apple's A7 processor or better. That's millions of iPhones (5s, 6, 6+), and iPads (Air, Air 2), that can run Metal apps right And there are zero (that's right - a big fat goose egg) Android devices that support Vulcan today. Sure, Metal will never gain any traction.
  • ThreeDee912 - Wednesday, March 4, 2015 - link

    OS X heavily uses OpenGL, and I'm pretty sure Metal is iOS-only. Should be interesting to see if Apple implements Vulkan into OS X in a future release. Probably won't be in 10.11 or even 10.12 though as it's still in development.
  • purerice - Tuesday, March 3, 2015 - link

    Before people flame on AMD and Mantle, read this from the article:
    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

    TLDR: A small contribution to Vulkan means AMD can cut back on Mantle spending. Win-Win. OpenGL improves, AMD saves money, and DirectX, Metal, etc. get better competition.
  • mdriftmeyer - Tuesday, March 3, 2015 - link

    Vulcan creates zero competition for Metal API. The only GPGPU driver on iOS is Apple's modified ImgTec GPGPU IP integrated into the A series processors.

    Metal is not for OS X.

    Vulcan spec will be lucky to be finished by 2015 and won't see full implementation far past 2017.

    They've been ``working on this'' since June 2014. In short, they've given themselves 18 months from start to finish on a spec. Meanwhile, OpenGL 4-4.5 is still not completely implemented anywhere, never mind the vendor specific extensions.

    I'm all for Vulcan having the potential to stop the ductape world of AMD, Intel, Nvidia extensions and gaming vendors juggling OpenGL/DirectX but Vulcan doesn't change the juggling. When we get an actual commitment from Apple on OS X and all major gaming vendors to support Vulcan, then I'll be impressed.

    Full disclosure: I own AMD and Apple stock.
  • stephenbrooks - Tuesday, March 3, 2015 - link

    I wouldn't hold your breath for Apple to support a cross-platform standard. For everyone else, Vulcan looks like a neat idea but will take years to go mainstream.
  • mdriftmeyer - Tuesday, March 3, 2015 - link

    I don't expect Apple to adopt Vulcan for iOS. I do expect on OS X, but not until OpenGL 4.5 is already past and the gaming industry has flushed out Vulcan on OS X and Windows. Linux will be an afterthought.
  • Antronman - Tuesday, March 10, 2015 - link

    Well if it means anything, Source 2 is going to have Vulkan support right out of the box.

    People expect it will be released around The International.
  • eanazag - Tuesday, March 3, 2015 - link

    I'd like to Phys-X replaced some sort of OpenCL runtime so it could be leveraged on any device. Nvidia has gone through great lengths to lock down its use.

    I would throw a GTX 750 in my desktop just to run it with my AMD R290. I bounce back and forth between GPU vendors. Or run physics on the Intel iGPU.

    This release is a good step towards making that a possibility.
  • mdriftmeyer - Tuesday, March 3, 2015 - link

    Bullet 3 is an OpenCL implementation Physics library:
  • SirKnobsworth - Tuesday, March 3, 2015 - link

    So if AMD contributed some of its Mantle resources toward Vulkan, then where does that put the future of Mantle? Is Vulkan the future of Mantle, or will AMD continue to develop Mantle on its own?

Log in

Don't have an account? Sign up now