[Mesa-dev] [PATCH 2/7] vbo: Add a predraw resolve callback

[Chris Wilson]

On Wed, Sep 09, 2015 at 10:19:10AM -0700, Ian Romanick wrote:
> On 09/09/2015 10:10 AM, Kenneth Graunke wrote:
> > On Wednesday, September 09, 2015 02:38:56 PM Chris Wilson wrote:
> >> A common problem with using HiZ and multisampling is that surfaces need
> >> to resolved prior to use. Currently i965 does this inside its state
> >> update hook, but that is a comparatively heavyweight operation that need
> >> not be performed so frequently. The obvious solution (and therefore
> >> fraught with dragons) is to move the HiZ/color resolves into the
> >> brw_draw_prims() - however, the resolves are performed using meta and
> >> end up re-entering brw_draw_prims() corrupting the context state of the
> >> original call. To avoid the meta recursion, we can add a new callback
> >> (vbo->resolve()) into the vbo pipeline that is called just before
> >> vbo->draw().
> >>
> >> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >> Cc: Brian Paul <brianp at vmware.com>
> >> Cc: Jordan Justen <jordan.l.justen at intel.com>
> >> Cc: Jason Ekstrand <jason.ekstrand at intel.com>
> >> Cc: Kenneth Graunke <kenneth at whitecape.org>
> >> Cc: Francisco Jerez <currojerez at riseup.net>
> >> ---
> >>  src/mesa/vbo/vbo.h            |  1 +
> >>  src/mesa/vbo/vbo_context.c    | 19 +++++++++++++++++++
> >>  src/mesa/vbo/vbo_context.h    |  1 +
> >>  src/mesa/vbo/vbo_exec_array.c |  1 +
> >>  src/mesa/vbo/vbo_exec_draw.c  |  5 ++++-
> >>  src/mesa/vbo/vbo_save_draw.c  |  2 ++
> >>  6 files changed, 28 insertions(+), 1 deletion(-)
> > 
> > What problem are you trying to solve with this patch series?
> > Are you trying to fix bugs?  If so, what triggers them?
> > Are you trying to improve performance?  If so, do you have any data
> > demonstrating that it benefits some workload?
> 
> In 0/7 he says, "By moving the current HiZ/color resolves
> we need before drawing from out of the notify and into the draw itself,
> we can save a few percent of overhead in OglBatch7 on Atom class
> devices."  Given the amount of change here, I too would like to see some
> actual performance data.

http://people.freedesktop.org/~ickle/vbo/

ministat 63c4b7e_bench_synmark:OglBatch7 2fbce8b_bench_synmark:OglBatch7
x 63c4b7e_bench_synmark:OglBatch7
+ 2fbce8b_bench_synmark:OglBatch7
+------------------------------------------------------------------------------+
|                                                    x               +         |
|                                                    x               +         |
|                                                    x   x           + +  +    |
|                                                    x   x           +++ +++   |
|                                               x  x x   x x         +++ +++   |
|                                               x  xxx  xx xx        +++++++   |
|                                              xx xxxxx xxxxx    +  ++++++++++ |
|x                          x              x   xxxx**xx xxxxxx  x++ +++++++++++|
|                                          |________AM________|   |____A____|  |
+------------------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x  50       8.96925       10.4881       10.2213     10.203639    0.22548474
+  50         10.16       10.8186       10.6612     10.649134    0.12242131
Difference at 95.0% confidence
	0.445495 +/- 0.0719896
	4.36604% +/- 0.705529%
	(Student's t, pooled s = 0.181425)

Looking at the total number of intel_update_state() vs brw_draw_prims()
for OglBatch7 doesn't alone explain the change as there are nearly the
same number of calls to both. (Though we do see similar changes in the
INTEL_NO_HW versions of OglBatch0 and OglBatch7, but that data is much
more noisy.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre