mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-03 18:00:10 +01:00
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>
This commit is contained in:
parent
04c42f3ab5
commit
6f231fddff
1 changed files with 8 additions and 7 deletions
|
|
@ -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);
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue