Open StefanPoelloth opened 4 months ago
spencer-lunarg
commented
4 months ago 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
commented
4 months ago 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();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
commented
4 months ago 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
commented
4 months ago @spencer-lunarg did the repro help or can i provide more information like a dump or gfxreconstruct?
spencer-lunarg
commented
4 months ago I haven't had time to look at the repro, it should likely be fine, just backed up currently with GPU-AV stuff
glebov-andrey
commented
1 month ago Hi,
I think we're seeing the same issue with GPU-AV.
There are a lot of VUID-vkCmdDraw-format-07753 which VUID-vkCmdDraw-viewType-07752 which do not match the actual shaders mentioned, e.g. [Set 0, Binding 1, Index 0, variable "output_image"] requires UINT component type, but bound descriptor format is VK_FORMAT_R8G8_UNORM., when the mentioned descriptor set doesn't even have a binding named output_image, and none which would require a UINT component type.
I'm not sure if this is related, but TSAN reports a number of data races inside VVL when GPU-AV is enabled.
It might also have somthing to do with the data race which I reported here: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/4646#issuecomment-1988557333 Even with a single worker thread this data race still occurs because it's related to a VVL-internal thread
spencer-lunarg
commented
1 month ago @glebov-andrey thanks for poking this again
I am 90% sure I know the source of this all, the issue is how we mark which descriptors were touched for bindless descriptors. Currently the logic is intertwined with the generic validation. We need to separate it so things like Sync Validation can use it, so I have this on my upper priority to get fixed by the next SDK for sure
glebov-andrey
commented
1 month ago @spencer-lunarg Sounds great! In that case, should I create separate issues about the data races (either of them)?
spencer-lunarg
commented
1 month ago should I create separate issues
@glebov-andrey yes, we do test with TSAN for normal validation, but realized right now we don't do it for GPU-AV and should check that regardless (as might be unrelated in the future even if we fix this issue)
Environment:
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)