layers: Suppress incorrect validation error for buffer_reference#5349
Conversation
|
Author piofra01-arm not on autobuild list. Waiting for curator authorization before starting CI build. |
|
CI Vulkan-ValidationLayers build queued with queue ID 28684. |
|
CI Vulkan-ValidationLayers build # 10886 running. |
|
CI Vulkan-ValidationLayers build # 10886 passed. |
|
Minor issue with the formatting of the commit see https://github.com/KhronosGroup/Vulkan-ValidationLayers/actions/runs/4286113485/jobs/7465624547 |
|
I really want a test to prevent regression of this. Do you have a SPIR-V example that was hitting this, I am willing to add the test if you don't want to |
|
Author piofra01-arm not on autobuild list. Waiting for curator authorization before starting CI build. |
22827c3 to
f065e1c
Compare
|
Author piofra01-arm not on autobuild list. Waiting for curator authorization before starting CI build. |
|
Here are the shaders used in the test where the issue was spotted: The test mostly just draws a quad, the only twist is that it uses data from the shared buffer in the fragment shader. It doesn't do anything special, besides setting up basic scaffolding to create the buffer and pass it to the vertex shader. Specifically:
The input description/state looks as follows: |
SHADER_MODULE_STATE::GetBaseType returns zero when passed a physical storage buffer to a struct, which later results in a validation error, despite no check whether structs passed between shader stages are compatible. This change suppresses the validation error.
f065e1c to
13abd6e
Compare
|
Author piofra01-arm not on autobuild list. Waiting for curator authorization before starting CI build. |
|
@piofra01-arm thanks for the descriptive example. I am going to quick write up a negative test to
|
spencer-lunarg
left a comment
There was a problem hiding this comment.
So looking into this, the real issue is I wasn't aware that you could use a PhysicalStorageBuffer struct as a shader interface type
I wrote up some test to make sure to test this correctly
Because currently we are falsely reporting any PhysicalStorageBuffer interface, I am ok for taking this change now until I finish up my change to correctly check these types of interfaces (Will create an issue once this is merged to track it)
|
CI Vulkan-ValidationLayers build queued with queue ID 31975. |
|
CI Vulkan-ValidationLayers build # 10967 running. |
|
CI Vulkan-ValidationLayers build # 10967 passed. |
SHADER_MODULE_STATE::GetBaseType returns zero when passed a physical storage buffer to a struct, which later results in a validation error, despite no check whether structs passed between shader stages are compatible. This change suppresses the validation error.
Conceptually, this change addresses a wider spectrum of cases, where in the
TypesMatchfunction we failed to identify both of the compared types, and would returnfalse(types don't match). Currently the only clear path for this to happen is dealing with a physical storage buffer to a struct, in which case a potentially unhelpful validation error is produced:This logic seems to hold for a general case, where both types are unknown - since we failed to identify parameter types, we cannot validate their compatibility.
Returning
truein this case leads to some counter-intuitive logic, wheretruedoesn't mean we verified the types match, rather, that we're not certain that they don't match. If this is not acceptable, I can refactor this to also be able to express the case where we were unable to compare the types.Otherwise,
TypesMatchis only used in one place, and is static within theshader_validation.cppfile, so this workaround doesn't introduce issues elsewhere.Conceptually, failing to identify types in
TypesMatchlikely warrants its own validation warnings, but handling this is beyond the scope of this pull request.An ideal solution would be to implement a mechanism to compare this type of parameters being passed between shader stages, at least for cases where they can be resolved, and validate struct compatibility. The above validation error shows the types are known, and BaseTypesMatch already contains the code for comparing structs. This is also beyond the scope of this pull request.