Handle buffer reference with arrays to themselves

[spencer-lunarg]

The following currently causes issues with how member type of structs are found

#version 450
#extension GL_EXT_buffer_reference : enable

layout(buffer_reference) buffer T1;
layout(set = 3, binding = 1, buffer_reference) buffer T1 {
   layout(offset = 48) T1  c[2]; // stride = 8 for std430, 16 for std140
} x;

void main() {}

Can reproduce with test/glsl/buffer_handle_2.spv

[cassiebeckley]

For the example you linked, spirv-reflect is producing the output

generator       : Google Shaderc over Glslang
source lang     : GLSL
source lang ver : 450
source file     :
entry point     : main (stage=PS)


  Descriptor bindings: 1

    Binding 3.1
      spirv id : 15
      set      : 3
      binding  : 1
      type     : VK_DESCRIPTOR_TYPE_STORAGE_BUFFER (UAV)
      count    : 1
      accessed : false
      name     : x (T1)
          // size = 0, padded size = 0
          struct T1 {

              // abs offset = 48, rel offset = 48, size = 16, padded size = 16, array stride = 8 UNUSED
              ref struct T1 {

                  // abs offset = 0, rel offset = 0, size = 0, padded size = 0
                  ref struct T1 {
                  } T1[2];

              } c[2];

          } x;

What is the desired output in this case? Would it make sense to simply stop at the first ref struct T1 and not show a struct body for that?

[chaoticbob]

It should look something like this:

          // size = 0, padded size = 0
          struct T1 {             
              ref T1  c[2];  // abs offset = 48, rel offset = 48, size = 16, padded size = 16, array stride = 8 UNUSED
          } x;

The logic would be someting like it's a buffer binding with a reference to something at offset=48. Size information for this might not be applicable or it's capped to the array stride. Need to understand what the shader developer's perspective on that would be.

Does layout(buffer_reference) itnroduce a new decoration or type? GLSL already causes a lot of confusion between the various OpTypeStruct for the block name, the block type, and the binding name. So not having sometype of anchoring information will make it even more annoying to parse.

[cassiebeckley]

Looking at this closer, it seems that glslang compiles T1 from the sample into T1 and T1_0. If I manually update the SPIR-V to decorate these with the correct names, the output is

  Descriptor bindings: 1

    Binding 3.1
      spirv id : 5
      set      : 3
      binding  : 1
      type     : VK_DESCRIPTOR_TYPE_STORAGE_BUFFER (UAV)
      count    : 1
      accessed : false
      name     : x (T1)
          // size = 0, padded size = 0
          struct T1 {

              // abs offset = 48, rel offset = 48, size = 16, padded size = 16, array stride = 8 UNUSED
              ref struct T1_0 {

                  // abs offset = 0, rel offset = 0, size = 0, padded size = 0
                  ref struct T1_0 {
                  } T1_0[2];

              } c[2];

          } x;

which I believe is correct (with the possible exception of T1_0[2] instead of c_0[2].

[spencer-lunarg]

after spending a LOT more time on this (while working on it indirectly with #232) I realize that the amount of effort to try and convey what is going on 100% in the non-YAML output is just not worth it... it works and displays information correctly in the YAML and (most importantly) the runtime version of it.

other problems related to this are solved in #232