validation: vkCmdBindDescriptorBuffersEXT/VkDescriptorBufferBindingInfoEXT ignore VkBufferUsageFlags2CreateInfo usage

[a2flo]

Environment:

• OS: any
• GPU and driver version: NVIDIA 550.40.82 and 565.77
• SDK or header version if building from repo: 1.4.304 and latest git
• Options enabled (synchronization, best practices, etc.):

Describe the Issue

It appears that the validation of VkDescriptorBufferBindingInfoEXT when calling vkCmdBindDescriptorBuffersEXT() currently disregards VkBufferUsageFlags2CreateInfo usage flags.

I'm getting a VUID 08055 validation error, saying that the buffer doesn't match the .usage specified in VkDescriptorBufferBindingInfoEXT (which is set to 0). There is however a chained VkBufferUsageFlags2CreateInfo that contains the correct usage which seems to get ignored.

This happens with both a Vulkan 1.4 or 1.3 device/instance, with VK_EXT_descriptor_buffer, VK_KHR_maintenance5, and VK_KHR_maintenance6 enabled.

Expected behavior

As per VkDescriptorBufferBindingInfoEXT spec:
"If the pNext chain includes a VkBufferUsageFlags2CreateInfo structure, VkBufferUsageFlags2CreateInfo::usage from that structure is used instead of usage from this structure."

Valid Usage ID
08055, 09499, 09500
VUID-VkDescriptorBufferBindingInfoEXT-pNext-pNext

Additional context

Probably somewhere around: https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/main/layers/core_checks/cc_descriptor.cpp#L2491

[spencer-lunarg]

@a2flo can you possibly paste the full 05088 error message? We have made sure VkBufferUsageFlags2CreateInfo is piped through everywhere, so it should not be ignored anyway

I wrote a test in #9232 and it is working without any errors

[a2flo]

Full error message:

Validation Error: [ VUID-vkCmdBindDescriptorBuffersEXT-pBindingInfos-08055 ] Object 0: handle = 0x7cc1e30000000d60, name = desc_buf:clear_color#0, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x7c40443c | vkCmdBindDescriptorBuffersEXT(): pBindingInfos[0].address (0x12830000) has no buffer(s) associated to it such that valid usage passes. At least one buffer associated to this device address must be valid.
The following buffers have a usage that does not match pBindingInfos[0].usage (VkBufferUsageFlags2(0)):
VkBuffer 0x7cc1e30000000d60[desc_buf:clear_color#0]: buffer has usage VK_BUFFER_USAGE_2_TRANSFER_SRC_BIT|VK_BUFFER_USAGE_2_TRANSFER_DST_BIT|VK_BUFFER_USAGE_2_STORAGE_BUFFER_BIT|VK_BUFFER_USAGE_2_INDEX_BUFFER_BIT|VK_BUFFER_USAGE_2_INDIRECT_BUFFER_BIT|VK_BUFFER_USAGE_2_SHADER_DEVICE_ADDRESS_BIT|VK_BUFFER_USAGE_2_RESOURCE_DESCRIPTOR_BUFFER_BIT_EXT
The Vulkan spec states: For any element of pBindingInfos, usage must match the buffer from which address was queried (https://docs.vulkan.org/spec/latest/chapters/descriptorsets.html#VUID-vkCmdBindDescriptorBuffersEXT-pBindingInfos-08055)

Of course, if I set .usage in VkDescriptorBufferBindingInfoEXT to the old truncated/32-bit usage flags, everything works as expected. But that is not the intent of VkBufferUsageFlags2 and not what is stated in the spec.

@spencer-lunarg: your test doesn't make use of VkBufferUsageFlags2CreateInfo when calling vkCmdBindDescriptorBuffersEXT.

Also note that VkBufferUsageFlags2 validation works everywhere else for me.

FYI:

(lldb) l -
   418 			vkCmdBindDescriptorBuffersEXT(encoder->cmd_buffer.cmd_buffer, desc_buf_count,  desc_buf_bindings.data());

(lldb) p desc_buf_count
(const uint32_t) 1

(lldb) p desc_buf_bindings[0]
(std::vector<VkDescriptorBufferBindingInfoEXT>::value_type)  (sType = VK_STRUCTURE_TYPE_DESCRIPTOR_BUFFER_BINDING_INFO_EXT, pNext = 0x00005962b1ee18d0, address = 310575104, usage = 0)

(lldb) p *(VkBufferUsageFlags2CreateInfo*)desc_buf_bindings[0].pNext
(VkBufferUsageFlags2CreateInfo)  (sType = VK_STRUCTURE_TYPE_BUFFER_USAGE_FLAGS_2_CREATE_INFO, pNext = 0x0000000000000000, usage = 4325731)

[spencer-lunarg]

@a2flo ooooo, I see, I can reproduce this now.

We track the VkBufferUsageFlags2CreateInfo for the VkBuffer, but yes, we are not using the correct usage when it was applied to VkDescriptorBufferBindingInfoEXT... getting a fix up now!

[a2flo]

Thanks, works for me as well now.