[![Khronos Vulkan][1]][2] [1]: https://vulkan.lunarg.com/img/Vulkan_100px_Dec16.png "https://www.khronos.org/vulkan/" [2]: https://www.khronos.org/vulkan/ # Architecture of the Vulkan Loader Interfaces [![Creative Commons][3]][4] [3]: https://i.creativecommons.org/l/by-nd/4.0/88x31.png "Creative Commons License" [4]: https://creativecommons.org/licenses/by-nd/4.0/ ## Table of Contents - [Overview](#overview) - [Who Should Read This Document](#who-should-read-this-document) - [The Loader](#the-loader) - [Goals of the Loader](#goals-of-the-loader) - [Layers](#layers) - [Drivers](#drivers) - [Installable Client Drivers](#installable-client-drivers) - [VkConfig](#vkconfig) - [Important Vulkan Concepts](#important-vulkan-concepts) - [Instance Versus Device](#instance-versus-device) - [Instance-Specific](#instance-specific) - [Instance Objects](#instance-objects) - [Instance Functions](#instance-functions) - [Instance Extensions](#instance-extensions) - [Device-Specific](#device-specific) - [Device Objects](#device-objects) - [Device Functions](#device-functions) - [Device Extensions](#device-extensions) - [Dispatch Tables and Call Chains](#dispatch-tables-and-call-chains) - [Instance Call Chain Example](#instance-call-chain-example) - [Device Call Chain Example](#device-call-chain-example) - [Elevated Privilege Caveats](#elevated-privilege-caveats) - [Application Interface to the Loader](#application-interface-to-the-loader) - [Layer Interface with the Loader](#layer-interface-with-the-loader) - [Driver Interface With the Loader](#driver-interface-with-the-loader) - [Debugging Issues](#debugging-issues) - [Loader Policies](#loader-policies) - [Filter Environment Variable Behaviors](#filter-environment-variable-behaviors) - [Comparison Strings](#comparison-strings) - [Comma-Delimited Lists](#comma-delimited-lists) - [Globs](#globs) - [Case-Insensitive](#case-insensitive) - [Environment Variable Priority](#environment-variable-priority) - [Table of Debug Environment Variables](#table-of-debug-environment-variables) - [Glossary of Terms](#glossary-of-terms) ## Overview Vulkan is a layered architecture, made up of the following elements: * The Vulkan Application * [The Vulkan Loader](#the-loader) * [Vulkan Layers](#layers) * [Drivers](#drivers) * [VkConfig](#vkconfig) ![High Level View of Loader](./images/high_level_loader.png) The general concepts in this document are applicable to the loaders available for Windows, Linux, Android, and macOS systems. ### Who Should Read This Document While this document 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. ### The Loader The application sits at the top and interfaces directly with the Vulkan loader. At the bottom of the stack sits the drivers. A driver can control one or more physical devices capable of rendering Vulkan, implement a conversion from Vulkan into a native graphics API (like [MoltenVk](https://github.com/KhronosGroup/MoltenVK), or implement a fully software path that can be executed on a CPU to simulate a Vulkan device (like [SwiftShader](https://github.com/google/swiftshader) or LavaPipe). Remember, Vulkan-capable hardware may be graphics-based, compute-based, or both. Between the application and the drivers, the loader can inject any number of optional [layers](#layers) that provide special functionality. The loader is critical to managing the proper dispatching of Vulkan functions to the appropriate set of layers and drivers. 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 driver being called. This document 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: 1. Support one or more Vulkan-capable drivers on a user's system without them interfering with one another. 2. Support Vulkan Layers which are optional modules that can be enabled by an application, developer, or standard system settings. 3. Keep the overall overhead of the loader to the minimum possible. ### Layers Layers are optional components that augment the Vulkan development environment. They can intercept, evaluate, and modify existing Vulkan functions on their way from the application down to the drivers and back up. Layers are implemented as libraries that can be enabled in different ways and are loaded during CreateInstance. Each layer can choose to hook, or intercept, Vulkan functions which in turn can be ignored, inspected, or augmented. Any function a layer does not hook is simply skipped for that layer and the control flow will simply continue on to the next supporting layer or driver. Because of this, a layer can choose whether to intercept all known Vulkan functions or only a subset it is interested in. Some examples of features that layers may expose include: * Validating API usage * Tracing API calls * Debugging aids * Profiling * Overlay Because layers are optional and dynamically loaded, they can be enabled and disabled as desired. For example, while developing and debugging an application, enabling certain layers can assist in making sure it properly uses the Vulkan API. But when releasing the application, those layers are unnecessary and thus won't be enabled, increasing the speed of the application. ### Drivers The library that implements Vulkan, either through supporting a physical hardware device directly, converting Vulkan commands into native graphics commands, or simulating Vulkan through software, is considered "a driver". The most common type of driver is still the Installable Client Driver (or ICD). The loader is responsible for discovering available Vulkan drivers on the system. Given a list of available drivers, the loader can enumerate all the available physical devices and provide this information for an application. #### Installable Client Drivers Vulkan allows multiple ICDs each supporting one or more devices. Each of these devices is represented by a Vulkan `VkPhysicalDevice` object. The loader is responsible for discovering available Vulkan ICDs via the standard driver search on the system. ### VkConfig VkConfig is a tool LunarG has developed to assist with modifying the Vulkan environment on the local system. It can be used to find layers, enable them, change layer settings, and other useful features. VkConfig can be found by either installing the [Vulkan SDK](https://vulkan.lunarg.com/) or by building the source out of the [LunarG VulkanTools GitHub Repo](https://github.com/LunarG/VulkanTools). VkConfig generates three outputs, two of which work with the Vulkan loader and layers. These outputs are: * The Vulkan Override Layer * The Vulkan Layer Settings File * VkConfig Configuration Settings These files are found in different locations based on your platform:
Platform | Output | Location |
---|---|---|
Linux | Vulkan Override Layer | $USER/.local/share/vulkan/implicit_layer.d/VkLayer_override.json |
Vulkan Layer Settings | $USER/.local/share/vulkan/settings.d/vk_layer_settings.txt | |
VkConfig Configuration Settings | $USER/.local/share/vulkan/settings.d/vk_layer_settings.txt | |
Windows | Vulkan Override Layer | %HOME%\AppData\Local\LunarG\vkconfig\override\VkLayerOverride.json |
Vulkan Layer Settings | (registry) HKEY_CURRENT_USER\Software\Khronos\Vulkan\Settings | |
VkConfig Configuration Settings | (registry) HKEY_CURRENT_USER\Software\LunarG\vkconfig |
Environment Variable | Behavior | Restrictions | Example Format |
---|---|---|---|
VK_ADD_DRIVER_FILES |
Provide a list of additional driver JSON files that the loader will use
in addition to the drivers that the loader would find normally.
The list of drivers will be added first, prior to the list of drivers
that would be found normally.
The value contains a list of delimited full path listings to
driver JSON Manifest files. |
If a global path to the JSON file is not used, issues may be encountered.
Ignored when running Vulkan application with elevated privileges. |
export VK_ADD_DRIVER_FILES= set VK_ADD_DRIVER_FILES= |
VK_ADD_LAYER_PATH | Provide a list of additional paths that the loader will use to search for layers in addition to the loader's standard Layer library search folder when looking for explicit layer manifest files. The paths will be added first, prior to the list of folders that would be searched normally. | Ignored when running Vulkan application with elevated privileges. |
export VK_ADD_LAYER_PATH= <path_a>:<path_b> set VK_ADD_LAYER_PATH= <path_a>;<path_b> |
VK_DRIVER_FILES |
Force the loader to use the specific driver JSON files.
The value contains a list of delimited full path listings to
driver JSON Manifest files. This has replaced the older deprecated environment variable VK_ICD_FILENAMES, however the older environment variable will continue to work for some time. |
If a global path to the JSON file is not used, issues may be encountered.
Ignored when running Vulkan application with elevated privileges. |
export VK_DRIVER_FILES= set VK_DRIVER_FILES= |
VK_LAYER_PATH | Override the loader's standard Layer library search folders and use the provided delimited file and/or folders to locate explicit layer manifest files. | Ignored when running Vulkan application with elevated privileges. |
export VK_LAYER_PATH= <path_a>:<path_b> set VK_LAYER_PATH= <path_a>;<path_b> |
VK_LOADER_DEBUG |
Enable loader debug messages using a comma-delimited list of level
options. These options are: * error (only errors) * warn (only warnings) * info (only info) * debug (only debug) * layer (layer-specific output) * driver (driver-specific output) * all (report out all messages) To enable multiple options (outside of "all") like info, warning and error messages, set the value to "error,warn,info". |
None |
export VK_LOADER_DEBUG=all set VK_LOADER_DEBUG=warn |
VK_LOADER_DEVICE_SELECT |
Allows the user to force a particular device to be prioritized above all
other devices in the return order of vkGetPhysicalDevices and
vkGetPhysicalDeviceGroups functions. The value should be " NOTE: This DOES NOT REMOVE devices from the list on reorders them. |
Linux Only | set VK_LOADER_DEVICE_SELECT=0x10de:0x1f91 |
VK_LOADER_DISABLE_SELECT |
Allows the user to disable the consistent sorting algorithm run in the
loader before returning the set of physical devices to layers. |
Linux Only | set VK_LOADER_DISABLE_SELECT=1 |
VK_LOADER_DISABLE_INST_EXT_FILTER |
Disable the filtering out of instance extensions that the loader doesn't
know about.
This will allow applications to enable instance extensions exposed by
drivers but that the loader has no support for. |
Use Wisely! This may cause the loader or application to crash. |
export VK_LOADER_DISABLE_INST_EXT_FILTER=1 set VK_LOADER_DISABLE_INST_EXT_FILTER=1 |
VK_LOADER_DRIVERS_SELECT |
A comma-delimited list of globs to search for in known drivers and
used to select only the drivers whose manifest file names match one or
more of the provided globs. Since drivers don’t have a name like layers, this glob is used to compare against the manifest filename. Known driver manifests being those files that are already found by the loader taking into account default search paths and other environment variables (like VK_ICD_FILENAMES or VK_ADD_DRIVER_FILES). |
This functionality is only available with Loaders built with version
1.3.234 of the Vulkan headers and later. If no drivers are found with a manifest filename that matches any of the provided globs, then no driver is enabled and it may result in Vulkan applications failing to run properly. |
export VK_LOADER_DRIVERS_SELECT=nvidia set VK_LOADER_DRIVERS_SELECT=nvidia The above would select only the Nvidia driver if it was present on the system and already visible to the loader. |
VK_LOADER_DRIVERS_DISABLE |
A comma-delimited list of globs to search for in known drivers and
used to disable only the drivers whose manifest file names match one or
more of the provided globs. Since drivers don’t have a name like layers, this glob is used to compare against the manifest filename. Known driver manifests being those files that are already found by the loader taking into account default search paths and other environment variables (like VK_ICD_FILENAMES or VK_ADD_DRIVER_FILES). |
This functionality is only available with Loaders built with version
1.3.234 of the Vulkan headers and later. If all available drivers are disabled using this environment variable, then no drivers will be found by the loader and will result in Vulkan applications failing to run properly. This is also checked before other driver environment variables (such as VK_LOADER_DRIVERS_SELECT) so that a user may easily disable all drivers and then selectively re-enable individual drivers using the enable environment variable. |
export VK_LOADER_DRIVERS_DISABLE=*amd*,*intel* set VK_LOADER_DRIVERS_DISABLE=*amd*,*intel* The above would disable both Intel and AMD drivers if both were present on the system and already visible to the loader. |
VK_LOADER_LAYERS_ENABLE |
A comma-delimited list of globs to search for in known layers and
used to select only the layers whose layer name matches one or more of
the provided globs. Known layers are those which are found by the loader taking into account default search paths and other environment variables (like VK_LAYER_PATH). This has replaced the older deprecated environment variable VK_INSTANCE_LAYERS |
This functionality is only available with Loaders built with version 1.3.234 of the Vulkan headers and later. |
export VK_LOADER_LAYERS_ENABLE=*validation,*recon* set VK_LOADER_LAYERS_ENABLE=*validation,*recon* The above would enable the Khronos validation layer and the GfxReconstruct layer, if both were present on the system and already visible to the loader. |
VK_LOADER_LAYERS_DISABLE |
A comma-delimited list of globs to search for in known layers and
used to disable only the layers whose layer name matches one or more of
the provided globs. Known layers are those which are found by the loader taking into account default search paths and other environment variables (like VK_LAYER_PATH). |
This functionality is only available with Loaders built with version
1.3.234 of the Vulkan headers and later. Disabling a layer that an application intentionally enables as an explicit layer may cause the application to not function properly. This is also checked before other layer environment variables (such as VK_LOADER_LAYERS_ENABLE) so that a user may easily disable all layers and then selectively re-enable individual layers using the enable environment variable. |
export VK_LOADER_LAYERS_DISABLE=*MESA*,~implicit~ set VK_LOADER_LAYERS_DISABLE=*MESA*,~implicit~ The above would disable any Mesa layer and all other implicit layers that would normally be enabled on the system. |
Environment Variable | Behavior | Replaced By | Restrictions | Example Format |
---|---|---|---|---|
VK_ICD_FILENAMES |
Force the loader to use the specific driver JSON files.
The value contains a list of delimited full path listings to
driver JSON Manifest files. NOTE: If a global path to the JSON file is not used, issues may be encountered. |
This has been replaced by VK_DRIVER_FILES. | Ignored when running Vulkan application with elevated privileges. |
export VK_ICD_FILENAMES= set VK_ICD_FILENAMES= |
VK_INSTANCE_LAYERS | Force the loader to add the given layers to the list of Enabled layers normally passed into vkCreateInstance. These layers are added first, and the loader will remove any duplicate layers that appear in both this list as well as that passed into ppEnabledLayerNames. | This has been deprecated by VK_LOADER_LAYERS_ENABLE. It also overrides any layers disabled with VK_LOADER_LAYERS_DISABLE. | None |
export VK_INSTANCE_LAYERS= <layer_a>;<layer_b> set VK_INSTANCE_LAYERS= <layer_a>;<layer_b> |
Field Name | Field Value |
---|---|
Android Loader | The loader designed to work primarily for the Android OS. This is generated from a different code base than the Khronos loader. But, in all important aspects, it should be functionally equivalent. |
Khronos Loader | The loader released by Khronos and currently designed to work primarily on Windows, Linux, macOS, Stadia, and Fuchsia. This is generated from a different code base than the Android loader. But in all important aspects, it should be functionally equivalent. |
Core Function | A function that is already part of the Vulkan core specification and not
an extension. For example, vkCreateDevice(). |
Device Call Chain | The call chain of functions followed for device functions.
This call chain for a device function is usually as follows: first the
application calls into a loader trampoline, then the loader trampoline
calls enabled layers, and the final layer calls into the driver specific
to the device. See the Dispatch Tables and Call Chains section for more information. |
Device Function | A device function is any Vulkan function which takes a VkDevice,
VkQueue, VkCommandBuffer, or any child of these, as its
first parameter. Some Vulkan device functions are: vkQueueSubmit, vkBeginCommandBuffer, vkCreateEvent. See the Instance Versus Device section for more information. |
Discovery | The process of the loader searching for driver and layer files to set up
the internal list of Vulkan objects available. On Windows/Linux/macOS, the discovery process typically focuses on searching for Manifest files. On Android, the process focuses on searching for library files. |
Dispatch Table | An array of function pointers (including core and possibly extension
functions) used to step to the next entity in a call chain.
The entity could be the loader, a layer or a driver. See Dispatch Tables and Call Chains for more information. |
Driver | The underlying library which provides support for the Vulkan API.
This support can be implemented as either an ICD, API translation
library, or pure software. See Drivers section for more information. |
Extension | A concept of Vulkan used to expand the core Vulkan functionality.
Extensions may be IHV-specific, platform-specific, or more broadly
available. Always first query if an extension exists, and enable it during vkCreateInstance (if it is an instance extension) or during vkCreateDevice (if it is a device extension) before attempting to use it. Extensions will always have an author prefix or suffix modifier to every structure, enumeration entry, command entry-point, or define that is associated with it. For example, `KHR` is the prefix for Khronos authored extensions and will also be found on structures, enumeration entries, and commands associated with those extensions. |
Extension Function | A function that is defined as part of an extension and not part of the
Vulkan core specification. As with the extension the function is defined as part of, it will have a suffix modifier indicating the author of the extension. Some example extension suffixes include: KHR - For Khronos authored extensions, EXT - For multi-company authored extensions, AMD - For AMD authored extensions, ARM - For ARM authored extensions, NV - For Nvidia authored extensions. |
ICD | Acronym for "Installable Client Driver".
These are drivers that are provided by IHVs to interact with the
hardware they provide. These are the most common type of Vulkan drivers. See Installable Client Drivers section for more information. |
IHV | Acronym for an "Independent Hardware Vendor".
Typically the company that built the underlying hardware technology
that is being used. A typical examples for a Graphics IHV include (but not limited to): AMD, ARM, Imagination, Intel, Nvidia, Qualcomm |
Instance Call Chain | The call chain of functions followed for instance functions.
This call chain for an instance function is usually as follows: first
the application calls into a loader trampoline, then the loader
trampoline calls enabled layers, the final layer calls a loader
terminator, and the loader terminator calls all available
drivers. See the Dispatch Tables and Call Chains section for more information. |
Instance Function | An instance function is any Vulkan function which takes as its first
parameter either a VkInstance or a VkPhysicalDevice or
nothing at all. Some Vulkan instance functions are: vkEnumerateInstanceExtensionProperties, vkEnumeratePhysicalDevices, vkCreateInstance, vkDestroyInstance. See the Instance Versus Device section for more information. |
Layer | 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 driver. See the Layers section for more information. |
Layer Library | The Layer Library is the group of all layers the loader is able to discover. These may include both implicit and explicit layers. These layers are available for use by applications unless disabled in some way. For more info, see Layer Discovery . |
Loader | The middleware program which acts as the mediator between Vulkan
applications, Vulkan layers, and Vulkan drivers. See The Loader section for more information. |
Manifest Files | Data files in JSON format used by the Khronos loader. These files contain specific information for either a Layer or a Driver and define necessary information such as where to find files and default settings. |
Terminator Function | The last function in the instance call chain above the driver and owned
by the loader.
This function is required in the instance call chain because all
instance functionality must be communicated to all drivers capable of
receiving the call. See Dispatch Tables and Call Chains for more information. |
Trampoline Function | The first function in an instance or device call chain owned by the
loader which handles the set up and proper call chain walk using the
appropriate dispatch table.
On device functions (in the device call chain) this function can
actually be skipped. See Dispatch Tables and Call Chains for more information. |
WSI Extension | Acronym for Windowing System Integration.
A Vulkan extension targeting a particular Windowing system and designed
to interface between the Windowing system and Vulkan. See WSI Extensions for more information. |