Layers incorrectly assume a dynamic state has been invalidated

[rg3igalia]

Environment:

• OS: Fedora 44
• GPU and driver version: RADV from Mesa main
• SDK or header version if building from repo: 74115d6
• Options enabled (synchronization, best practices, etc.): defaults+synchronization

Describe the Issue

There is an upcoming set of CTS tests that are failing validation due to what I think is a layers bug. The situation is a bit tricky. The tests try to verify that drivers are not invalidating dynamic state by mistake when doing something like:

1. Set a dynamic state.
2. Bind pipeline that does not have that state (not static nor dynamic).
3. Draw.
4. Bind pipeline with the dynamic state from step 1.
5. Draw.

And the goal is verifying that the dynamic state from step 1 is correctly used at step 5. Most of the tests work alright, but some of them fail unexpectedly. In particular, there are some cases that try to check this with, e.g., VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT. In those cases, the pipeline bound at step 2 disables rasterization and sets pViewportState to nullptr at pipeline creation time, arguably creating a pipeline that does not have viewport state, but the layers complain:

ERROR|VALIDATION: [VUID-vkCmdDraw-scissorCount-03418] vkCmdDraw(): VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT state is dynamic, but the command buffer never called vkCmdSetScissorWithCount.
(There was a call to vkCmdBindPipeline with VkPipeline 0x1240000000124 that didn't have VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT and invalidated the prior vkCmdSetScissorWithCount call).
The Vulkan spec states: If a shader object is bound to any graphics stage or a graphics pipeline is bound which was created with the VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT dynamic state enabled, and the state is not inherited, then vkCmdSetScissorWithCount must have been called and not subsequently invalidated in the current command buffer prior to this drawing (https://docs.vulkan.org/spec/latest/chapters/drawing.html#VUID-vkCmdDraw-scissorCount-03418)

With the problem being that I think the state has not been invalidated because the pipeline bound at step 2 did not have that state.

Expected behavior

No validation errors.

Valid Usage ID

VUID-vkCmdDraw-scissorCount-03418 and VUID-vkCmdDraw-viewportCount-03417.

Additional context

N/A

[rg3igalia]

There's something very similar happening when the first pipeline has a null pDepthStencilState, which is allowed when the subpass or dynamic render pass does not have a depth attachment. In these cases the draws may happen in separate subpasses or dynamic render passes, because the second pipeline would typically use a depth attachment. The dynamic states that would be affected are:

• VK_DYNAMIC_STATE_DEPTH_TEST_ENABLE
• VK_DYNAMIC_STATE_DEPTH_WRITE_ENABLE
• VK_DYNAMIC_STATE_DEPTH_COMPARE_OP
• VK_DYNAMIC_STATE_DEPTH_BOUNDS_TEST_ENABLE
• VK_DYNAMIC_STATE_STENCIL_TEST_ENABLE
• VK_DYNAMIC_STATE_STENCIL_OP
• VK_DYNAMIC_STATE_DEPTH_BOUNDS

And the sequence would look like:

1. Set dynamic state related to depth/stencil (one of the above).
2. Start rendering without a depth attachment.
3. Bind pipeline with pDepthStencilState set to nullptr.
4. Draw.
5. Next subpass, or end and start rendering, in both cases with a depth attachment.
6. Bind pipeline with dynamic state from step 1.
7. Draw.
8. End rendering.

Affected VUs could be VUID-vkCmdDraw-None-07843, VUID-vkCmdDraw-None-07844 and VUID-vkCmdDraw-None-07845, maybe more.

[spencer-lunarg]

Bind pipeline that does not have that state

.... yes, this whole Dynamic State stuff is a hot mess right now... it use to be "dynamic or static" and now there is this "ignored" state that is effecting various issues

@rg3igalia send me the CTS CL (and test name) offline so I can try it out locally if possible

thanks for reporting, adding on my Dynamic State Fun™ pile