summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
diff options
context:
space:
mode:
authorConnor Abbott <cwabbott0@gmail.com>2015-06-05 19:20:57 -0400
committerConnor Abbott <cwabbott0@gmail.com>2015-10-30 02:18:53 -0400
commit6f231fddff1661c2ca2cfb7bb7a0e6a970bcbf40 (patch)
treefa2ab86c12d4760947fdd7a671651e182ffe0c90 /src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
parent04c42f3ab56a19089b46dea48615aeef8b8225da (diff)
downloadexternal_mesa3d-6f231fddff1661c2ca2cfb7bb7a0e6a970bcbf40.zip
external_mesa3d-6f231fddff1661c2ca2cfb7bb7a0e6a970bcbf40.tar.gz
external_mesa3d-6f231fddff1661c2ca2cfb7bb7a0e6a970bcbf40.tar.bz2
i965: fix cycle estimates when there's a pipeline stall
The issue time for an instruction is how many cycles it takes to actually put it into the pipeline. If there's a pipeline stall that causes the instruction to be delayed, we should first take that into account to figure out when the instruction would start executing and *then* add the issue time. The old code had it backwards, and so we would underestimate the total time whenever we thought there would be a pipeline stall by up to the issue time of the instruction. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Diffstat (limited to 'src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp')
-rw-r--r--src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp15
1 files changed, 8 insertions, 7 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index cd1f21e..3e86cb0 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -1405,18 +1405,19 @@ instruction_scheduler::schedule_instructions(bblock_t *block)
instructions_to_schedule--;
update_register_pressure(chosen->inst);
+ /* If we expected a delay for scheduling, then bump the clock to reflect
+ * that. In reality, the hardware will switch to another hyperthread
+ * and may not return to dispatching our thread for a while even after
+ * we're unblocked. After this, we have the time when the chosen
+ * instruction will start executing.
+ */
+ time = MAX2(time, chosen->unblocked_time);
+
/* Update the clock for how soon an instruction could start after the
* chosen one.
*/
time += issue_time(chosen->inst);
- /* If we expected a delay for scheduling, then bump the clock to reflect
- * that as well. In reality, the hardware will switch to another
- * hyperthread and may not return to dispatching our thread for a while
- * even after we're unblocked.
- */
- time = MAX2(time, chosen->unblocked_time);
-
if (debug) {
fprintf(stderr, "clock %4d, scheduled: ", time);
bs->dump_instruction(chosen->inst);