Name conflicts not previously present in generated headers from sokol-shdc after 5e42076

[jdah]

I use the generated shader headers from sokol-shdc pretty extensively, often including and using multiple shaders in the same source file - It looks like in 5e42076 uniform buffers, images, and samplers were changed to generate in the reflection headers as "UB/IMG/SMP_<name>" instead of "UB/IMG/SMP_<program>_<name>" which gives conflicts when the same name is used (I tend to just call one-off textures "tex" or whatever) across multiple shaders. It seems like vertex attributes are still prefixed with the program name though?

Am I missing something/is there a reason the program name was dropped? if not, can we get it back please? :)

EDIT: this is specifically in the #define-d names - i.e. #define UB_whatever (0). manually prefixing types, especially for uniform blocks only seems like a half solution because then I end up with types like <program>_<program>_vs_params_t :/

[floooh]

Hmm, previously the 'conflict potential' was even bigger, because it was just SLOT_<name> instead of being separated by the resource type (this commit you're pointing to just undid a temporary experiment in the bindings-cleanup branch).

Maybe something else has regressed though which causes the same defines to be generated multiple times.

Can you check that you are on the latest sokol-shdc version? Because there was a regression which caused such conflicts:

https://github.com/floooh/sokol-tools/blob/master/CHANGELOG.md#09-nov-2024

If that's not it, can you upload the shader(s) which cause that collision so that I can reproduce the problem?

The intended behaviour is that a single IMG_tex constant is generated for all textures named tex in a single shader file (no matter how many shader programs are in that file - that's also why all resources of the same name and type must have the same bindslot definition) - that way you may get collissions across shader files though.

One thing that has changed is that there's no 'module prefix' anymore in the generated constants. Do you use the @module meta-tag in your shaders? I removed the module prefixing because it wasn't consistent across the various languages anyway, but if it is actually used it would be trivial to add back.

[jdah]

Yeah, I'm on the latest sokol-shdc - the issue isn't the same constants being generated in a single shader file though.

The intended behaviour is that a single IMG_tex constant is generated for all textures named tex in a single shader file (no matter how many shader programs are in that file - that's also why all resources of the same name and type must have the same bindslot definition) - that way you may get collissions across shader files though.

It's the collisions across shader files that are an issue for me, like having IMG_tex across multiple shaders with potentially different bindslots and then including both of those generated headers in the same file. something like

<file a.glsl>
@module A
...
@fs fs
layout(binding=0) uniform texture2D tex;
...
@end
@program a vs fs

<file b.glsl>
@module B
...
@fs fs
layout(binding=0) uniform texture2D another_tex;
layout(binding=1) uniform texture2D tex;
...
@end
@program b vs fs

then including generated headers a.glsl.h and b.glsl.h in the same source file.

One thing that has changed is that there's no 'module prefix' anymore in the generated constants. Do you use the @module meta-tag in your shaders? I removed the module prefixing because it wasn't consistent across the various languages anyway, but if it is actually used it would be trivial to add back.

I do use the module prefix and that's what was previously allowing me to not have name conflicts across files. With the module prefixes back this issue would be fixed for me.

[floooh]

I do use the module prefix and that's what was previously allowing me to not have name conflicts across files. With the module prefixes back this issue would be fixed for me.

Oki doki, yeah, removing the module prefix for C/C++ was a stupid idea in hindsight (for other language bindings that's ok because those languages typically have a module system which wraps symbols in their own namespace).

I'll add the module prefixes back ASAP for the C/C++ generator.

And thanks for the bug report!

[floooh]

Ok should be fixed now, see PR #161 for details.

The binaries in sokol-tools-bin will be uptodate when this CI pipeline goes green:

https://github.com/floooh/sokol-tools/actions/runs/12260726422

...I think I'll also change one of the sokol-samples to use the @module tag to protect from regressions in the future.