[Mesa-dev] Plan to work on opt_peephole_sel optimization for vec4

[Matt Turner]

On Sun, Oct 11, 2015 at 10:17 AM, Antía Puentes <apuentes at igalia.com> wrote:
> As there are quite a lot of movement related to vec4 optimizations and I
> would like to avoid overlapping, I am commenting here that I intend to
> work on a version of the fs_visitor::opt_peephole_sel() for vec4.
>
> Suggestions about other FS optimizations worth porting to the vec4
> backend are welcome.

Hi Antia.

I don't believe it's valuable to port the opt_peephole_sel() pass to
the vec4 backend. With NIR (since NIR essentially performs the same
optimization), the opt_peephole_sel() pass only improves code
generation on Gen < 7 (where we use MRFs) in cases like

(+f0) if
mov m1, ...
mov m2, ...
send ..., m1
else
mov m1, ...
mov m2, ...
send ..., m1
endif

where the two sends are texture operations using the same coordinate
but different samplers. On Gen7+ where send-from-GRF, the source
payload for the two sends will be different registers and
opt_peephole_sel() won't handle it.

That said, we still do send-from-MRF on all platforms in the vec4
backend, but texturing is sufficiently rare in vertex shaders that I
don't believe there's much to be gained.


I believe the most valuable optimization missing from the vec4 backend
is global copy propagation (it currently only has local copy
propagation). *Lots* of shaders would benefit from this even before we
switched to NIR, and even more after.

While both fs/vec4 backends have opt_copy_propagate(), the fs
backend's implementation is much better. It first performs local (that
is, on each basic block separately) copy propagation. Second, it uses
the values available at the end of each block to generate an analysis
of the dataflow, and finally it reruns local copy propagation but this
time with more data available.

I would expect big improvements in the vec4 backend from making its
copy propagation pass global.