summaryrefslogtreecommitdiffstats
path: root/src/gallium
diff options
context:
space:
mode:
authorEric Anholt <[email protected]>2016-11-15 15:47:49 -0800
committerEric Anholt <[email protected]>2016-11-29 09:01:23 -0800
commitd40a3212aee2c0b2667011f28540cecf000bdea3 (patch)
treeeb01efe31a7fc43b3b62f8cfd2b440e001dfb168 /src/gallium
parent4690a93b123a64f8730a870a336ae9756d11fd18 (diff)
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.
Diffstat (limited to 'src/gallium')
-rw-r--r--src/gallium/drivers/vc4/vc4_qpu_schedule.c20
1 files changed, 20 insertions, 0 deletions
diff --git a/src/gallium/drivers/vc4/vc4_qpu_schedule.c b/src/gallium/drivers/vc4/vc4_qpu_schedule.c
index 45360f73410..878cdf95d96 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)