As there have been lots of new information on Vulkan, Khronos’ new graphics and compute API I decided to do a little write up of the new API from a hobby 3D developer’s point of view.
Although I’ve been writing games, demos and applications with OpenGL for roughly 15 years now I still consider myself a hobby developer in terms of 3D graphics. My job is not depending on pushing pixels, maxing out draw calls or swizzling shader commands, and most of my work on 3D (primarily OpenGL) is done during my spare time (mostly late at night).
During this years SIGGRAPH and GamesCom, Khronos showed off some stuff related to Vulkan (LunarG e.g. uploaded a video of LunarXChange, the developer platform for Vulkan) and several IHVs (e.g. PowerVR) and ISVs demoed applications and implementations.
And while it’s still a way to go before Vulkan is released to the public (should be by the end of the years) I’d like to write down a few words on the new API for hobby (OpenGL) developers that may be uncertain on whether to switch or not, or even on what Vulkan actually is.
(That’s what graphics developers want. All CPU cores feeding data to the GPU)
It won’t replace OpenGL (ES)
Vulkan is a new high performance graphics and compute API to compete with DirectX 12 and Metal. It won’t replace OpenGL, though it was often refered to as “glNext”. The OpenGL ecosystem, including OpenGL ES is still alive and will benefit from years of driver optimizations and will continue to be extended by new versions and extension. Khronos recently announced 14 new OpenGL extensions and a new OpenGL ES version.
OpenGL, OpenGL ES, WebGL and Vulkan will therefore co-exist, at least for the time being. I don’t think any IHV (or ISV) will be dropping support for the “old” APIs in favor of Vulkan. Most engines e.g. will get an additional Vulkan renderer.
It targets desktop and mobile
Google recently announced support for Vulkan on Android, so the API will be the same for desktop and mobile. So if you’re doing multi platform stuff and use C++ on mobile you don’t have to write separate render paths for OpenGL and OpenGL ES anymore. And no, the API won’t be handicapped by supporting mobile and desktop GPUs, as it targets only modern GPUs.
It’s not AMD’s Mantle (but has lots in common)
Yes, it’s based on AMD’s Mantle (and the principles behind Mantle) and AMD was so kind of basically handing Mantle over as a basis for Vulkan to Khronos (and LunarG). While it’s a great idea to read the Mantle Programming Guide and API Reference if you want to know more about Vulkan’s workings and basic concepts, it’s not the same. Mantle was a single vendor API that was pretty much tailored onto AMD’s GCN GPU architecture and was never really intended for public use. Vulkan will have wide support for different GPU vendors and architectures and the API will be used by a much broader audience. So it’s not just a Mantle with function name prefixes replaced, you should expect differences in API naming and in terms of functionality and extensions.
It’s a fundamentally different (and new) API
If you’ve taken a look at the Mantle guide I posted above you may have expected this. The API and all the concepts are fundamentally different. Sure, stuff like vertex. uniform, shader storage buffers and the different shader types are still there, but compared to the OpenGL you’re used to it will be fundamentally different. Switching from OpenGL to Vulkan as a hobby developer won’t be easy because of this, and the fact that you’re going to do all the GPU memory and resource management by yourself. You’re going to deal with descriptor sets, layouts, persistent state objects, etc. that aren’t present in OpenGL. But on the other hand you’ll get a new and clean API with much less clutter than the current OpenGL. Although It depends on your experience with 3D APIs, if you haven’t worked with another modern 3D API yet it wont’ be easy to switch over from OpenGL. If you had troubles switching from intermediate OpenGL to modern (shader based) OpenGL back in the days, this will be even harder.
There will be extensions
Just like OpenGL and Mantle, Vulkan will also be extended over the years to support new GPU functionality. So Vulkan will also have an extension mechanism too that should be a bit cleaner than the one from OpenGL, i.e. extensions will have to be activated upon creating your instances.
No more state machine
When OpenGL was released, the hardware landscape was pretty different compared to now. GPUs made huge advances over the last decades (I still own a working S3 ViRGE to prove this ;) ) and while a state machine (that was once small and is now huge thanks to all the OpenGL versions and extensions) seemed like a good idea back then it’s no longer state of the art and was especially bad for the OpenGL drivers. So there won’t be a GL-like state machine in Vulkan anymore. While it’s a huge departure from OpenGL it’s a very welcome one. Instead of pulling levers on a huge state machine you well define e.g. your rendering pipeline (or several if you need to switch) once, allowing the GPU an efficient way of optimizing, storing and accessing it whenever it needs to be accessed.
It won’t magically speed up your rendering
Don’t expect your single threaded renderer to be much faster after switching from OpenGL over to Vulkan (unless it’s ancient and using OpenGL immediate mode). Vulkan is all about getting rid of CPU bottlenecks often caused by driver overhead when rendering complex scenes (aka “I can haz more drawcalls plz?”). So if you want the performance gains possible with Vulkan you need to go all in on multi threaded resource management. Benefits on single threaded renderer with only few dynamic object allocations will be noticeable (due to the lower general CPU overhead), but won’t be as big. If you’re not familiar with concepts like “command buffers” I recommend on watching e.g. NVIDIA’s slides on “Approaching zero driver overhead”. It’ll surely come in handy if you plan on playing around with Vulkan and realizing why and how you can speed up rendering using multiple threads. Another great read is “GPU-Driven large scene rendering”, also by NVIDIA.
It’s (all) about the draw calls
Pretty much everything in the life of a modern graphics programmer is about the draw calls. You want to sell your car to a 3D engine dev? Tell him it makes millions of drawcalls per mile ;) Complex scenery is often made up of thousands (or millions) of draw calls. With OpenGL, draw calls are pretty expensive (mostly due to driver overhead). Just like DirectX 12, Vulkan eliminates most of the CPU and driver overhead, thus allowing far more draw calls than OpenGL. Expect a ten fold increase in draw call performance.
You’re going to manage GPU memory and resources yourself
OpenGL did a pretty “good” job at hiding away all the memory and resource management stuff on the GPU side from the API user. Like with the other modern 3D APIs this will become explicit with Vulkan, so instead of the driver, memory management is done by the programmer. But you’re managing your CPU-side memory and resources by yourself already, aren’t you? With Vulkan you’ll also manage GPU resources and memory. It adds some more effort, and is something to be considered before switching from OpenGL. Once again it’s a good idea to take a look at the Mantle Programming guide I posted early.
You’ll no longer upload human readable shaders
Shaders in Vulkan will be stored using SPIR-V (Standard Portable Immediate Representation) (Whitepaper), a binary high-level intermediate representation of your shaders converted from GLSL that can be directly feed to the GPU. This removes the need for shader compilers in drivers, and everyone that has tried to get complex GLSL shaders up and running across various vendors know that runtime compilation of shaders caused lots of troubles. SPIR-V eliminates that problem thanks to a standardized immediate binary representation of your shaders that’s no longer depending on shader compilers inside the driver. Great for the API user and also great for hardware vendors. You’re still going to write your shaders using GLSL, but you won’t have to release them along your application. You rather use tools provided by the Vulkan SDK that convert your GLSL shaders to SPIR-V and pass these binary files along with your app instead of the human readable text shaders. If you don’t know about Khronos’ reference glslang compiler, you should now take a look at it ;)
You don’t need a new (or updated) operating system
Vulkan support won’t (usually) be provided by the operating system, but will be delivered through the graphics drivers. So no need for Microsoft to patch up Windows. A GPU driver supporting Vulkan is enough. This is a real advantage over Mantle (only one vendor) and especially DirectX 12, which MS won’t support for older Windows versions. In theory, Vulkan support could even be provided for Windows XP. Expect support for Windows (7 and up), lots of linux distributions and mobile platforms like Android and Tizen upon launch. All with the same API :)
So what’s the verdict (as a hobby developer)?
If your main goal is to display your 3D stuff (e.g. using OpenGL) for your hobby games or demos and yout don’t need to squeeze out as much draw calls as possible, you probably won’t gain anything by moving from OpenGL (ES) to Vulkan. Porting your current (mostly single threaded) renderer (that isn’t creating many resources dynamically) to Vulkan wont’ net you a huge performance boost but will have you spent hours adopting to the new API and doing all the memory and resource allocation by yourself.
If you’re more about using the latest 3D techniques and can’t keep calm when reading up on the latest and newest OpenGL extensions, then yes, go ahead and switch to Vulkan, even if you’re only doing 3D development as your hobby. A new, nice and clean API is always great to work with, and the experience you gain when switching from an established rendering API to a new (and shiny) API based on modern GPU architectures is worth the effort.
And if you haven’t used OpenGL yet but you want to start off doing 3D development in the future then it pretty much depends on your programming experience. If you’re used to dynamically allocation stuff during runtime and managing all the resources by yourself, Vulkan may be right for you. The API is very clean and leaves the whole management stuff to the developer. OpenGL on the other hand benefits from mature implementations that have been optimized over the years, but the API is pretty cluttered. Only using “modern” OpenGL with stuff like AZDO and DSA mitigates this a bit though, but if you start with OpenGL there are usually several ways of implementing a feature or functionality, so it can become a bit confusing. Alas this one is not easy, but if you start off with 3D programming, it could be great idea to begin with a modern API that’s based on modern GPU architectures rather than an aged API that went through many iterations.
If you want to chime in on the discussion for Vulkan, or got questions regarding the new API. Khronos also offers a Vulkan forum.
Am I going to switch over to Vulkan?
Yes, definitely :) My days of coding big games, which are more about the content than the technology are pretty much over (it’s hard to work on huge projects when you code 8h+ daily for a living) and I totally enjoy getting my head into new technologies. No matter if it’s the latest OpenGL extension or a new open API by the people behind OpenGL.
So expect some Vulkan demos (and maybe tutorials) once it’s getting released, but also expect me to also continue working with OpenGL ;)