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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
