vulkano-shaders generate different types with the same name in one namespace

[p0lunin]

For the following code:

struct Foo { uint a; };
layout(std140, set = 0, binding = 0) readonly buffer A{
    Foo foo[];
};
layout(set = 1, binding = 0) readonly buffer B {
    Foo foo[];
};
void main() {}

vulkano-shaders generates 2 types with name Foo. I think this is because shader uses the same structure with different memory layouts std140 and shared (uses by default).

[Rua]

Clearly these need to have different names, but what should they be?

[p0lunin]

Maybe macro will create namespaces with memory layout as name? e.g. types::std140::Foo and types::packed::Foo.

[Rua]

What about the names A and B? How come those aren't used by Vulkano-shaders?

[Rua]

I accidentally stumbled upon this old issue. I'll elaborate a bit more for future reference. Given this definition in GLSL:

struct Foo {
    float bar;
};

layout(push_constant) uniform PushConstants {
    Foo x;
} pc;

layout(binding = 0) uniform Uniforms {
    Foo x;
} uni;

The shader compiler will generate this SPIR-V output:

               OpName %Foo "Foo"
        %Foo = OpTypeStruct %float
%PushConstants = OpTypeStruct %Foo
%_ptr_PushConstant_PushConstants = OpTypePointer PushConstant %PushConstants
         %pc = OpVariable %_ptr_PushConstant_PushConstants PushConstant

               OpName %Foo_0 "Foo"
      %Foo_0 = OpTypeStruct %float
   %Uniforms = OpTypeStruct %Foo_0
%_ptr_Uniform_Uniforms = OpTypePointer Uniform %Uniforms
        %uni = OpVariable %_ptr_Uniform_Uniforms Uniform

Two different structures with the name Foo are defined in the SPIR-V; one for the push constants and another copy for the uniform buffer. The same thing happens with a uniform buffer combined with any other kind of input variable, such as a storage buffer, as long as they use the same GLSL struct in their definition. This happens because uniform buffers use the extended alignment (std140) by default, instead of the base alignment (std430) used by everything else. The difference in layout becomes more clear when bar is turned into an array float bar[2]:

               OpDecorate %_arr_float_uint_2 ArrayStride 4
%_arr_float_uint_2 = OpTypeArray %float %uint_2
        %Foo = OpTypeStruct %_arr_float_uint_2

               OpDecorate %_arr_float_uint_2_0 ArrayStride 16
%_arr_float_uint_2_0 = OpTypeArray %float %uint_2
      %Foo_0 = OpTypeStruct %_arr_float_uint_2_0

Now, the two Foos aren't exact copies of each other anymore, but are actually different structs with a different layout.

Vulkano-shaders can't deal with this situation at the moment. When presented with two different structs named Foo, it will happily generate two Rust structs also named Foo, which of course leads to a compile error.

[marc0246]

This was fixed in #2132.

[Rua]

After some Discord discussion we concluded that the issue is only fixed in the case of duplicate structs. It's not fixed if the structs actually have different definitions, like in my last example above.

[marc0246]

For context, the way I see it is that as long as we have a stuct registration mechanism in place which tracks structs across different shaders, this is very difficult (maybe impossible?) to solve completely. We could append a number at the end of the struct name inside a shader, but what if two different shaders have the same type of collision, but their numberings end up being different?