On Tue, Apr 2, 2013 at 4:48 PM, Eric Anholt <[email protected]> wrote: > Matt Turner <[email protected]> writes: > >> The original goal of pre-register allocation scheduling was to reduce >> live ranges so we'd use fewer registers and hopefully fit into 16-wide. >> In shader-db, this change causes us to lose 30 16-wide programs, but we >> gain 29... so it's a toss-up. At least by choosing instructions in a >> better order all programs should be slightly faster. > > I think this will break the GLES3 test that we created this pass for.
It does, and I've been trying to figure out another way of solving it. > I think we'll get the same performance benefit by round-robining our > allocated registers instead of packing them in the low numbers, which is > what that branch I had mentioned to you was for. I don't think so, since the round-robin allocation would have helped write-after-read stalls, but our hardware doesn't stall on write-after-read. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
