Some thoughts about the Vulkan API (glNext) and the future of OpenGL
Today the Khronos group announced officially the name of the new cross-plattform 2D/3D and compute API which will be (kind of) the successor of OpenGL. So far it was named “Next Generation OpenGL Initiative” or shorter: “glNext”, the official name will now be Vulkan (btw. the german name for Vulcano).
I read at some places, that it is “OpenGL 5.0” – but I think that this is far from being correct. The Vulkan API is not an improved version on OpenGL (as GL 3 was over GL 2.1) but a new start. It is not compatible with OpenGL. So far for OpenGL compatibility was a huge deal and functions from OpenGL 1.0 (we are talking 1992 here!) are still available in the latest OpenGL Compatibility profile.
Graphics hardware is quickly developing and can be programmed in a very flexible way today. The job of a modern graphics API is to allow the developers full access to this programmable processors in an efficient way. But before around 2001 there was no programmability at all and the graphics APIs job was to control a fixed function co-processor limited to implement some steps of the rendering pipeline. In fact, back in 1992 when OpenGL started out, there weren’t even 3D accelerated graphics cards for consumers at all! Keeping this in mind it is impressive that the same API was able to survive for 23 years just with added functionality but without breaking old code. OpenGL is not only cross-plattform on the PC, but variants also available on phones, game consoles (OpenGL ES) and even the web (WebGL).
In my opinion after such a long time it is time to have a fresh start, because OpenGL got at some placed more complicated and indirect than it could be – just to ensure not breaking any compatibility. It is also hard to parallel the rendering code onto multiple CPU threads, which wasn’t a big deal back in the days of single core CPUs… Not only could it be more pleasant to develop for (we will have to see how nice Vulkan API will be to program), it can also result in a better performance removing some of the layers between to application and the hardware. This also is a chance to add better debugging tools and functions.
As there is no compatibility between OpenGL and the Vulkan API, many large GL code bases will not switch immediately. But older applications will still want to access new hardware features, so I believe that OpenGL is not dead yet, but will in fact live on for some more versions. I’m confident that we will see new hardware features exposed in OpenGL 5.0 (maybe at Siggraph this year?). Just as NVIDIA, AMD and Intel didn’t drop the Compatibility profile even in the latest OpenGL versions, I don’t expect them to drop support for new OpenGL versions any time soon. I guess it’s actually more likely that we will quite some OpenGL extensions which expose more Vulkan like features in OpenGL to help transitioning (e.g. the Vulkan shader “binaries” SPIR-V). Limited compatibility in the other direction at least for the shaders is planned by providing a GLSL to SPIR-V compiler.
I can’t estimate how soon Apple will react to Vulkan. Will they drop Metal in favour of Vulkan on iOS? As Apple is developing the graphics drivers on their own (on iOS and MacOS), they will not want to support two APIs. On the other hand, a slimmer and closer to the metal (and closer to Metal) API will simplify the driver development. So when will Apple switch to Vulkan and not update their OpenGL versions? I expect them to switch sooner or later as Apple is part of the Khronos initiative that created Vulkan.
Vulkan API offers another nice opportunity for OpenGL developers: You can probably implement a full OpenGL stack on top of Vulkan. This offers a way to run OpenGL programs on systems that do not support (newer versions of) OpenGL and also provides a OpenGL stack that behaves the same on all systems (as you deploy it). A program can even at startup time choose between the OpenGL stack provided by the operating system and the one it provides itself in a library based on Vulkan.