Layers and Extensions

Vulkan's layer-based framework allows new functionality and error checking to be added or removed with ease


Vulkan requires a developer to be very explicit in everything they do. This is an intentional design of the API and reduces the driver overhead but is more prone to validity errors as Vulkan does very little error checking of its own.

There are the two main types of errors in Vulkan:
  • Validity errors - these stem from the incorrect usage of the API. This is generally due to the application not following the API rules described in the Vulkan specification document. Normally, the incorrect usage of the API will result in an undefined behaviour which can make it difficult to determine the initial error.
  • Runtime errors - these occur whether the API is used correctly or not. They are errors that take the form of return codes returned from function calls. These return codes point toward a specific issue, for instance running out of memory on allocation of an object.

Despite not catching these errors itself, Vulkan does provide help with application debugging through use of its layer framework. Enabled layers are able to intercept API entry points, evaluating or modifying the called functions before passing them on to the ICDs. This is mentioned in Brief Overview of the Vulkan API. In addition, multiple layers can be chained sequentially to enhance their functionality. These layers are optional components and therefore can be disabled in the final version of the application, reducing the driver overhead.

A particular type of layer, called a validation layers, is able to detect and log validity errors. This is really useful when trying to catch incorrect usage of the API.

An example of these validity errors can be seen when creating and destroying an object in Vulkan. The validation layer will track the object and monitor its lifecycle. If at any time the object is destroyed incorrectly, the validation layer will log the error in the standard output.

Setting up the validation layers is one of the most important first steps when setting a Vulkan application. The next step is defining any required extensions to run the application.


Extensions in Vulkan work similarly to the ones in OpenGL ES. They extend the API’s functionality and may add additional features or commands. They can be used for a variety of purposes, such as providing compatibility for specific hardware.

Extensions can be divided into two types:

  • Instance-level extensions are extensions with global functionality. They affect both the instance-level and device-level commands.
  • Device-level extensions specifically affect the device they are bound to.

Vulkan does not make assumptions about the type of application being developed, as it could just as easily be a compute application as a graphics one. For this reason, some fairly key functionality for graphics applications such as surfaces and swapchains are both considered extensions to the core API. The surface extension (VK_KHR_SURFACE_EXTENSION_NAME) is an instance-level extension, while the swapchain extension (VK_KHR_SWAPCHAIN_EXTENSION_NAME) is a device-level one.