False positive VUID-vkCmdDraw-viewType-07752
Environment:
- OS: Windows 10
- GPU and driver version: NVIDIA GeForce RTX 3070 Ti, API version: 1.3.277.0, Driver info: NVIDIA 551.86
- SDK or header version if building from repo: 1.3.283.0
- Options enabled (synchronization, best practices, etc.): GAV
Describe the Issue
Run the 04_MetallicRoughness sample:
Validation layer:
Validation Error: VUID-vkCmdDraw-viewType-07752
Object 0: handle = B0D8DD000000039B, type = VK_OBJECT_TYPE_DESCRIPTOR_SET;
MessageID = 0000000000000000
vkCmdDraw(): the descriptor (VkDescriptorSet 0xb0d8dd000000039b[], binding 0, index 12)
ImageView type is VK_IMAGE_VIEW_TYPE_CUBE but the OpTypeImage has (Dim = 2D) 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://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDraw-viewType-07752)
Expected behavior
No validation error.
Additional context
The GLSL shader contains aliased descriptors at binding 0:
layout (set = 0, binding = 0) uniform texture2D kTextures2D[];
layout (set = 1, binding = 0) uniform texture3D kTextures3D[];
layout (set = 2, binding = 0) uniform textureCube kTexturesCube[];
The index 12 is never accessed via kTextures2D[]. Only via kTexturesCube[].
This issue exists in Vulkan SDKs 1.3.283.0, 1.3.280.0, 1.3.275.0.
1.3.268.0 has no issues.
Possibly related: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/7932
so can confirm it on my machine, poked at it, I think this is something with how we manage our buffers and possibly not clearing them
This NEVER happens on the first vkQueueSubmit but always the 2nd (or sometimes 4th or even later) it will suddenly have the 12 index as part of binding 0 instead of 2
@spencer-lunarg Is there a way to fix it?
for now export VK_LAYER_MESSAGE_ID_FILTER=VUID-vkCmdDraw-viewType-07752 unfortunately
I know @arno-lunarg or I will get a chance to look into this soon, but currently trying to fix other GPU-AV related issues
So I looked more into this and I was confused as I confirmed the values coming in were valid, I then went to the demo and added some DebugPrintf and found
int textureBindlessQueryLevels2D(uint textureid) {
return textureQueryLevels(kTextures2D[textureid]);
}
is where I am getting the bad value from
I confirmed the envMapTextures.envMapTexture.index(), that gets piped there was where the 12 (in my case 13) came from
so from my knowledge this is a bug in the demo and needs to be
- return textureQueryLevels(kTextures2D[textureid]);
+ return textureQueryLevels(kTexturesCube[textureid]);
@spencer-lunarg Oh, I think we just need a separate function for cube maps, textureBindlessQueryLevelsCube().
Fixed https://github.com/PacktPublishing/3D-Graphics-Rendering-Cookbook-Second-Edition/commit/b8ff6677ad4d72eeb0acbc26929e271e5ab5d7b9.
@spencer-lunarg Thanks for figuring this out!
awesome, glad to hear!