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

[Francisco Jerez]

Antía Puentes <apuentes at igalia.com> writes:

> Hi Matt,
>
> thanks for your suggestions.
>
> On dom, 2015-10-11 at 10:35 -0700, Matt Turner wrote:
>> 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.
>
> Ok.
>
>> 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.
>
> I will be working on global copy propagation then.
>

Heh...  I suggest you hold yourself from working on this for a while.

While working on some fragment discard improvements last week I noticed
that a seemingly harmless change in the CFG could cause shitloads of
shader-db regressions (>8k).  The reason is that a bunch of optimization
passes of the compiler back-end are fully local (including VEC4 copy
propagation) and become ineffective anytime your dataflow happens to
traverse edges of the CFG.

Instead of reimplementing the intricate dataflow propagation logic (e.g.
what fs_copy_prop_dataflow does) in every pass (or rather every pass
that needs to consider two or more instructions at once), I've given a
shot at implementing use-def chains in the back-end (didn't have a
bigger hammer at hand).  Use-def chains should simplify this sort of
optimization passes massively and allow them to work globally without
any additional effort: Instead of looping back the instruction list to
find out whether the last instruction that wrote a register had some
specific form (c.f. cmod_propagation, saturate_propagation,
compute_to_mrf, which are all local and have O(n^2) complexity), you
just look-up the use entry for the instruction you're interested in and
look at its immediate neighbours in the use-def graph, which represent
the instruction(s) that generated the variable.

Use-def chains can be implemented trivially on an SSA IR so as an added
benefit it should become easier to port optimization passes to SSA once
they've been rewritten in terms of use-def chains.

I've got an algorithm to construct the use-def graph basically working
on the FS back-end (I'm not sharing it publicly yet though because in
its current form it would likely offend some people's sensibilities -- I
could send you a branch in private though if you're interested).  I
haven't started porting other optimization passes to use it yet, but
it's next on my to-do list.

>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151012/9913bc72/attachment-0001.sig>