Kenneth Graunke <kenn...@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 <kenn...@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)
pgpXa7iFjHjkm.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
