[Mesa-dev] [PATCH] glsl: Lower constant arrays to uniform arrays.

[Eric Anholt]

Kenneth Graunke <kenneth at whitecape.org> writes:

> Consider GLSL code such as:
>
>    const ivec2 offsets[] =
>       ivec2[](ivec2(-1, -1), ivec2(-1, 0), ivec2(-1, 1),
>               ivec2(0, -1),  ivec2(0, 0),  ivec2(0, 1),
>               ivec2(1, -1),  ivec2(1, 0),  ivec2(1, 1));
>
>    ivec2 offset = offsets[<non-constant expression>];
>
> Both i965 and nv50 currently handle this very poorly.  On i965, this
> becomes a pile of MOVs to load the immediate constants into registers,
> a pile of scratch writes to move the whole array to memory, and one
> scratch read to actually access the value - effectively the same as if
> it were a non-constant array.
>
> We'd much rather upload large blocks of constant data as uniform data,
> so drivers can simply upload the data via constbufs, and not have to
> populate it via shader instructions.
>
> This is currently non-optional because both i965 and nouveau benefit
> from it - we can revisit that if another driver actually benefits.
>
> Improves performance in a terrain rendering microbenchmark by about 2x,
> and cuts the number of instructions in about half.  Helps a lot of
> "Natural Selection 2" shaders, as well as one "HOARD" shader.
>
> total instructions in shared programs: 5473459 -> 5471765 (-0.03%)
> instructions in affected programs:     5880 -> 4186 (-28.81%)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77957
> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
>
> Reviewers: suggestions for better max_array_access handling are welcome.
> Reviewers: This changes the const-ness of the expression.  Is that a problem?

I definitely like the idea for my driver (temporary registers are
precious)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141016/81ac4228/attachment.sig>