Extensions are a concept any OpenGL users may be familiar with: Extensions provide optional functionality provided by the specific driver implementation. These may include functionality not included in the Vulkan standard by default, functionality with limited availability, or functionality restricted to certain operating systems.
The amount of extensions available at present is low, but gives a fair indication of the types of extensions to become available at some time. The following table includes all extensions mentioned in Khronos' official Vulkan 18.104.22.168 header. This list may not be up to date at present, and extensions provided by vendors does not have to be in the official Vulkan header, so there may be more extensions around.
| ||Platform-specific surface APIs. (X) is an abbreviation for the target platform (eg win32)|
| || Allows for the use of the |
| || Allows for the |
| ||Allows debug layers to report messages back to the application using a callback function. Mostly used by the debugging layers.|
| ||Allows the application to set descriptive names for points in time on a command list or command queue|
| ||NVidia-specific extension allowing shaders to be in GLSL rather than SPIR-V|
| ||AMD-specific extension allowing the strict rasterization order guaranteed by the API to be relaxed, potentially imporiving GPU rasterization performance|
Some of these extensions (such as
VK_EXT_debug_report) are instance extensions, where as others are device extensions. The difference for the most part comes down to whether or not it extends functionality on the API itself or provides additional functionality in either the driver or the GPU.
Vulkan is in many ways similar to Direct3D 12. Similarly to Direct3D 12, Vulkan aims to reduce the amount of CPU load required to submit sufficient work to the GPU.
One of the approaches used to reduce overhead in use of the Vulkan API was to remove most error checking from the Vulkan API calls themselves.
In older APIs, such as Vulkan's predecessor OpenGL, driver implementations were required to check for user errors. This allows the developer to ensure all operations are executed correctly during development. This is important for the development process, as this provides invaluable information in incorrect usage of the API and miscellaneous inefficiencies.
However, a well-developed product will upon release no longer require error checking, as by that point most problems that were in the application would have been fixed by the developers. As such, the CPU time invested in ensuring correct usage of the API is effectively wasted.
While performance is improved by this measure, debugging is still a necessary part of the development process. This need is served by introducing debugging layers. While not the only purpose of layers, this is at the present time the largest use case for layers.
Layers can intercept function calls between the application and the API, allowing these layers to detect the function call, check the parameters, perform some logic over this input and then pass the data to the next layer and ultimately the runtime.
Layers are used for debugging, but also for utilities. Renderdoc is a popular graphics debugger for Direct3D 11, OpenGL and Vulkan which also uses the layer mechanism to allow tracking the debugged application. On the other hand, the Steam overlay commonly used in games purchased from Valve's online distribution platform is also provided as a layer to inject itself into the application automatically.
Both of the aforementioned example layers are implicit layers. This means the layers are added to the list of layers even if the user did not explicitly ask for them in the application. Exclusive layers have to be specified by the user in function calls to
vkCreateDevice for instance layers and device layers respectively.