diff options
author | Connor Abbott <[email protected]> | 2015-06-05 19:20:57 -0400 |
---|---|---|
committer | Connor Abbott <[email protected]> | 2015-10-30 02:18:53 -0400 |
commit | 6f231fddff1661c2ca2cfb7bb7a0e6a970bcbf40 (patch) | |
tree | fa2ab86c12d4760947fdd7a671651e182ffe0c90 /src/mesa/drivers | |
parent | 04c42f3ab56a19089b46dea48615aeef8b8225da (diff) |
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 <[email protected]>
Diffstat (limited to 'src/mesa/drivers')
-rw-r--r-- | src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 15 |
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 cd1f21e1253..3e86cb05cce 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); |