Vulkan validation: mesh-fallback indirect draws use a dynamic vertex stride that was never set (VUID-04913) #2494

Closed
opened 2026-11-11 20:59:12 +00:00 by hckrman101 · 1 comment
hckrman101 commented 2026-11-11 20:59:12 +00:00 (Migrated from github.com)

On a GPU without mesh shaders (RX 580, Mesa 26.2.6 RADV), the Khronos validation layer (1.4.363) reports thousands of these per play session:

VUID-vkCmdDrawIndirect-pStrides-04913
VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE state is dynamic, but the command buffer never called vkCmdBindVertexBuffers2

So a pipeline with a dynamic vertex binding stride is drawn with vkCmdDrawIndirect while no vertex buffers were bound through vkCmdBindVertexBuffers2 in that command buffer. The indirect draws are most likely the mesh-shader fallback's (compute writes the vertices, then an indirect draw), which would explain why it only shows on cards without mesh shaders.

Counts, about 45 s in Kokiri Forest after reaching play, headless:

build 04913 messages presents
main 7759a6f3 5,302 2,760
#2323's head 12f835d0 4,373 1,680

It scales with frames drawn; nothing else in that run's validation output is new.

Why it matters: drawing with a dynamic stride state that was never set is undefined. On this RADV it renders correctly as far as we can see, but another driver could read a garbage stride.

Possible fixes, not tried:

  • give the fallback's indirect-draw pipelines a static stride (drop VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE from them), or
  • bind the fallback's vertex buffer, or a dummy one, with vkCmdBindVertexBuffers2 before those draws.

How to reproduce: a GPU without mesh shaders (or force the mesh fallback), RX_VK_VALIDATION=1 with the validation layer installed and its duplicate-message limit off, then play for a minute.

On a GPU without mesh shaders (RX 580, Mesa 26.2.6 RADV), the Khronos validation layer (1.4.363) reports thousands of these per play session: ``` VUID-vkCmdDrawIndirect-pStrides-04913 VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE state is dynamic, but the command buffer never called vkCmdBindVertexBuffers2 ``` So a pipeline with a dynamic vertex binding stride is drawn with `vkCmdDrawIndirect` while no vertex buffers were bound through `vkCmdBindVertexBuffers2` in that command buffer. The indirect draws are most likely the mesh-shader fallback's (compute writes the vertices, then an indirect draw), which would explain why it only shows on cards without mesh shaders. Counts, about 45 s in Kokiri Forest after reaching play, headless: | build | 04913 messages | presents | |---|---|---| | main 7759a6f3 | 5,302 | 2,760 | | #2323's head 12f835d0 | 4,373 | 1,680 | It scales with frames drawn; nothing else in that run's validation output is new. Why it matters: drawing with a dynamic stride state that was never set is undefined. On this RADV it renders correctly as far as we can see, but another driver could read a garbage stride. Possible fixes, not tried: - give the fallback's indirect-draw pipelines a static stride (drop `VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE` from them), or - bind the fallback's vertex buffer, or a dummy one, with `vkCmdBindVertexBuffers2` before those draws. How to reproduce: a GPU without mesh shaders (or force the mesh fallback), `RX_VK_VALIDATION=1` with the validation layer installed and its duplicate-message limit off, then play for a minute.
NotRexed commented 2026-11-11 21:31:15 +00:00 (Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #1001, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1001 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

Thanks for the report. Reports of the same problem are now collected in #1001, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1001 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.
Commenting is not possible because the repository is archived.
No milestone
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Hookshot#2494
No description provided.