Mesa (master): vc4: Add a note for the future about texture latency calculation.
Eric Anholt
anholt at kemper.freedesktop.org
Tue Nov 29 17:04:59 UTC 2016
Module: Mesa
Branch: master
Commit: d40a3212aee2c0b2667011f28540cecf000bdea3
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d40a3212aee2c0b2667011f28540cecf000bdea3
Author: Eric Anholt <eric at anholt.net>
Date: Tue Nov 15 15:47:49 2016 -0800
vc4: Add a note for the future about texture latency calculation.
Debugging a shader-db reported cycle count regression from the tex
coalescing, I eventually figured out that the texture latencies were
totally bogus. Really fixing it will probably involve mirroring
vc4_qir_schedule.c's texture fifo management here.
---
src/gallium/drivers/vc4/vc4_qpu_schedule.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/vc4/vc4_qpu_schedule.c b/src/gallium/drivers/vc4/vc4_qpu_schedule.c
index 45360f7..878cdf9 100644
--- a/src/gallium/drivers/vc4/vc4_qpu_schedule.c
+++ b/src/gallium/drivers/vc4/vc4_qpu_schedule.c
@@ -705,6 +705,26 @@ static uint32_t waddr_latency(uint32_t waddr, uint64_t after)
/* Apply some huge latency between texture fetch requests and getting
* their results back.
+ *
+ * FIXME: This is actually pretty bogus. If we do:
+ *
+ * mov tmu0_s, a
+ * <a bit of math>
+ * mov tmu0_s, b
+ * load_tmu0
+ * <more math>
+ * load_tmu0
+ *
+ * we count that as worse than
+ *
+ * mov tmu0_s, a
+ * mov tmu0_s, b
+ * <lots of math>
+ * load_tmu0
+ * <more math>
+ * load_tmu0
+ *
+ * because we associate the first load_tmu0 with the *second* tmu0_s.
*/
if (waddr == QPU_W_TMU0_S) {
if (QPU_GET_FIELD(after, QPU_SIG) == QPU_SIG_LOAD_TMU0)
More information about the mesa-commit
mailing list