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 <ch...@chris-wilson.co.uk> > >> Cc: Brian Paul <bri...@vmware.com> > >> Cc: Jordan Justen <jordan.l.jus...@intel.com> > >> Cc: Jason Ekstrand <jason.ekstr...@intel.com> > >> Cc: Kenneth Graunke <kenn...@whitecape.org> > >> Cc: Francisco Jerez <curroje...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
