You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I run glslang -V -R --aml --amb myfile.frag I get this if I disassemble the result. It uses an extra myLighti_shadowMap uniform with no binding, which seems like it shouldn't happen.
If I then run SPIRV-Cross to generate a Metal shader from the SPIR-V via spirv-cross --msl --msl-version 20100 frag.spv, this is the result which also seems broken - it's accessing a single myLighti_shadowMap uniform in the loop instead of accessing something different in each iteration.
If a sampler is in a struct and relaxed rules (-R) are used when generating SPIR-V code, it can have incorrect output.
Here's an example GLSL shader:
If I run
glslang -V -R --aml --amb myfile.frag
I get this if I disassemble the result. It uses an extramyLighti_shadowMap
uniform with no binding, which seems like it shouldn't happen.bad SPIR-V disassembly
If I then run SPIRV-Cross to generate a Metal shader from the SPIR-V via
spirv-cross --msl --msl-version 20100 frag.spv
, this is the result which also seems broken - it's accessing a singlemyLighti_shadowMap
uniform in the loop instead of accessing something different in each iteration.bad MSL code
FYI @sbourasse
Tested with the latest glslang release (14.2.0).
The text was updated successfully, but these errors were encountered: