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

Jason Ekstrand jason at jlekstrand.net
Wed Oct 21 16:04:35 PDT 2015


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.

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


More information about the mesa-dev mailing list