khronos-Vulkan

OpenGL will live long and prosper,  or at least that’s what the Khronos Group’s hope is for their next-generation API to rival DirectX and Apple’s Metal. The Khronos Group finally settled on Vulkan as the name for their next generation API. Vulkan is the German translation for “volcano” and it is particularly apt because Vulkan, as the world has now discovered, is basically the open-source version of AMD’s Mantle API. Its unknown at this point how much of Mantle is inside Vulkan, but Khronos admits that it is “more than you would think.” So what’s cooking inside Vulkan and why should you be interested in it? Hit the jump for more. 

Firstly, why call it Vulkan? Khronos isn’t saying much about the name choice because they had a poll a while back for people to pick or suggest a name for their new API, which a few weeks ago was simply called OpenGL Next or glNext. It hasn’t been a secret that the group has been borrowing code from Mantle for quite some time – in fact, it was as little as a year ago that they got into bed with AMD to improve the low-API nature of glNext. According to Khronos, both Vulkan and Mantle are capable of mostly the same things and they are also aimed at the same goal – multi-platform support for a low-overhead API that gives Khronos and developers a fresh start.

Thus, if Mantle was the catalyst to get the low-API ball rolling and get people interested in it, Vulkan will be the exploding volcano that will finally erupt on the industry and rain hellfire on all its enemies, engulfing towns and cities with fire and ash and burning and… – no I’m just kidding, its just an open-source API that will open the floodgates for people to tinker with it and improve it as the open-source community always does.

Its quite a feather in the cap for AMD because they have almost stuck to their promises of getting Mantle off the ground (and if they planned all along to rework Mantle into Vulkan, then they succeeded). Though there will not be a public SDK release for Mantle this year (or ever, if I’m right), AMD has said that developers should be moving to working with DirectX 12 or other low-overheard APIs of a similar nature. Mantle may have just been a very early version of what would become Vulkan without anyone outside of that inner developer’s circle knowing about it. Like Mantle, it’ll greatly increase CPU performance by improving multi-threading and, also like Mantle, it increases draw call batch limits way more than was previously possible , although OpenGL did provide methods to increase draw calls already. The years of bloat, however, have not been kind to it.

But while Mantle gets usurped by Vulkan, it will continue on with other game engines and AMD will still be maintaining it as they already have been for the handful of games that currently make us of it. Mantle isn’t a dead end for AMD, just merely a stepping stone that they will continue to make use of to get people into the mindset of making games on a low-level API. Many of the things that Mantle has been trying to do has resulted in positive improvements for gamers – split-screen rendering makes a return and we can finally use individual VRAM pools on multiple GPUs in a system to do and hold different sets of data.

At this stage, people are also now looking at Apple’s Metal and wondering why they came up with that name. You need extreme heat and pressure to create metal, right? What if their API is called Metal because they compress texture sizes to fractions of the originals to increase effective bandwidth, and turn up the heat by increasing performance and framerates? Maybe, that all sounded better in my head. Still, I expect Apple to reveal at some point that Metal is based on the work done in Mantle and Vulkan.

khronos-vulkan-commandbuffer-slide

Like a lot of low-level APIs being released this year, Vulkan will improve multi-threading by using the other CPU cores as command buffers. What this means is that the system will queue up work for the GPU to do in a command queue and it will intelligently load up the queue with new instructions from the command buffer in parallel, if the workload allows for that level of use. This means that instead of a game like Assassin’s Creed Unity (based on DirectX 11) drawing separate elements of the game in a queue, it can be calculated and drawn all at once, provided the GPU is sufficiently fast enough to do so smoothly. Like Mantle and DirectX 12, Vulkan also reduces GPU driver driver overhead to improve overall performance.

khronos-vulkan-flowchart

There is a fundamental change from how Mantle behaves, however. Mantle’s selling point was that it could understand Microsoft’s shader language that they developed for DirectX, called the High-Level Shader Language (HLSL), so any existing project that was already targeting DirectX could be forked to provide Mantle support at the same time without deviating too much from the pre-set deadlines. This allowed Mantle to work directly with the existing shader code, and all the work instead went into performance optimisation and just plain making things work.

Vulkan does it very differently. It can work with GLSL shaders (which is what OpenGL understands) and Khronos is planning to create a translator to turn any shader code like GLSL into something called SPIR-V. SPIR-V is another shader language that Vulkan can understand, but it isn’t just made for Vulkan, as it will include and present data that isn’t GPU-related at all to other APIs. SPIR-V’s role together with the translator is like taking a drawing (the shader code) and describing it in English, then translating that English into something appropriate for your hardware to understand. Together with Vulkan, it will target hardware found in both desktop and mobile markets, and will also be one of the data delivery mechanisms for OpenCL, because OpenCL 2.1 will be able to understand it.

In the future, Khronos group will be working on a translator for HLSL as well as any translators that may be needed to port over andf compile shaders for mobile applications.

khornos-fiveapis

Despite Vulkan being much more advanced and cutting-edge than OpenGL, Khronos will continue developing and improving the rest of the standards they maintain for other platforms and uses. With enough time on their hands, SPIR-V will be compatible with OpenGL and GL|ES and they will continue to offer OpenGL as an API for anyone who doesn’t want to deal with the complexities of running Vulkan. Because all of their APIs are also able to be run on multiple platforms, this puts Khronos in a unique position because while they have a separate solution for most, if not all, graphical or compute requirements, its almost a code-once-run-anywhere type of gig thanks to SPIR-V. It will be interesting to see where this progresses and how closely Khronos group will work with other Linux developers and Valve to get Vulkan in to the market as fast as possible.

Vulkan is already supported by Source 2

If you didn’t already know about the Source 2 announcement, you can catch up on that here. While Source 2 is already a huge advancement for the industry because its another engine that will be initially free to developers, it also already has support for AMD’s Mantle and Vulkan. Check out this demo at GDC 2015 by Valve’s Pierre-Loup Griffais of DOTA 2 running on Intel HD4600 integrated graphics using Vulkan on the Source 2 engine. Yes, Intel is one of the partners for Vulkan and its going to be very interesting to see how quickly Nvidia embraces it, if at all. Support from AMD is basically a no-brainer at this point in time.

Are you a game developer excited for the possibilities that Vulkan brings to you? Are you excited for Source 2? Do you want to go play some more DOTA2 RIGHT NOW after watching that video? Let us know in the comments below.

More stuff like this: