Back in August of 2014, Khronos announced the Next Generation OpenGL Initiative. The industry consortium, responsible for overseeing a number of major cross-platform GPU standards such as OpenGL and OpenCL, was embarking upon a development project to create a true, next-generation successor to OpenGL and OpenGL ES. What would eventually become to be known as Vulkan, Khronos’s new graphics API would be an open, multi-platform low-level API to rival DirectX 12 and Metal.

Now 18 months after the initiative began, today Khronos is announcing that the Vulkan 1.0 specification has been released, and that the consortium and its members intend to hit the ground running. Along with the release of the specification itself, today will also mark the launch of document, drivers, SDKs, conformance tests, and even beta software support. Khronos has never had a hard API launch before – previous procedures were to release the specification and then let members trickle in with drivers and applications – so this marks a major occasion not just for graphics APIs, but for Khronos as an organization going forward.

Vulkan 1.0 – Mantle, We Hardly Knew Ye

We’ll start things off with the Vulkan API itself. Since Khronos’s last major press update almost a year ago in March of 2015, not a great deal has changed on the technical side from a high level. After being gifted Mantle 1.0 from AMD – an action that significantly sped up the development process and bypassed the need to figure out some fundamental questions about how the API should be designed – the consortium went about adapting Mantle to serve as a wider, more generic API suitable for hardware from multiple vendors across multiple OSes.

The end result is that Vulkan has its roots firmly in Mantle, through Khronos has worked to make it very clear that multiple vendors are responsible for contributing IP that ultimately went into Vulkan. And while the specific low-level details of the API are beyond the scope of this article, I do know that the shader resource binding system is significantly different from Mantle, and that’s not the only system that was updated or overhauled during Vulkan’s development.

As for the API itself, Khronos’s goals are unchanged. Vulkan will be the low-level, low overhead successor to OpenGL, as low-level APIs have become increasingly important over the past few years. By implementing such a model, Vulkan gains abilities that OpenGL never could, not the least of which is the ability for multiple threads/cores to dispatch graphics work, a scenario that maps far better to modern multi-core CPUs. This also gives Khronos’s now flagship graphics API the chance to promote compute to a first class citizen within the graphics API, introducing support for separated graphics and compute queues (think: async shading). And though we’re still some time off from widescale adoption, Khronos will also be setting up Vulkan as their preferred API for virtual reality, as the lower overhead from the API (and lack of mandatory state validation and error handling) will cut down on API latency as compared to OpenGL.

Overall, Vulkan has also given Khronos the chance to start anew and to throw out 25 years of OpenGL history, something that some sections of the development community have been clamoring for since the middle of the last decade.

Platforms & Feature Sets

Meanwhile, as Vulkan is not the only low-level API on the block – and indeed is likely to be the last major low-level API to be introduced – Khronos will not just be fulfilling their mission in releasing Khronos as an open, multi-platform API, but they will be leveraging that in order to try to drive the adoption of the API. While OpenGL ES has been a modern success story on the mobile, mainline OpenGL has floundered on the desktop for a number of years now, and along with making a clean break from OpenGL on the API side, Vulkan gives Khronos a chance to make a clean break from OpenGL’s reputation on the desktop and general developer malaise towards it. Which is not to say that Vulkan is guaranteed to be any more successful than OpenGL has been, but certainly the new API and this new era of hard launching an API give Khronos and Vulkan the best chance they could realistically have.

From a technical perspective Khronos designed Vulkan to work on most hardware and operating systems that supported recent releases of OpenGL and OpenGL ES, and by and large they will hit that goal. Linux will of course get support for the API, as will Windows. In fact as Vulkan is not tied to the Windows driver model (WDDM) like DirectX 12 is, one of Vulkan’s differentiators will be that it will also be supported on Windows 8, Windows 7, and though no specific GPU vendors have been named, even the now obsolete (but still very much used in closed systems) Windows XP. Supporting a wider range of Windows version certainly gives Vulkan a leg-up in this respect, though DirectX’s overall momentum and the free upgrades being offered for Windows 10 should not be overlooked.

Meanwhile on the mobile side, Google has previously committed towards integrating Vulkan support into Android, where it will be a first-class API. Android will not just support Vulkan for rendering, but the Android platform test itself will include tests for Vulkan. At this point in time Google has not commented on when they will actually integrate Vulkan, and the next version of Android (presumably Android N) is a likely bet, though it’s not outside the realm of possibility that it could be sooner to take advantage of next-generation SoCs that are due to launch.

Update: While Google has not announced anything, NVIDIA has published a note stating that Vulkan support will be coming to the current version of Android, Marshmallow.

Vulkan OS Support
Platform Supported?
Android Supported - Marshmallow & Later
iOS Not Supported
OS X Not Supported
Windows Supported - Windows XP & Later
Linux Supported

