GLSL local variables, interface blocks, and XOR #258
Conversation
Otherwise the backends will panic on e.g. `vec4 local = Global;` if the global isn't used anywere else in the function.
![monocodus[bot]](https://avatars.githubusercontent.com/in/28526?s=60&v=4){kind=small}
| } else { | ||
| // variables in interface blocks without an instance name are in the global namespace | ||
| // https://www.khronos.org/opengl/wiki/Interface_Block_(GLSL) | ||
| if let TypeInner::Struct { members } = &extra.module.types[d.ty].inner { |
There was a problem hiding this comment.
Let's not match on a reference, instead we should just do ref members. This is more explicit and less sugary.
| for m in members { | ||
| if let Some(name) = &m.name { | ||
| let h = extra | ||
| .module | ||
| .global_variables | ||
| .fetch_or_append(GlobalVariable { | ||
| name: Some(name.into()), | ||
| class, | ||
| binding: binding.clone(), | ||
| ty: m.ty, | ||
| interpolation, | ||
| storage_access: StorageAccess::empty(), // TODO | ||
| }); | ||
| extra.lookup_global_variables.insert(name.into(), h); | ||
| } | ||
| } |
There was a problem hiding this comment.
I don't really see how this works - how does it relate to the code here: https://github.com/kristoff3r/naga/blob/c436606d09188efab0057db469802ea01df3230f/src/front/glsl/parser.rs#L971.
Also won't this register the members as 'plain' global vars? What happens when these are referenced - then I don't think it will translate into AccessIndex. (OpAccessChain in spv).
I made a small sample where you can see the spv output for named vs. anon interface block: http://shader-playground.timjones.io/12dc04ae724cbb6aa1ddcf812e638302
There was a problem hiding this comment.
Ah, I didn't notice that there was some handling of this already. I'll take a look at it and see if it needs changing.
There was a problem hiding this comment.
No worries, we'll sort it out :)
There was a problem hiding this comment.
I shall wait for @pjoe before merging the GLSL-in fixes
I did some more GLSL work. With this all the shaders from #210 gets through glsl-in -> glsl-out with what looks like a sensible result - except for a small bug in glsl-out, which I'll open another pull request for.