Next Generation OpenGL Becomes Vulkan: Additional Details Releasedby Ryan Smith on March 3, 2015 3:02 AM EST
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…
Post Your CommentPlease log in or sign up to comment.
View All Comments
Flunk - Tuesday, March 3, 2015 - linkIf all it did was convince Microsoft to build DirectX 12, then it served it's purpose. It's cheaper for AMD to just drop it now and they've achieved their goal.
piiman - Saturday, March 7, 2015 - linkDidn't dx12 start development before Mantle?
Jumangi - Tuesday, March 3, 2015 - linkYour a graphics tech legend...In your own mind.
Creig - Tuesday, March 3, 2015 - linkSomebody needs a bit more fiber their diet.
blanarahul - Tuesday, March 3, 2015 - link*yawn* *rubs eyes* Did I miss something?
TallestJon96 - Tuesday, March 3, 2015 - linkI agree with some if what you're saying, but not all. Mantle is dead, but at least it started this low level APIA business. I think FreeSync will be quite good (maybe worse than Gsync, but not much), but it another no win situation, imthey don't make any money from it.
Money on consoles is not a waste, it's one of the few places they have steady revenue. The PS4 is based on an app, and it would be bass-ass to see them give it a comercial release (I imagine they are contractually obligated not to). I think APUs is a market they should try to work to their advantage. For casual and older games, APUs are a pretty economically friendly way to game. If AMD can get higher end APUs that are cheap enough, I think they'll have a solid market. Memory bandwidth is an issue, but DDR4 will be standard soon enough.
I think AMD is pretty much stuck as far as CPUs go. For gaming they are ok, but modern i3s are better in some instances, and they almost never beat an i5.
As far as GPUs go, they are still competitive, but only on price. The 280 is a great GPUS that isn't too power hungry and provides a nice 3gb with plenty of bandwidth (compared to the cheap 128 bit, 2gb 960.). But they are too power hungry to be competive for high end, or the low power market (750 ti is a beast that destroys thier low power cards). The only reason to buy an AMD card is price and high res gaming, and only the middle of the road cards (280) make sense in the power segment. I can't imagine AMD is making much money off $180 cards.
Kinda sucks for AMD. They provide some innovation and open standards, and are the only thing keeping INTEL/NVIDIA from becoming a monopoly, but they just can't make money. I think they will just stick to value options like the r9 280 and apu's, and eek out a profit every year.
piiman - Saturday, March 7, 2015 - link"Mantle is dead, but at least it started this low level APIA business. "
Pfffffftttttttt! Do you think API's just pop into existence in 6 months? More than likely all three have been in development for years before we even heard of Mantle. How could a proprietary API push anyone?
TEAMSWITCHER - Tuesday, March 3, 2015 - linkAnd if Microsoft and Apple favor their own technologies over Vulcan (DX12 and Metal) then I doubt any of this will ever gain traction with developers.
Flunk - Tuesday, March 3, 2015 - linkI don't think Metal is going to ever gain any traction, we're looking at an Android dominant market right now. The fact that Vulkan will be available on all popular platforms makes it a clear winner for mobile development, it also makes sense on PC if you want to support Windows, Mac and LInux or any combination of those 3.
Guspaz - Tuesday, March 3, 2015 - linkApple's app store still represents significantly more revenue (that is: applications sold) than Android. So the app market is very far from being Android dominated. If you're selling a game, or trying to make any money from a game, then iOS still represents a 60% larger market than Android.
In terms of raw number of applications, only within the last year has Android passed iOS.
It will all boil down to if Apple supports Vulkan. If they do, Metal will fade away. If they don't, it will see heavy use.