Eric Anholt <e...@anholt.net> writes: > This brings over the batch-wrap-prevention and aperture space checking > code from the normal brw_draw.c path, so that we don't need to flush the > batch every time. > > There's a risk here if the intel_emit_post_sync_nonzero_flush() call isn't > high enough up in the state emit sequences -- before, we implicitly had > one at the batch flush before any state was emitted, so Mesa's workaround > emits didn't really matter. > > Improves cairo-gl performance by 13.7733% +/- 1.74876% (n=30/32) > No statistically significant performance difference on unigine tropics > (n=10) > No statistically significant performance difference on openarena (n=755) > No statistically significant performance difference on Lightsmark (n=15, > though this may be an issue of test power -- looks like a ~.3% > performance hit) > Reduces low-resolution GLB 2.7 performance by 0.604517% +/- 0.140544% > (n=132/133) > --- > I've got the test system running more Lightsmark now -- the bimodal > distribution of its results was killing the stats, and I'd bumped the > power cable and it ran out of battery and died. > > I'm a little mystified by the small GLB and possibly LM regressions. > My theory was the first-post-swap-batch throttling, except > that we've got about 5 batches per frame on GLB.
Updated LM results: -2.45051% +/- 0.341284% (n=30/32). At this point I think we do need to figure out these regressions before landing the change. It's on the blorp-flush branch of my tree if someone wants to follow up while I'm gone.
pgpNJU3z8Thrt.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
