[Bug 77957] New: Variably-indexed constant arrays result in terrible shader code

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77957

          Priority: medium
            Bug ID: 77957
          Assignee: idr at freedesktop.org
            Blocks: 77547
           Summary: Variably-indexed constant arrays result in terrible
                    shader code
        QA Contact: intel-3d-bugs at lists.freedesktop.org
          Severity: enhancement
    Classification: Unclassified
                OS: All
          Reporter: kenneth at whitecape.org
          Hardware: Other
            Status: NEW
           Version: git
         Component: Drivers/DRI/i965
           Product: Mesa

Our vec4 backend generates rubbish for 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>];

The constant array is stored as a temporary value in ordinary VGRFs, and then
demoted to scratch due to the variable indexing.

This means:
1. Piles of MOVs from immediates into registers (not to mention wasted
registers!)
2. Piles of scratch writes to move those registers into scratch.
3. Finally, a scratch read for the access.

We could instead demote constant arrays to uniforms.  This would eliminate the
scratch writes, moves, and wasted registers.  The pull load would be
approximately the same cost as the scratch read.

If we see constant arrays in the backend, I believe we can assume that they're
variably-indexed...otherwise opt_array_splitting would have handled them.

I'm not sure whether to implement this at the GLSL IR level or in the backend.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20140426/2fb9dd5f/attachment.html>