How Is Vulkan Different from Previous Graphics APIs?

Older graphics APIs such as OpenGL were designed when graphics hardware was very different from modern designs, and when a different abstraction model was appropriate. While OpenGL and its mobile equivalent, OpenGL ES, have been able to support additional features by offering extensions and new versions, the basic architecture of these APIs has changed little in the last twenty years. This continuity has allowed long-term support: in general, very old applications will continue to run on modern hardware. The cost of this approach has been that the behaviour of modern GPUs is so abstracted by the API that it is hard for the application and the driver to know each other’s needs. The result is unpredictable performance for the application and considerable complexity in the driver, as each vendor applies different driver optimizations in an attempt to make software run quickly.[1]

Vulkan is designed as an "explicit API". With an API such as OpenGL ES, a driver will handle the complexity of GPU state, manage graphics memory, compile shaders as needed, and perform any synchronization necessary to make the graphics hardware behave as the application expects. In Vulkan, all of these operations are directly under the application’s control; the driver exposes the hardware’s needs and abstracts only the most hardware-specific operations. This adds complexity for the application programmer (who must now handle more variation in device behavior), but it makes the graphics driver much simpler and more predictable. For the developers of premium applications, who spend more time optimizing their software for portability and performance than in basic content creation, Vulkan should reduce overall development time and improve the customer experience. By moving more control to the application, Vulkan reduces the total amount of work that the CPU must do and allows application developers better control over how that work happens.

Vulkan shares a philosophy with recent proprietary graphics APIs and with games console APIs. Each has design differences, but all are intended to give the application authors more console-like levels of control. For small developers who are not limited by the performance of the end-user experience, older APIs such as OpenGL ES may result in less programming work. For those who need the best rendering quality that the hardware can provide, Vulkan gives application authors much more opportunity to make the most of the GPU.

Vulkan is intended to support current graphics hardware, rather than being dependent on future GPU designs. Implementations can expose exactly which features are supported, and platforms can choose a minimum level of support, but at its simplest, Vulkan 1.0 will run on existing hardware designed to implement OpenGL ES 3.1. Optional features allow more advanced functionality up to the level of the latest desktop OpenGL APIs.

1. Nermin Hajdarbegovic. "A Brief Overview Of Vulkan API." Toptal Engineering Blog. 15 Aug. 2015. Web. 11 May 2016.