On Wed, Oct 21, 2015 at 7:04 PM, Jason Ekstrand <ja...@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.ekstr...@intel.com>
>
> On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott <cwabbo...@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 <cwabbo...@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@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
