Learning the Vulkan API? Check out this overview of Vulkan Loader and Layers.
Vulkan is a layered architecture, made up of the following elements: 1) The Vulkan Application, 2) The Vulkan Loader, 3) Vulkan Layers, and 4) Installable Client Drivers (ICDs).
While this tutorial is primarily targeted at developers of Vulkan applications, drivers, and layers, the information contained in it could be useful to anyone wanting a better understanding of the Vulkan runtime. These general concepts are applicable to the loaders available for Windows-, Linux-, and Android-based systems.
The Loader
The application sits on one end of, and interfaces directly with, the loader. On the other end of the loader from the application are the ICDs, which control the Vulkan-capable hardware. An important point to remember is that Vulkan-capable hardware can be graphics-based, compute-based, or both. Between the application and the ICDs the loader can inject a number of optional layers that provide special functionality.
The loader is responsible for working with the various layers as well as supporting multiple GPUs and their drivers. Any Vulkan function may wind up calling into a diverse set of modules: loader, layers, and ICDs. The loader is critical to managing the proper dispatching of Vulkan functions to the appropriate set of layers and ICDs. The Vulkan object model allows the loader to insert layers into a call chain so that the layers can process Vulkan functions prior to the ICD being called.
This tutorial is intended to provide an overview of the necessary interfaces between each of these.
Goals of the Loader
The loader was designed with the following goals in mind.
- Support one or more Vulkan-capable ICDs on a user’s computer system without interference between them.
- Support Vulkan Layers, which are optional modules that can be enabled by an application, developer, or standard system settings.
- Minimize overall performance impact to a Vulkan application.
Layers
Layers are optional components that augment the Vulkan system. They can intercept, evaluate, and modify existing Vulkan functions on their way from the application down to the hardware. Layers are implemented as libraries that can be enabled in different ways (including by application request) and are loaded during CreateInstance. Each layer can choose to hook (intercept) any Vulkan functions which in turn can be ignored or augmented. A layer does not need to intercept all Vulkan functions. It may choose to intercept all known functions, or, it may choose to intercept only one function.
Some examples of features that layers may expose include:
- Validating API usage
- Adding the ability to perform Vulkan API tracing and debugging
- Overlaying additional content on the application’s surfaces
Because layers are optional, you may choose to enable layers for debugging your application, but then disable any layer usage when you release your product.
Read more information about the Vulkan loader and layers [here].
