The Future of OpenGL
The obvious solution then is to simply create a new version of OpenGL with the same design goals as these newer closer-tothe- metal APIs, while remaining vendor and platform-neutral as it is now. Many developers working with OpenGL have talked about the many issues faced by them in OpenGL, and the need for a clean break, an entirely new graphics API developed using the same open approach as OpenGL, but built for modern graphics chipset architectures, and with modern graphics development in mind. This is exactly what was happening under the umbrella of the glNext project.
Also revealed was the fact that while Vulkan was to be the successor to OpenGL, it does not share its legacy. In fact Vulkan is to a large extent based on AMD’s Mantle graphics API, which AMD graciously contributed to the Khronos Group. This is rather a generous move of AMD given how it will now become a vendor-neutral and platform-neutral framework under Khronos, thus eliminating any competitive advantage they had through a vendor locked framework. To be honest though Mantle was unlikely to succeed as an AMD-only Windows only technology, especially given the similar goals of DirectX 12.
So while Vulkan is a successor to OpenGL, it is also the successor to AMD Mantle. Given the existence of Vulkan, Mantle will no longer exist in its current form since it has essentially been
superseded. The landscape of graphics API has suddenly cleared a lot, it is now down to three, Metal by Apple, DirectX 12 by Microsoft, and Vulkan by the Khronos Group.
Unlike Microsoft and Apple, the Khronos Group is a non-profit consortium that is focused entirely on creating open graphics standards. Apple and Microsoft are member of Khronos as well though among other major game development and hardware companies such as AMD, Intel, NVIDIA, Valve, Unity, EPIC Games, Blizzard, EA, Google, Mozilla, Oxide, PIXAR, and Oculus VR and many others.
If you think it odd that a new major standard API is based on a technology created by a single corporation for its own use, perish the thought. This is exactly how OpenGL started in the first place. OpenGL was a successor to IRISGL (Integrated Raster Imaging System Graphics Library), which was a creation of Silicon Graphics (SGI) designed for their own workstations. It was eventually open sourced and standardised as OpenGL.
What Vulkan Brings to the Table
One of the biggest advantage that Vulkan has over other graphics APIs is the fact that it is designed to work on all platforms, desktop or mobile, and operating systems. It can work with NVIDIA hardware, AMD hardware, and Intel hardware, and other graphics hardware available on mobile platforms such as Adreno.
This, of course, is something OpenGL already does, and very important for Vulkan being a fresh API. Where Vulkan is intended to excel, is where some of the biggest drawbacks lie in OpenGL currently. It is designed to take advantage of the current generations’ architectures, and trends in hardware architectures that are here to stay. When OpenGL was designed, both CPUs and GPUs were single-core affairs.
The trend these days is towards higher core counts at lower speeds. Octa-core mobile processors are increasingly common and are getting cheaper. Desktop and laptop core counts are also on the rise. We’ve already mentioned how the number of GPU cores had been on the rise, and is now in the territory of 16 physical cores and hundreds or even thousands of virtual cores.
Multi-threaded design
These trends do not play well with the way OpenGL is designed. While OpenGL-based games and applications can take advantage of multiple cores, all OpenGL interactions only run in a single thread. What this means is that even if the rest of the application code is spread across multiple processors, the speed of a single core defines how fast OpenGL can process graphics commands and pass them to the GPU. Vulkan is explicitly designed to take advantage of multiple cores. It supports receiving commands from multiple threads at the same time allowing for better utilisation of multicore hardware.
This is a design that has been proven to show performance gains since EA’s Frostbite 3 engine (which powers all their modern games such as the newest Dragon Age: Inquisition and Battlefield 4) was ported to use Mantle, and showed real world improvements in performance to as much as 45%.
Lower driver overhead
Current graphics drivers do a lot, too much if you ask the developers of Vulkan. One of the goals of Vulkan then is to reduce how much management OpenGL does, and leave all that for the engine developer to handle.
Vulkan gives developers explicit control over the GPU, and removes everything but the most necessary components between the GPU and the software using it. This increase in power, also brings with an increase in responsibility. Low-level features such as memory management, error validation and CPU-GPU synchronization are now the responsibility of the developer. Vulkan even removes run-time error checking that was done by OpenGL. The idea behind this being that all the testing should be done beforehand, so error-checking need not run in production code. Also, despite error checking, GPU crashes are known to happen, so why pay with the overhead?
To help developers ship error-free code, Vulkan will ship with good tools to properly test the application during development. Vulkan, unlike OpenGL will ship with a full SDK.
Layered design
Some of the OpenGL features that have been removed in Vulkan are now available as additional layers over the core driver. For instance, there are layers available for validation, reference counting, debugging, checking for thread safety, trace capture and replay, and performance linting.
In Vulkan, disabled layers do not use up any CPU or GPU
layer if needed. Third parties can create their own layers. For instance Steam’s overlay that shows game information can be implemented as a Vulkan layer.
Bytecode Shaders
Shaders are one of the most important bits of GPU code while developing games but their current design leaves a lot to be desired. Currently there are two main languages to create shaders GLSL (for OpenGL) and HLSL (for DirectX).
Developers wanting to target both OpenGL and DirectX need to create the same shader code in both languages and ship them with the game. This leads to a duplication of effort in keeping two ver- sions of the same code in sync. Or use automated code-conversion tools to output code in these languages. Game developers also need to ship the source code of their shaders, which are then compiled by the graphics drivers at run time before being sent to the GPU. Not only does this cost in performance, it also causes issues for companies that want to keep their code private.
With Vulkan comes a new binary shader format called SPIR-V. This is a bytecode format that can be compiled to run on any GPU. Since it is a bytecode format, it removes the need for a full compiler in the driver, and reduces the performance impact of compiling shaders at run time. Also companies that want to keep their shaders private can now do so.
Of course developers wont directly write shaders in this binary format. Rather the idea is to support multiple source languages, which can all be compiled to the SPIR-V format. Game developers can use the language of their choice, GLSL, HLSL, or some other language entirely – such as Apple’s new Metal shader language. As long as there is a compiler for it that
outputs SPIR-V.
Conclusion
Thanks to AMD’s donation of Mantle, Vulkan is well on its way to becoming a reality soon. EA’s Frostbite 3 engine, already supports Mantle, and EA has committed to port it to Vulkan. Valve’s Source 2 engine already supports Vulkan alpha, and their Steam Machines will also support Vulkan. Valve has also (in partnership with LunarG) developed a driver for Intel GPUs that supports Vulkan and will be kept in sync with the latest Vulkan specifications.
This driver will be open sourced. The Vulkan spec and drivers should be available this year
itself, and the spec for SPIR-V is already available. A compiler for GLSL to SPIR-V is also available, and SPIR-V is supported by the newest OpenCL.
It will be interesting to see how major game companies, platform holders and vendors get behind Vulkan and (if at all) current generation consoles also take to Vulkan, but in the words of Valve’s John McDonald, “Outlook good?”.