Unfortunately the one notable holdout here – and the reason not all current OpenGL platforms will support Vulkan – is Apple. While Apple’s specific internal plans are not public, Khronos confirmed that after initially being involved with the Vulkan working group, Apple stepped aside and is no longer participating. In the last year Apple has doubled-down on their own low-level API, Metal, even extending it to the desktop. Meanwhile Apple never did update iOS to OpenGL ES 3.1, so all signs point to them being entirely insular here for both OS X and iOS. Unfortunately this means that there will not be a modern, low-level API that can cross iOS-Android or Windows-OS X, and the overall API ecosystem will be more Balkanized than in past years, something that most developers will likely rely on middleware to resolve. Though despite all of this, Khronos was quick to note that while Apple pulled out of participating in the Vulkan working group, they are still a member of the Khronos consortium overall.

Moving on, let’s talk about feature sets. When we were briefed on Vulkan last year, Khronos announced that Vulkan would offer feature sets as a means of allowing a single API to accommodate the differences in features available on desktop and mobile GPUs. Historically OpenGL didn’t have a true concept of feature sets (rather it was individual capability bits), but they have been in use on DirectX for some time now.

For Vulkan, Khronos opted to give platform holders the right of first refusal on defining feature sets; Khronos would only define feature sets if the platform holder passed on it. Now that Vulkan is launching, we have updated information on which platforms will be defining their own feature sets, and what Khronos will be doing for the rest.

Vulkan Feature Set Definitions
Platform Defined By
Android Platform Holder - Google
Windows Khronos - Feature Sets TBD
Linux Khronos - Copy of Windows Feature Sets

Google has confirmed that they will be handling their own feature set definitions. Meanwhile, as expected, Microsoft has declined and deferred to Khronos. Finally, the Linux development community has similarly opted to put Khronos in charge of feature sets, requesting that Linux’s feature sets are made identical to Windows’ feature sets.

Khronos for their part has not yet defined the feature sets, so these are still to be determined. Now that Vulkan is shipping Khronos will be holding a developer feedback period to get input on what developers would like to see for feature sets, and to figure out what’s actually going to be viable within the consortium. The current idea being floated, though by no means guaranteed, would be to have a desktop feature set that closely mirrored OpenGL 4.5, and a separate mobile feature set that closely mirrored OpenGL ES 3.2. This would ensure that while developers are making the jump from OpenGL to Vulkan, they don’t also have to accommodate a significant shift in feature capabilities as well.

Drivers & Software

Keeping with their goals for a hard launch for Vulkan, Khronos’s members will be hitting the ground running on the driver front. The all-important Vulkan conformance test is already complete, and 30 drivers have passed testing. In turn, some of those drivers will be getting released today for developers and end-users to experiment with right away.

At this point Khronos has confirmed that Android drivers from NVIDIA and Qualcomm have passed conformance testing, as have Linux drivers from Imagination, Intel, and NVIDIA. Finally, on the Windows side, so far only NVIDIA has passed conformance testing. ARM for their part has a Linux driver under review, and while we asked AMD about a Windows driver for today’s launch, they weren’t able to get back to us by press time. However in a separate pre-written press release that will be going out at the same time as this article, they say that “With this transition to public availability of the Vulkan 1.0 API specifications, AMD will be releasing a beta version of our Vulkan™ API-enabled Radeon™ Software driver,” so if not today then I’d expect to see one soon.

Update: Windows drivers for both AMD and NVIDIA GPUs have been posted today. Both drivers are developer betas and either lack features or are based on older branches than current consumer drivers, however the NVIDIA driver has passed Vulkan conformance testing.

On the hardware side of matters, there’s still some ambiguity in the mobile space about what specific GPUs will support Vulkan, in part due to the fact that it’s Google defining the feature sets. Imagination, Qualcomm, ARM, and NVIDIA have all publicly committed to supporting Vulkan, so the question is how they will handle older architectures. Qualcomm is just launching their new Adreno 5xx series, whereas ARM Mali “Midgard” and Imagination PowerVR “Rogue” continue to be each respective firm’s leading GPU architecture. Finally NVIDIA for their part has already confirmed that Kepler and newer will get Vulkan support.

For NVIDIA that will extend to the desktop as well. So although Fermi is still slated to get DirectX 12 support (and this is something we’re looking into separately), only GPUs starting with Kepler will get Vulkan. AMD for their part has been advertising Vulkan support for their entire range of Graphics Core Next for some time, and at this point that encompasses all of their non-legacy GPUs. Finally, Intel has confirmed that Broadwell (Gen 8.5) and later will be getting official Vulkan support, and that the Linux driver will be open source.

Vulkan Desktop GPU Support
Vendor GPUs
AMD GCN 1.0 & Later
Intel Broadwell (Gen 8.5) & Later
(Ivy Bridge & Haswell Unconfirmed)
NVIDIA Kepler & Later

Also being released today alongside Vulkan drivers will be Vulkan software as well. Croteam has previously announced that they have been developing a Vulkan rendering path for their puzzle-em-up game The Talos Principle, and Khronos tells us that a version of the game with beta Vulkan support will be released today, giving everyone something to test Vulkan against. Croteam does note however that the Vulkan rendering path should be considered a proof of concept demonstration to showcase that Vulkan words, and indeed The Talos Principle is not a game known for pushing a lot of draw calls or using rendering techniques that would greatly benefit from Vulkan’s most potent abilities.

