Closed aitor-lunarg closed 11 months ago
I feel like this has been reported elsewhere as well, but can't find it at the moment, but yeah, pretty sure this is a known problem unfortunately :/
@ncesario-lunarg I've asked this in the chat about a week ago, maybe that's what you're thinking of.
Yep @ziga-lunarg, that's what I was thinking of, just completely forgot where I saw it :)
So I looked into this, I think this would benefit from the Instruction
class I have talked to @ncesario-lunarg about. The main issue is if a shader looks like
%image = OpLoad %type_image %image_ptr
%value1 = OpImageRead %type_vec4_u32 %image %const_vec2_i32_00 SignExtend
%value2 = OpImageRead %type_vec4_u32 %image %const_vec2_i32_00
would still be invalid, so currently at draw time we have data stored in the descriptors (ex is_write_without_format
) but what is really needed is a way to look at the access instructions (OpImageRead
s) at draw time, but the SHADER_MODULE_STATE
is not around. Having a separate Instruction
class could be copied to hold and in this case, it could be used to check if SignExtend
is set... I hit this similar issue of needing the actual instruction for some other SPIRV validation not yet implemented (VUID-vkCmdDispatch-None-04115
and VUID-vkCmdDispatch-OpImageWrite-04469
)
@aitor-lunarg I still need to add the spirv-val
code to catch cases where you mix signedness, but can you confirm the false positive are gone from CTS now
Describe the Issue As stated in the title, if we have an OpTypeImage (https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpTypeImage) with a mismatching
Sampled Type
of the bound image we will getVUID-vkCmdDispatch-None-02699
even if the access respectsImage Format
's signedness.The spec (https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#spirvenv-format-type-matching) states that
The signedness must match the signedness of any access to the image
. Spir-v 1.4 introducesSignExtend
andZeroExtend
to force signedness when accessing the resource, so until resource access, we won't know if the access is correct as stated in https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#spirvenv-image-signednessValid Usage ID VUID-vkCmdDispatch-None-02699
Environment:
Additional context Here's a test to replicate the issue:
The main issue being
%type_image = OpTypeImage %type_u32 2D 0 0 0 2 Rgba32i
since the sample result is unsigned instead of signed.Can also be replicated using CTS
dEQP-VK.image.extend_operands_spirv1p4.*.mismatched_sign.*