Vulkan is intended to be a high-performance API for developers who spend their time trying to get the most out of the system. The largest gains will be seen where the application’s graphics work is limited by the CPU – either in driver overheads or in single-threaded rendering in the application. Vulkan’s ability to spread work across multiple threads, re-use work, and give the application control over scheduling means that it is easier for Vulkan applications to make the most of the GPU’s performance.
While improvements such as better control over memory state and pipeline synchronization and the ability to split work into sub-passes means that the GPU’s work can itself be more efficient, Vulkan cannot magically improve the performance of the GPU. If an application is already limited by GPU (and not driver) performance, for example because it is texture or fragment shader-bound, there is only so much assistance that Vulkan can provide – although the portability advantages of Vulkan remain useful.
Giving the application extra control over the graphics system means that the application developer needs to expend additional effort to do work which was previously in the driver’s remit. For application authors who want this control, this is good news; for developers wanting to get a simple concept to market, this may be a problem. Fortunately, multiple game engine developers are working to support Vulkan, and may offer a low-cost route to getting Vulkan’s performance advantages.
While currently Vulkan requires a lot of programming effort, this situation is expected to improve. The OpenGL and OpenGL ES ecosystems have many helper libraries and samples available. Vulkan’s layer mechanism is intended to offer an explicit way to add support to the API in ways that can simplify application development, but which do not require core modifications. Layers to help simplify memory management and synchronization are obvious examples. Vulkan is a very new API, and its ecosystem is still growing.
Vulkan is intended to be supported on current graphics hardware. However, there is a significant amount of legacy hardware in the field. OpenGL and OpenGL ES are not going away – support for them remains important, and the main means of programming mobile hardware which is too limited to support Vulkan. We can expect Vulkan support to grow rapidly in the future, and form the basis of a new, efficient way of driving graphics for future generations.