Skip to content

Human Readable Metadata for Vulkan Handles #7

@JohnSmoit

Description

@JohnSmoit

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)

See the following comment for implentation details

Metadata

Metadata

Assignees

Labels

DebugHelps track and identify bugs in the library itselfVulkanSpecifically effects the Vulkan BackendenhancementNew feature or request

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions