diff options
author | Eric Anholt <[email protected]> | 2016-11-15 15:47:49 -0800 |
---|---|---|
committer | Eric Anholt <[email protected]> | 2016-11-29 09:01:23 -0800 |
commit | d40a3212aee2c0b2667011f28540cecf000bdea3 (patch) | |
tree | eb01efe31a7fc43b3b62f8cfd2b440e001dfb168 /src/gallium | |
parent | 4690a93b123a64f8730a870a336ae9756d11fd18 (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.c | 20 |
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) |