summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLionel Landwerlin <lionel.g.landwerlin@intel.com>2017-07-25 17:49:22 +0100
committerLionel Landwerlin <lionel.g.landwerlin@intel.com>2017-07-25 18:56:33 +0100
commit9f439ae1201cb049ffedb9b0e2d4f393fb0a761e (patch)
tree4a51a64eddd48be08bb7adf4759348b78f7a5478
parent45383d32d4fd0265a7133704cb3e6c15620177cd (diff)
i965: perf: flush batchbuffers at the beginning of queries
As Chris commented, it makes more sense to have batch buffer flushes before the query. Usually applications like frame_retrace do a series of queries and in that case, with flushes at the end of the queries, we might still have the first query contained in 2 different batchs. More generally it would be quite usual to have the query contained in 2 batch buffers because we never now what's the fill rate of the current batch buffer. If we move the flushing at the beginning of the queries, it's pretty much guaranteed that queries will be contained in a single batch buffer (unless the amount of commands is huge, but then it's only fair to include reloading request times in the measurements). Fixes: adafe4b733c02 ("i965: perf: minimize the chances to spread queries across batchbuffers") Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: "17.2 17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
-rw-r--r--src/mesa/drivers/dri/i965/brw_performance_query.c16
1 files changed, 8 insertions, 8 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c b/src/mesa/drivers/dri/i965/brw_performance_query.c
index d7902de836c..d8680b48793 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
@@ -1212,6 +1212,14 @@ brw_begin_perf_query(struct gl_context *ctx,
obj->oa.begin_report_id = brw->perfquery.next_query_start_report_id;
brw->perfquery.next_query_start_report_id += 2;
+ /* 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);
+
/* Take a starting OA counter snapshot. */
brw->vtbl.emit_mi_report_perf_count(brw, obj->oa.bo, 0,
obj->oa.begin_report_id);
@@ -1298,14 +1306,6 @@ 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