Proposal: debug naming of subresources

[martty]

Problem

When an application suballocates or reuses VkBuffers or VkImages, the object itself may have no meaningful identity - but the current debug naming API vkSetDebugUtilsObjectNameEXT and friends cannot name subresources, which makes it difficult for developers to get meaningful debug name readout. Furthermore, resource suballocation is an idiomatic way of using Vulkan.

Persistent identity subresources, where the application has suballocated from a buffer/image, but the identity of the subresource is tied to the host timeline. An example is suballocating a large buffer to hold the indices of a specific mesh - in this case the application would name the subresource before it is being used with an identifier, eg. 'Suzanne.glb - indices', and this name-subresource link would be persistent until the subresource is reused.

Proposal

Persistent identity subresources: a straightforward extension of VK_EXT_debug_utils, which allows the naming of subresources

struct VkDebugUtilsBufferRangeInfoEXT {
    VkStructureType    sType;
    const void*        pNext;
    VkDeviceSize       offset;
    VkDeviceSize       size;
    const char*        pObjectName;
};

struct VkDebugUtilsImageSubresourceInfoEXT {
    VkStructureType         sType;
    const void*             pNext;
    VkImageSubresourceRange subresource;
    const char*             pObjectName;
};

These structures can be chained to VkDebugUtilsObjectNameInfoEXT, when the named object is a VkBuffer or VkImage, respectively.

Discussion

• All identifiers and API snippets are just for explanation of course.

cc. @nanokatze @Dolkar

[HansKristian-Work]

This proposal is difficult to make progress on as-is from a Vulkan API point-of-view. This is a feature that should get buy-in from the tooling side first, because if they don't implement it, the extension is dead as drivers don't see this API anyways. It might be better to talk with those people first, and if the tooling applications can agree on an API they'd like to expose, we could get this into Vulkan without too much problem.

[krOoze]

The debug utilities do not really track on the device timeline neither, so it would be often ambiguous which name to report. Especially if there are also sync bugs. Until some kind of fence wait is called, it would be quantum superposition of multiple names.

Is this supposed to be like the state commands, where the name change would be immediate?

[martty]

Device timeline here means "with respect to command buffer recording", not the actual state of the device.

[krOoze]

Hm, makes sense. Perhaps should also add Private Data versions of those.

[martty]

Split off transient resource naming into #1954.