Fix OpImageRead result type when compiling HLSL (#2706)
authorNathan Reed <nathaniel.reed@gmail.com>
Wed, 28 Jul 2021 15:29:17 +0000 (08:29 -0700)
committerGitHub <noreply@github.com>
Wed, 28 Jul 2021 15:29:17 +0000 (09:29 -0600)
commitfc9897d1ba419063a67b105ccf5a6364402a1ea7
tree39701c4dd9d29571c0204380c1d6495a65a933de
parent4a12ee1ae364c4e7fc7f3ae0675e5a1df8190ae2
Fix OpImageRead result type when compiling HLSL (#2706)

Fix OpImageRead result type when compiling HLSL

- Per the Vulkan spec, OpImageRead must return a 4-component vector always. When compiling HLSL, loads from a RWTexture of a template type with < 4 components would incorrectly generate an OpImageRead with a < 4 component result, resulting in validation errors.
- This was previously fixed for OpImageFetch in commit 4425f24; this commit does the same thing for OpImageRead.
- Added associated tests and expanded existing image fetch tests to check all the different types of textures, in both float and int incarnations, for completeness.
- Update other HLSL tests involving OpImageRead
SPIRV/GlslangToSpv.cpp
Test/baseResults/hlsl.imagefetch-subvec4.comp.out
Test/baseResults/hlsl.imageload-subvec4.comp.out [new file with mode: 0644]
Test/baseResults/hlsl.rw.register.frag.out
Test/baseResults/hlsl.rw.scalar.bracket.frag.out
Test/baseResults/hlsl.rw.vec2.bracket.frag.out
Test/baseResults/spv.rw.autoassign.frag.out
Test/hlsl.imagefetch-subvec4.comp
Test/hlsl.imageload-subvec4.comp [new file with mode: 0644]
gtests/Hlsl.FromFile.cpp