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.

SPIR-V

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 A COMMENT

44 Comments

View All Comments

  • piiman - Saturday, March 07, 2015 - link

    If only they had started Mantle before dx12 got started. There is zero evidence Mantle influenced dx12 even a little. Reply
  • StevoLincolnite - Thursday, March 05, 2015 - link

    It really doesn't matter if Mantle was a waste of resources or not.
    It really wouldn't have mattered if Mantle had no game support.
    It really wouldn't have mattered if AMD Cancelled it 6 months ago...

    The job of Mantle was to light the competitive fires underneath Microsoft's and Kronus's lazy laurels to innovate, they did a fantastic job and now... All consumers in the PC space benefit because of it, regardless if you have an Intel, nVidia or AMD Graphics chip. - That's a mightily impressive "Waste of resources".
    Reply
  • MojaMonkey - Saturday, March 14, 2015 - link

    Taking nothing away from Mantle. I'm sure Microsoft's strat of unifying windows and Xbox through Direct X was started many years ago and in similar timescales to Valve and AMD. Reply
  • Vigilant007 - Thursday, March 05, 2015 - link

    Mantle was clearly a stop gap. Whether or not it was a waste of resources I don't think is really clear considering Mantle seems to have given at least a minor boost to Vulkan.

    I doubt we will see this running on actual hardware till probably end of next year, with games supporting it probably right around two years from today.

    Why? Microsoft has no incentive to build in support into Windows. Google's mobile initiatives are so heavily splintered by OEM's that it will probably only be new hardware to actually get the necessary bits in people hands. Apple has always taken their time to support other OpenGL releases. With Metal actually shipping and Apple providing developers with enough tools to make Metal relevant I don't see much benefit for them.

    Vulkan could very well be the future of gaming. It will probably take the same amount of time for Electric cars to be more common place.
    Reply
  • JonnyDough - Friday, March 06, 2015 - link

    Mantle was for AMD's sake so they had a good idea of how to start programming next gen APUs/graphics. Just an FYI. It is for all intents and purposes "similar enough". Reply
  • TheJian - Tuesday, March 03, 2015 - link

    http://www.pcper.com/news/Graphics-Cards/GDC-15-AM...

    As I've stated so many times here, tomshardware etc. Mantle is dead. Vulkan will certainly last longer than Mantle did ;) What a waste of money. They spent a ton probably chasing the idea they could help their low quality cpus, isntead of simply making a CPU IPC monster (sans gpu) to dethrone Intel until they could correct and dedicate a ton more to the meager 5% increases we keep getting from Intel's cpu side.

    I won't hold my breath on how good NOT SO Freesync will be until reviewed heavily this month when monitors hit. AMD would have shown it running tons of games by now if it worked as good as gsync. But we can pray it's good enough to bring down gsync stuff. I continue to have major hate for AMD's MANAGEMENT. Note no hate for the company, it's workers, or the products - just need better management who cares about CORE products or markets they can actually get a foot into). They need a REAL cpu to bring back some mind share, and more attention to their gpu. APU's won't make them a dime with Intel racing down to stop ARM (armada) from coming up the chain. AMD's apu's just get squeezed out of any pricing power.

    They need to quit chasing apu and make a real GPU and CPU killer. Jumping Intel right now with cpu only (as Intel keeps chasing gpu instead of IPC with no pure cpu competition) would allow pricing power as 95% of us gamers just turn off integrated crap and buy a GPU anyway. Again, management is the problem. They have the right engineers to make a great cpu (keller, papermaster etc), but you need to drop the gpu part from it, and dedicate that space to CPU so you can win back gamers (and possibly sell more cards than now to those gamers).

    The ATI purchase at 3x what they should have paid was the start of the downfall (no money left for R&D). Then they compounded the problem by wasted resources on Consoles, which make them nothing unless they get to 7yrs selling great where margins improve. But they'll die due to mobile being good enough this xmas at 14nm (X1's replacement etc will be better than xbox360/ps3 already, and worse next year etc as we see 10nm). Then they did it again on Mantle. Mantle was an API doomed from the start and only a last resort to make up for short comings in the cpu.

    I don't see a product AMD has on the horizon that will bring pricing power unless they have a cpu monster coming. The gpu side seems too power hungry (among other things, is liquid really required?) and likely just have HBM as "blue crystals" so to speak (marketing garbage that helps nothing now). If we needed more bandwidth today, NV wouldn't have went from 384bit bus to 256 and beat their last cards handily. IT will be needed at some point, or something like it, but not the next gen or two probably. HBM will likely raise costs for AMD jumping too soon as a marketing point and again, makes lower profits if the other guy beats you using standard stuff (and if needed going back to 384 etc). I hope AMD gets bought soon. They have some great people still, they just need to be told by management to do something that makes money.
    Reply
  • tuxfool - Tuesday, March 03, 2015 - link

    Did you even read the article? Vulkan is a derivation of mantle. Reply
  • Beany2013 - Tuesday, March 03, 2015 - link

    Read the article? That's not the done thing when you have a rambling, foaming at the mouth diatribe to write! Reply
  • Kutark - Tuesday, March 03, 2015 - link

    Derivation is probably too strong a word, springboard might be more proper. Reply
  • blaktron - Tuesday, March 03, 2015 - link

    Thank goodness you don't run a major electronics firm with actual investors and shareholders. Reply

Log in

Don't have an account? Sign up now