-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Overview
While validation layers are a major help in ensuring a vulkan application is well behaved, they can be somewhat difficult to track due to the fact that there is just one debug callback handler provided by the VkDebugUtilsEXT extension. Attaching human-readable metadata tags to vulkan handles would be a great help in tracking the source of vulkan errors.
New Features
- An opt-in extension to all vulkan handle creation processes, which allows for arbitrary tags to be attached to a created vulkan handle. These would be associated with vulkan handles by their pointer addresses (since those remain static for the handle's lifetime in all cases) in some sort of map.
- Update the currently rather minimal debug callback to index the map based on the provided handle values of interest (these are passed to the callback via vulkan so that, for instance an error involving a VkQueue would have that handle passed to the callback automatically) and print relevant metadata (such as an associated human-readable name/identifier)
- Provide a minimal API for querying handle metadata and callbacks so that when handles are destroyed, the metadata is also destroyed as well.
Examples
As of now, validation errors look like so:
debug(validation): 4096 -- Validation Error: [ VUID-VkInstanceCreateInfo-flags-06559 ]
Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0xf6b4649b | vkCreateInstance(): pCreateInfo->flags has VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR set,
but pCreateInfo->ppEnabledExtensionNames does not include VK_KHR_portability_enumeration
The Vulkan spec states: If flags has the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit set, the list of enabled extensions in ppEnabledExtensionNames must contain VK_KHR_portability_enumeration
(https://vulkan.lunarg.com/doc/view/1.3.231.1/windows/1.3-extensions/vkspec.html#VUID-VkInstanceCreateInfo-flags-06559)But I think it wouldn't be too difficult to update them to look like this:
err(validation): 4096 -- Validation Error: [ VUID-VkInstanceCreateInfo-flags-06559 ]
Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0xf6b4649b | vkCreateInstance(): pCreateInfo->flags has VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR set,
but pCreateInfo->ppEnabledExtensionNames does not include VK_KHR_portability_enumeration
The Vulkan spec states: If flags has the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit set, the list of enabled extensions in ppEnabledExtensionNames must contain VK_KHR_portability_enumeration
(https://vulkan.lunarg.com/doc/view/1.3.231.1/windows/1.3-extensions/vkspec.html#VUID-VkInstanceCreateInfo-flags-06559)
Objects:
- [0]: VkInstance -- "Application Context"(The usefulness is admittedly less apparent in the example since there is really only ever one VkInstance but I was too lazy to cause another validation error to happen. Just imagine the objects overview for something like VkBuffers or ``VkDescriptorSets``` for which there are many possible handles in a given application)