[Mesa-dev] [PATCH 2/2] i965: Avoid flushing the batch for every blorp op.
eric at anholt.net
Fri Jun 28 14:38:11 PDT 2013
Eric Anholt <eric at 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
> 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%
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the mesa-dev