When Glslang creates a counter for an AppendStructuredBuffer, the additional buffer is placed in the same (set,binding) slot as its associated buffer. I think that's a bug because it's a binding collision. DXC puts the associated counter in the binding right after the associated buffer. Examples below.
(Neither variable gets an Index decoration)
Consider this shader with an AppendStructuredBuffer:
Note that variable %outputs_0 and its associated counter %outputs_count_0 both get descriptor set 0 and binding 0.
I think this is a bug because they collide.
DXC's SPIR-V output puts the counter in binding 1.
Compile with dxc -spirv -T cs_6_0 -E main x.comp -Fo x.d.spv -fspv-reflect
I get the following. Note that %counter_var_outputs is in set 0, binding 1.
When Glslang creates a counter for an AppendStructuredBuffer, the additional buffer is placed in the same (set,binding) slot as its associated buffer. I think that's a bug because it's a binding collision. DXC puts the associated counter in the binding right after the associated buffer. Examples below.
(Neither variable gets an Index decoration)
Consider this shader with an AppendStructuredBuffer:
Let's say I put it in file
x.comp
I compile it to SPIR-V, using :
glslang -D -e main -V100 --hlsl-iomap x.comp -o x.spv
I get this SPIR-V:
Note that variable
%outputs_0
and its associated counter%outputs_count_0
both get descriptor set 0 and binding 0. I think this is a bug because they collide.DXC's SPIR-V output puts the counter in binding 1. Compile with
dxc -spirv -T cs_6_0 -E main x.comp -Fo x.d.spv -fspv-reflect
I get the following. Note that
%counter_var_outputs
is in set 0, binding 1.