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.

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.

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.

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.