[Mesa-dev] [PATCH 42/61] nir: Add a concept of per-member structs and a lowering pass

[Timothy Arceri]

On 29/03/18 08:23, Timothy Arceri wrote:
> On 29/03/18 05:34, Jason Ekstrand wrote:
>> On March 27, 2018 21:16:25 Timothy Arceri <tarceri at itsqueeze.com> wrote:
>>
>> So I've been thinking about structs and I'm pretty sure we should be
>> able to write some passes to completely lower them away.
>>
>> vertex shader inputs, buffer block and shader interface blocks cannot
>> contain structs so it seems to me the only blocker is the way we assign
>> uniform and varying locations.
>>
>> Currently for a struct like this:
>>
>> struct S2 {
>> int b;
>> int c;
>> };
>>
>> struct S1 {
>> int a;
>> S2 s2[3];
>> int d;
>> };
>>
>> uniform S1 s[2][2];
>>
>> We store things like so:
>>
>> s[0][0].a = location 0
>> s[0][0].s[0].b = location 1
>> s[0][0].s[0].c = location 2
>> s[0][0].s[1].b = location 3
>> s[0][0].s[1].c = location 4
>> s[0][0].s[2].b = location 5
>> s[0][0].s[2].c = location 6
>>
>> ...
>>
>> If we had a GLSL IR pass that pushed the arrays down to the innermost
>> member like so:
>>
>> struct S2 {
>> int b[2][2][3];
>> int c[2][2][3];
>> };
>>
>> struct S1 {
>> int a[2][2];
>> S2 s2;
>> int d[2][2];
>> };
>>
>> uniform S1 s;
>>
>>
>> We would instead store things like so:
>>
>> s[0][0].a = location 0
>> s[0][1].a = location 1
>> s[1][0].a = location 2
>> s[1][1].a = location 3
>> s[0][0].s[0].b = location 4
>> s[0][0].s[1].b = location 5
>> s[0][0].s[2].b = location 6
>>
>> ...
>>
>> This allows us to easily split the members out into independent arrays
>> of arrays.
>>
>> To do this we might want to create the uniform (resource) name before
>> pushing the arrays down so that we still match up the correct uniforms
>> with the names passed to the API but that shouldn't be to difficult.
>>
>> With this in place we should be able to generate better shaders when
>> structs are used and be able to delete a whole bunch of struct handing
>> code (and avoid this new code/concept?).
>>
>> Does anyone see any holes in my analysis?
>>
>> Only that it doesn't help for SPIR-V which is the whole reason for 
>> this patch.
>>
>>
> 
> How does it not help SPIR-V? As per above it would seem the only reason 
> we need to handle structs in NIR is because of the way we assign storage 
> in OpenGL. I'm not as overly familiar with SPIR-V still but is there any 
> reason we can't do the struct splitting pass in NIR and be done with 
> structs?
> 

Ok nevermind. I misread the spec buffer blocks can indeed contains 
structs which make this not as useful.