False VUID-vkCmdDraw-format-07753 (and 07752)

[StefanPoelloth]

Environment:

• OS: Windows 10 22H2
• GPU and driver version: 2080Ti 556.12
• SDK or header version if building from repo: d0a37c686 (and 1.3.283 with less informations)
• Options enabled (synchronization, best practices, etc.): GPU-Assisted with Shader instrumentation and Descriptors indexing

Describe the Issue

The validation error says that Set 1 Binding 7 called "RoughnessMetallic" is of type float. But the compute shader using the descriptor set 0x26c066af5c8 is defining: layout(set = 1, binding = 7, rg32ui) uniform readonly uimage2D Visibility; And a 'RoughnessMetallic' doesnt exist in that shader, however in the next vkCmdDispatch that uses a different shader and descriptor set (not 0x26c066af5c8) uses RoughnessMetallic in Set 1 Binding 7.

validation layer: Validation Error: [ VUID-vkCmdDraw-format-07753 ] Object 0: handle = 0x26c066af5c8, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; Object 1: handle = 0x26c1032f0d0, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0x7be8f3b5 | vkCmdDraw(): the descriptor VkDescriptorSet 0x26c066af5c8[] [Set 1, Binding 7, Index 0, variable "RoughnessMetallic"] requires FLOAT component type, but bound descriptor format is VK_FORMAT_R32G32_UINT. The Vulkan spec states: If a VkImageView is accessed as a result of this command, then the numeric type of the image view's format and the Sampled Type operand of the OpTypeImage must match (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDraw-format-07753)

Expected behavior

There shouldnt be a validation error.

Additional context There seems to be a similar issue with VUID-vkCmdDraw-viewType-07752, It complains about TonemapLut being wrong but the descriptor set is some internal stuff from FSR2 that we use. "TonemapLut" is used in our postprocess vkCmdDispatch which is executed after FSR2.

validation layer: Validation Error: [ VUID-vkCmdDraw-viewType-07752 ] Object 0: handle = 0x54193b0000000384, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; Object 1: handle = 0xad17c80000000339, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0x73ed4ff5 | vkCmdDraw(): the descriptor VkDescriptorSet 0x54193b0000000384[] [Set 1, Binding 1, Index 0, variable "TonemapLut"] ImageView type is VK_IMAGE_VIEW_TYPE_2D but the OpTypeImage has (Dim = 3D) and (Arrayed = 0). The Vulkan spec states: If a VkImageView is accessed as a result of this command, then the image view's viewType must match the Dim operand of the OpTypeImage as described in Instruction/Sampler/Image View Validation (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDraw-viewType-07752)

[spencer-lunarg]

so the issue is there seems to be some issue between the compute vs graphics

just to get a confirmation from your side, when you call vkCmdBindPipeline and vkCmdBindDescriptorSets you are not mixing up the VK_PIPELINE_BIND_POINT_COMPUTE and VK_PIPELINE_BIND_POINT_GRAPHICS on them

[StefanPoelloth]

No, the passes resulting in VUID-vkCmdDraw-format-07753 are all vkCmdDispatch and vkCmdBindDescriptorSets only use VK_PIPELINE_BIND_POINT_COMPUTE.

Im not sure if FSR uses graphics internally.

Heres some pseudocode of the called functions where Execute is a vkCmdDispatch and Draw is a vkCmdDraw... Our passes hold the descriptor sets privately, the sets are not shared between passes.

PrimaryCullPass.Execute();
PrimaryVisibilityPass.Draw();
BuildTempHzbPass.Execute(c);
SecondaryCullPass.Execute();
SecondaryVisibilityPass.Draw();
BuildFinalHzbPass.Execute();
AttributePass.Execute(); # uses descriptor set 0x26c066af5c8 
ShadingPass.Execute(); # uses RoughnessMetallic in compute shader
FSR2Pass.Execute();
PostProcessPass.Execute();
DebugDisplayPass.Execute();
ImguiPass.Draw();

[spencer-lunarg]

thanks, will need to try to reproduce in a unit test, unfortunately some other stuff is top priority atm, so might be a bit until I swing back to this

[StefanPoelloth]

thanks, will need to try to reproduce in a unit test, unfortunately some other stuff is top priority atm, so might be a bit until I swing back to this

Ive hacked together a repro in c#: repro.zip

[StefanPoelloth]

@spencer-lunarg did the repro help or can i provide more information like a dump or gfxreconstruct?

[spencer-lunarg]

I haven't had time to look at the repro, it should likely be fine, just backed up currently with GPU-AV stuff