Push descriptors generate false positive DescriptorSetNotBound errors
jeffbolznv opened this issue · 5 comments
Most of the CTS tests with "with_push" in the name generate this error, for example: dEQP-VK.binding_model.shader_access.primary_cmd_buf.with_push_template.sampler_mutable.vertex.single_descriptor.1d:
<Text>ERROR: [ UNASSIGNED-CoreValidation-DrawState-DescriptorSetNotBound ] Object: 0x23e65429a30 (Type = 6) | VkPipeline 0x16 uses set #0 but that set is not bound. (code 0xffffffff from Validation at CommandBuffer:0)</Text>
I think this error check is looking for a descriptor set to actually be bound, but push descriptors are "pushed" rather than bound. The draw is still valid.
@jeffbolznv I'm still chasing this down, but the only way I can see in the code for this error to occur is when there has been no vkCmdPushDecriptors call since 1) the beginning of the command buffer or 2) since the last time the descriptor set was disturbed by an incompatible bind. (unless there is a bug in that logic).
At the very least, the error message is incorrect/misleading/unuseful.
Do you have a test case you can share?
The Vulkan CTS test dEQP-VK.binding_model.shader_access.primary_cmd_buf.with_push_template.sampler_mutable.vertex.single_descriptor.1d generates this error, as do several other tests.
Great test case. It sets the push descriptors with vkCmdPushDescriptorSetWithTemplateKHR, and vkCmdPushDescriptorSetWithTemplateKHR validation is incomplete in that it doesn't update the state that the VU test relies upon.
The test message is also wrong in that the test doesn't look to see if the descriptor is a push or bind descriptor, so that fix needs to be folded in to this as well.
I'm hitting the same error. I don't think the status is correct - it should not be "Incomplete" (as that indicates missing validation) - the status quo is that trying to use update templates with push descriptors generates an error in otherwise valid code. I feel like this should be a bug.
edit Although I guess this has both labels so "incomplete" is just a misnomer :) Anyway, would be great to have this fixed - currently this validation error needs to be suppressed which can hide other valid occurrences of the same error.
Suppressing the false positive is certainly reasonably separable from implementing the needed functionality, but that change will have to be removed when the functionality is added.