[Mesa-dev] [PATCH] glsl: Lower constant arrays to uniform arrays.
eric at anholt.net
Thu Oct 16 00:42:11 PDT 2014
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 818 bytes
Desc: not available
More information about the mesa-dev