On Sun, Oct 11, 2015 at 10:17 AM, Antía Puentes <apuen...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
