Closed AlexRouSg closed 4 months ago
@AlexRouSg we do shader instrumentation to detect if the texture is accessed or not. Can you provide the SPIR-V as it will be helpful to see if the bug is how we are instrumenting it
@spencer-lunarg I have tested with a very minimal frag shader and here it is, this is the first draw call with 2D textures, the second one is the same but sub 2D with 3D
vert shader is nothing interesting, just a fullscreen triangle
this is perfect! Thanks @AlexRouSg
We have a big PR refactoring a lot in GPU-AV but will take a look into this after that lands
update - have test to reproduce, this is only for GPU-AV and works fine with normal core checks
narrowed it down to
vkCmdBindPipeline(); // 2D
vkCmdBindDescriptorSets();
vkCmdBindPipeline(); // 3D
vkCmdDraw(); // draw that uses 3D textures
causes the error, about to dive into it more, but wanted to log progress
Environment:
Describe the Issue
The following code triggers
VUID-vkCmdDraw-viewType-07752
.However swapping the order of
vkCmdBindDescriptorSets
andvkCmdBindPipeline
does not.Removing the first draw call and related binding cmds that only uses 2D textures also does not trigger this VUID.
Expected behavior This VUID should not trigger as I have verified the SPIRV manually that the second draw call does not contain a
OpTypeImage 2D
nor does renderdoc detect a 3D texture being bound to the first draw call.Valid Usage ID VUID-vkCmdDraw-viewType-07752
ImageView type is VK_IMAGE_VIEW_TYPE_3D but the OpTypeImage has ( Dim = 2D )
Additional Info: Might be relevant but I am also using dynamic rendering + graphics pipeline library