On 08/27/2013 03:21 PM, Eric Anholt wrote:
intel_flush() now did nothing except call through (and
intel_batchbuffer_flush() does the no-op check, too!)
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 4 +---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 2 +-
src/mesa/drivers/dri/i965/intel_context.c | 17 ++++-------------
src/mesa/drivers/dri/i965/intel_context.h | 3 ---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +--
src/mesa/drivers/dri/i965/intel_pixel_copy.c | 3 ++-
src/mesa/drivers/dri/i965/intel_syncobj.c | 2 +-
7 files changed, 10 insertions(+), 24 deletions(-)
Series is:
Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
When running glxgears with INTEL_DEBUG=bat (and batch decoding turned
off) on master, I see this:
intel_context.c:366: Batchbuffer flush with 5388b (pkt) + 3424b (state)
= 8812b (26.9%)
intel_screen.c:165: Batchbuffer flush with 748b (pkt) + 448b (state) =
1196b (3.6%)
gen6_blorp.cpp:57: Batchbuffer flush with 16b (pkt) + 0b (state) =
16b (0.0%)
gen6_blorp.cpp:57: Batchbuffer flush with 740b (pkt) + 160b (state) =
900b (2.7%)
......repeating......
Which is pretty ridiculous...a 16 byte batch? Really? And we have to
switch to the kernel to execbuffer that. The others aren't much better.
With this series, we get a single batch per frame:
intel_screen.c:176: Batchbuffer flush with 6940b (pkt) + 4096b (state) =
11036b (33.7%)
......repeating......
Clearly much better. Every other application I've looked at sees
similar benefits - much better batch utilization, much fewer tiny batches.
--Ken
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
