-
Notifications
You must be signed in to change notification settings - Fork 812
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect SPIR-V can be generated when using samplers in structs with relaxed rules #3594
Comments
Thanks for another report, I'll look into this. |
Turns out to be harder than expected. 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. 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 ? |
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: