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

Jason Ekstrand jason at jlekstrand.net
Wed Mar 28 23:22:05 UTC 2018


On March 28, 2018 15:25:59 Timothy Arceri <tarceri at itsqueeze.com> wrote:

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.

Doing struct splitting in NIR may be useful especially for local variables 
with arrays if structs and indirections. In particular, having each 
register be an array of a single vector or scalar type.  Unfortunately, I 
don't see a way that we can actually remove struct support from the IR.




More information about the mesa-dev mailing list