Vulkan is a new API for hardware-accelerated graphics (and general computation) via traditional GPUs. OpenGL will continue to be developed, as it is a higher-level API than Vulkan is intended to be. Originally referred to “glNext,” one can infer that Vulkan was likely going to end up being “OpenGL 5,” but that the standards body eventually decided that a new name would better coincide with the relatively clean break the API purports to make from existing OpenGL paradigms.
Vulkan’s practical advantages to game developers are primarily about control (as in, allowing more of it, potentially allowing for better optimizations at the cost of significantly more up-front work on the developer’s part). Specifically:
- The API is oriented around asynchronous generation of command buffers across multiple threads and sequenced processing of those buffers to a command pipeline. This reflects the realities of modern hardware. Most high-profile and/or high-performance software built on OpenGL today implement this kind of behavior themselves; having the API support this itself means that developers need not implement and maintain that framework themselves, or that they can do so with less effort.
- Thread and memory management tasks are left to the application, not the driver, allowing game developers more control over those behaviors and thus potentially more accurate tailoring of those behaviors to their individual game’s needs.
- Validation and diagnostics layers can be independently enabled, allowing in theory for better tools integration with the API (something OpenGL itself has suffered from) and disabling of excessive validation, in theory allowing “the graphics on level three” to be that much more performant.
- There’s no hard API differential between mobile and desktop versions, which will in theory ease the porting of cross-platform games and if nothing else reduce version-checking headaches that everybody hates.
Vulkan’s very C-like / OpenGL-like in superficial structure (the look and feel of the API calls, et cetera. It is, however, better typed (in that not everything is a bare
int; there are relevant typedefs and so on).
It is much lower-level than OpenGL. One can expect a jump in operational setup and complexity between OpenGL and Vulkan as was seen in the D3D9 to D3D10 transition, which exposed a lot more of the under-the-cover details of GPU device operation to the API client. The transition is actually more akin to D3D11 to 12, since D3D12 is itself a very similar API to Vulkan, capability-wise.
To elaborate on OpenGL’s future:
OpenGL might achieve comparable performance to Vulkan, in draw calls per second, but also regarding general driver overhead:
- The most recent OpenGL extensions actually remove a lot of driver overhead by making everything bindless (e.g.
- With persistent mapping (
ARB_buffer_storage, core in 4.4) the buffer memory can be accessed directly by the CPU, thus the synchronization with the GPU is also explicit, just like Vulkan.
- Future extensions such as
NV_command_list(see Tristan Lorach’s Siggraph Asia 2014 presentation) are likely to provide to OpenGL the same “GPU feeding paradigm” as Vulkan.
Khronos recently announced the release of the all-new Vulkan API, which will complement (and in some cases replace) OpenGL and OpenGL ES. Vulkan is a low-overhead API designed to bring code “closer to metal”, boosting performance and efficiency. It is based on AMD’s Mantle API, and the final spec is expected later this year.
In this post – A Brief Overview Of Vulkan API – Toptal Technical Editor Nermin Hajdarbegovic explains why Vulkan could be a big deal in the long run. It may take a while, but this cross-platform API could drastically improve 3D performance on certain devices, especially the multi-core application processors that are used in billions of smartphones and tablets.