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