On Wednesday, June 21, 2017 6:25:28 PM PDT Lionel Landwerlin wrote: > Counter related to timings will be sensitive to any delay introduced > by the software. In particular if our begin & end of performance > queries end up in different batches, time related counters will > exhibit biffer values caused by the time it takes for the kernel > driver to load new requests into the hardware. > > Signed-off-by: Lionel Landwerlin <lionel.g.landwer...@intel.com> > --- > src/mesa/drivers/dri/i965/brw_performance_query.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c > b/src/mesa/drivers/dri/i965/brw_performance_query.c > index 06576a54d03..6b874d0bbee 100644 > --- a/src/mesa/drivers/dri/i965/brw_performance_query.c > +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c > @@ -1063,6 +1063,14 @@ brw_end_perf_query(struct gl_context *ctx, > obj->oa.begin_report_id + 1); > } > > + /* We flush the batchbuffer here to minimize the chances that MI_RPC > + * delimiting commands end up in different batchbuffers. If that's the > + * case, the measurement will include the time it takes for the kernel > + * scheduler to load a new request into the hardware. This is > manifested > + * in tools like frameretrace by spikes in the "GPU Core Clocks" > + * counter. > + */ > + intel_batchbuffer_flush(brw); > --brw->perfquery.n_active_oa_queries; > > /* NB: even though the query has now ended, it can't be accumulated >
Seems reasonable to me. Acked-by: Kenneth Graunke <kenn...@whitecape.org>
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
