In the last chapter, we initialized the Vulkan API and about learned the concepts of layers and extensions. We connected with the physical hardware device and understood the different types of queue exposed by it. Since we are gearing up for practical implementations, it's important that we learn the Vulkan debugging in order to avoid unpleasant mistakes.
Vulkan allows you to perform debugging through validation layers. These validation layer checks are optional and can be injected into the system at runtime. Traditional graphics APIs perform validation right up front using some sort of error-checking mechanism, which is a mandatory part of the pipeline. This is indeed useful in the development phase, but actually, it is an overhead during the release stage because the validation bugs might have already been fixed at the development phase itself. Such compulsory checks cause the CPU to spend a significant amount of time in error checking.
On the other hand, Vulkan is designed to offer maximum performance, where the optional validation process and debugging model play a vital role. Vulkan assumes the application has done its homework using the validation and debugging capabilities available at the development stage, and it can be trusted flawlessly at the release stage.
In this chapter, we will learn about the validation and debugging process of a Vulkan application. We will cover the following topics:
- Peeking into Vulkan debugging
- Understanding LunarG validation layers and their features
- Implementing debugging in Vulkan
Vulkan debugging validates application implementation. It surfaces not only errors, but also other validations, such as proper API usage. It does so by verifying each parameter passed to it, warning about the potentially incorrect and dangerous API practices in use and reporting any performance-related warnings when the API is not used optimally. By default, debugging is disabled, and it's the application's responsibility to enable it. Debugging works only for those layers that are explicitly enabled at the instance level at the time of instance creation (VkInstance).
When debugging is enabled, it inserts itself into the call chain for the Vulkan commands the layer is interested in. For each command, the debugging visits all the enabled layers and validates them for any potential error, warning, debugging information, and so on.
Debugging in Vulkan is simple. The following is an overview that describes the steps required to enable it in an application:
- Enable debugging capabilities by adding the
VK_EXT_DEBUG_REPORT_EXTENSION_NAMEextension at the instance level. - Define the set of validation layers intended for debugging. For example, we are interested in the following layers at the instance and device level. For more information about these layer functionalities, refer to the next section:
VK_LAYER_GOOGLE_unique_objectsVK_LAYER_LUNARG_api_dumpVK_LAYER_LUNARG_core_validationVK_LAYER_LUNARG_imageVK_LAYER_LUNARG_object_trackerVK_LAYER_LUNARG_parameter_validationVK_LAYER_LUNARG_swapchainVK_LAYER_GOOGLE_threading
- The Vulkan debugging APIs are not part of the core command, which can be statically loaded by the loader. These are available in the form of extension APIs that can be retrieved at runtime and dynamically linked to the predefined function pointers. So, as the next step, the debug extension APIs
vkCreateDebugReportCallbackEXTandvkDestroyDebugReportCallbackEXTare queried and linked dynamically. These are used for the creation and destruction of the debug report. - Once the function pointers for the debug report are retrieved successfully, the former API (
vkCreateDebugReportCallbackEXT) creates the debug report object. Vulkan returns the debug reports in a user-defined callback, which has to be linked to this API. - Destroy the debug report object when debugging is no longer required.