Meanwhile though we haven’t heard of confirmed release dates, there have been several Vulkan demos showcased over the last year from hardware and benchmark developers alike, including Intel, Valve, Basemark, and Kishonti. So The Talos Principle may not be the only Vulkan software release today.

Developers – SDKs and Documentation Available Now

Finally, on the development side of matters, today’s hard launch will also include tools for developers to begin writing games against the final specification. Khronos for their part has a slew of resources, including documentation, references, and the source code for their validation and loader tools for debugging.

Meanwhile LunarG, the Valve-backed software group tasked with developing a Vulkan SDK, will be releasing their SDK for Windows and Linux. The LunarG SDK will include a complete set of tools for Vulkan development, including the necessary validation layer, debugging tools, and trace and replay tools.

At the same time however Khronos has also been trying to make it clear to the press and developers alike that while Vulkan is the next generation successor to OpenGL, OpenGL itself isn’t going anywhere. Like DirectX 12, Vulkan’s transition to a low-level API will unquestionably make it harder to use, and Khronos expects that it will primarily be used by guru-level programmers. For other programmers who don’t need the abilities of Vulkan or lack the expertise to comfortably program against it, OpenGL will not be going anywhere and is still a supported multi-platform graphics API.

Ultimately I think middleware is going to solve much of the developer accessibility problem – as has been the plan with DirectX since the beginning – and Khronos tells us that at this point developer feedback and involvement on Vulkan has been better than expected. It is certainly a very optimistic message going into what is the group’s first hard launch, and with GDC 2016 taking place next month, it will be interesting to see what attendance is like at the planned developer events.

Comments Locked


View All Comments

  • VertexMaster - Tuesday, February 16, 2016 - link

    "Like DirectX 12, Vulkan’s transition to a low-level API will unquestionably make it harder to use".

    That statement is a little mis-leading. *Real-world* OpenGL applications are extremely hard to develop, especially if you are targeting multiple platforms / GPU vendors.
    - GLSL compilers are different with every vendor / OS with their own quirks and bugs (lots of bugs, especially mobile GPUs).
    - Driver performance is a huge factor with OpenGL and means that if you want anything close to optimal performance you have to customize your rendering approach for each vendor generation.
    - Each platform has it's own way of initializing the API. i.e. in windows OS case, you literally create an ancient OpenGL 1.x context and use that to initialize a newer version etc. It's madness.

    Trivial OpenGL examples might appear easier to comprehend from a code stand point, but for people who actually write GPU-enabled applications Vulkan will be much less frustrating (assuming good drivers). OpenGL was designed in the early 90s and while the API has evolved, it's still a giant hidden state-machine with endless side-effects. The last 30 years have taught software developers in general that those types of APIs are incredibly hard to use, especially as complexity scales up.
  • Ryan Smith - Tuesday, February 16, 2016 - link

    I won't disagree that OpenGL was more difficult to use than it should have been (this being part of the reason DX became so dominant). However with developers required to maintain their own state on Vulkan, it's going to be harder still, and Khronos has been trying to make it clear that it's not meant to be as accessible as OpenGL.
  • extide - Tuesday, February 16, 2016 - link

    Also, remember that developers have been programming OpenGL for a long time, so even if it IS complicated, there is a lot of knowledge around that kind of diminishes that aspect. This is an entirely new ballgame.
  • Flunk - Tuesday, February 16, 2016 - link

    All those logos on their supported OSes pages can be boiled down to just two OS families, Windows and Linux.
  • tuxRoller - Tuesday, February 16, 2016 - link

    IOW, the overwhelming majority of user facing computers.
  • ruthan - Tuesday, February 16, 2016 - link

    How to test it, on Win 7? I have last Nvidia stable driver and Talos principles demo game - no Vulkan renderer options - only DX9,DX11 and OpenGL.
    What next i need?
  • Stuka87 - Tuesday, February 16, 2016 - link

    While it states nVidia has passed conformance testing, it does not state that nVidia has released a driver with that support. It will most likely be in a beta version long before its in a release version.
  • ruthan - Tuesday, February 16, 2016 - link

    I read elsewhere (Phoronix) that even driver is released and after this post i found one:

    I installed it, but this not Vulkan options in Talos principle, but maybe i need restart of Windows, maybe game is not ready yet.

    These Phoronix articles are usually biased - by Linux like point of view - something is promised, half working = something is working.
  • ruthan - Tuesday, February 16, 2016 - link

    Here is solution, Talos beta - Steam flag magic is needed:
  • tuxRoller - Wednesday, February 17, 2016 - link

    They aren't biased in that way. The info they give is of a different story than you'd get from most tech/gaming sites and focuses on Linux driver development. It's a complicated area which means "working" has different meanings than what you're probably used to. For instance, you could say that the hardware is "working" once the drm-kms driver had been written. That doesn't mean you'll be able to play game X, but that the "full" capabilities of hardware are now available. Even that is a simplification, but the point is that the ARTICLES, let alone the information provided, aren't biased against Windows.

Log in

Don't have an account? Sign up now