AmberScript: Support a buffer with values of multiple types

[jaebaek]

Since the current AmberScript has only the following way to initialize a buffer with specific data:

BUFFER {name} DATA_TYPE {type} DATA
_value_+
END

it is impossible test the following case:

#!amber

SHADER compute kComputeShader HLSL
struct struct_with_bool {
  bool2 elem_v2bool;
  int2 elem_v2int;
  float2 elem_v2float;
  bool elem_bool;
  int elem_int;
  float elem_float;
};

ConsumeStructuredBuffer<struct_with_bool> consume_struct_with_bool;
AppendStructuredBuffer<bool> append_bool;
AppendStructuredBuffer<float> append_float;
AppendStructuredBuffer<int> append_int;

void main() {
  append_bool.Append(consume_struct_with_bool.Consume().elem_bool);
  append_int.Append(consume_struct_with_bool.Consume().elem_int);
  append_float.Append(consume_struct_with_bool.Consume().elem_float);
  append_v2bool.Append(consume_struct_with_bool.Consume().elem_v2bool);
  append_v2int.Append(consume_struct_with_bool.Consume().elem_v2int);
  append_v2float.Append(consume_struct_with_bool.Consume().elem_v2float);
}
END

BUFFER kConsumeBuffer DATA_TYPE float DATA
4.0 19.0
END
BUFFER kConsumeBufferIndex DATA_TYPE uint32 DATA
2
END

...

[jaebaek]

We need the following syntax:

BUFFER {name} DATA_TYPE DATA
({type} _value_+)+
END

e.g.,

BUFFER {name} DATA_TYPE DATA
uint 32
float 2.0 3.0 4.0
bool true false
vec2(float) 1.0 5.0
END

[dj2]

I'd rather have a way to define structs in amberscript then to write each type each time. Something like:

DATA_TYPE my_struct {
 bool2
 int2
 float2
}

And then use that data_type in the BUFFER command. But, do you have an actual test which requires structs at this point? If not, I'd prefer to hold off adding it until we know it's needed. (Like, can you just switch your example to using multiple buffers instead of a struct?)

[jaebaek]

Thank you for your suggestion. It worries me that the layout of new structure is unclear.
Is it std140 or std430?
Do we need padding or stride?

I think we need it now because we cannot bind multiple buffer for a single descriptor set / binding.
In my example above, consume_struct_with_bool must have 0 / 0 as descriptor set / binding.
With the current AmberScript spec, there is no way to create a buffer for consume_struct_with_bool nor create multiple buffers and bind it for 0 / 0.
(Please let me know if it is wrong)

[jaebaek]

Here is my suggestion:

1. Potential issues when we have multiple types in a buffer

• The offset of a value is unclear i.e., unclear layout
• It is unclear how we check the result values in EXPECT command

2. Spec we must add

• For the buffer definition, provide specific information i.e., type, offset, stride:

BUFFER {name} DATA_WITH_MULTIPLE_TYPES
(DATA_TYPE {type} OFFSET {offset} STRIDE {stride} _value_+)+
END

• Provide the same information for the verification:

EXPECT {buffer_name} IDX _x_ {comparator}
(DATA_TYPE {type} OFFSET {offset} STRIDE {stride} _value_+)+
END

[dj2]

Do we need the offset information? We figure it out for other buffers based on the layout used. We should be able to figure it out for data buffers. Which also means we don't need it for EXPECT as well.

(We shouldn't need it for the expect if the offsets are encoded in the data type, it can just use them)

[jaebaek]

Well .. I believe more specific rule would be more clear. If some GLSL users see a buffer definition without offset / stride information, it might be confusing. @dneto0 could you please tell your opinion?

[dj2]

GLSL doesn't have the buffer definitions in it, as far as I can tell. You're going to do something like

struct foo {
  float3 a;
  float b;
  bool2 c;
}

And it's just going to magically pack the float into the float3. But if you had an int there, it would pad the float3 to a float4 automatically. We, I think, need to replicate the automatic things and figure out how the layout works and just do the right thing.

[jaebaek]

I am still confused. Do you mean we need some rules like

struct foo {
  float3 a; // offset 0
  float b; // offset 12
  bool2 c; // offset 16
}

and

struct foo {
  float3 a; // offset 0
  int b; // offset 16
  bool2 c; // offset 20
}

?

Why don't we just put offset / stride information we define the struct?
I still believe it would be more clear.

For example,

DATA_TYPE foo
  OFFSET 0 STRIDE 16 TYPE float3 a[4]
  OFFSET 64 STRIDE 4 TYPE int b
  OFFSET 68 STRIDE 4 TYPE bool2 c
END

or we can skip STRIDE for non-array type

DATA_TYPE foo
  OFFSET 0 STRIDE 16 TYPE float3 a[4]
  OFFSET 64 TYPE int b
  OFFSET 68 TYPE bool2 c
END

Since SPIR-V has the same thing for struct based on OpMemberDecorate Offset ..., I think users can just use the layout specified in SPIR-V.

[dj2]

Because as the person writing the script with a GLSL source, I have no idea what those numbers should be. I don't know that float3 will pad to float4 or that float3,float won't have padding on the float3. Amber should be able to figure out all of those bits as needed.