On 06/07/15 22:36, Kenneth Graunke wrote:
On Monday, July 06, 2015 11:33:15 AM Chris Wilson wrote:
Since the purpose of transform feedback tends to be for the client to
act upon the results to change the geometry in the scene, it is likely
that the client will soon be waiting upon the results. Flush the batch
early so that we don't build up a long queue of commands afterwards that
could delay the readback.
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index 857ebe5..13dbe5b 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
@@ -494,6 +494,12 @@ gen7_end_transform_feedback(struct gl_context *ctx,
brw_batch_end(&brw->batch);
+ /* We will likely want to read the results in the very near future, so
+ * push this primitive to hardware if it is currently idle.
+ */
+ if (!brw_batch_busy(&brw->batch))
+ brw_batch_flush(&brw->batch);
+
/* EndTransformFeedback() means that we need to update the number of
* vertices written. Since it's only necessary if DrawTransformFeedback()
* is called and it means mapping a buffer object, we delay computing it
We need some data to justify this change.
I actually get a negative perf improvement out of this one, -0.9% on a
customer benchmark.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
