Quoting Lionel Landwerlin (2017-06-22 02:25:28) > 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);
Doesn't this make more sense before the start of the perf-query, because you want the bookkends in the same batch? Flushing afterwards does nothing to improve the likelihood of this query being contained. > --brw->perfquery.n_active_oa_queries; > > /* NB: even though the query has now ended, it can't be accumulated > -- > 2.11.0 > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
