[Mesa-dev] [PATCH 1/6] i965: fix cycle estimates when there's a pipeline stall

[Connor Abbott]

On Wed, Oct 21, 2015 at 7:04 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> I'm not 100% sure if this actually matches the hardware.  It's
> possible that some of the issue time is used to determine interference
> and do the thread switch in which case, there may be some overlap.
> However, it's definitely better than what we had before since, before,
> issue time would get completely over-written if we have a significant
> unblocked_time and that doesn't seem right.

Just FWIW: my understanding is that context switches are completely
atomic, i.e. the EU decides which thread to kick off each cycle and
there's no extra overhead for switching.

>
> Reviewed-by: Jason Ekstrand <jason.ekstrand at intel.com>
>
> On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>> 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.
>>
>> Signed-off-by: Connor Abbott <cwabbott0 at gmail.com>
>> ---
>>  src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 15 ++++++++-------
>>  1 file 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 4e43e5c..76d58e2 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);
>> --
>> 2.1.0
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev