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.
Basically we know how to remap variables from arrays when they are indexed with an integer literal, because it is easy to append the index to the variable name, create a top level binding for it, and call it a day.
When indexing an array with a variable, this trick doesn't work anymore since appending the variable name won't properly route to a top-level variable.
The only option I see to keep this behaviour transparent is to collapse array stacks entirely for opaque types. This is a bit more involved than I would like, and I'm not sure it is actually achievable.
Is it something that used to work but doesn't anymore ?
It's something that OpenGL GLSL supports, so my users have written shaders that use it which won't work on other backends.
I don't really like that it exists though, I could detect it and put in a warning if it's totally necessary but I'm hoping to avoid that to allow any OpenGL GLSL shader to work on Vulkan, Metal, etc. with my tool.
I think I managed to make something work, but it might change the way opaque uniforms locations are found. Considering I don't know how you handle them, would you mind giving it a try, see if it works for you ?
Here is a link to the branch on my fork : https://github.com/sbourasse/glslang/tree/bourasse/array-collapse
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: