All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: "Chang, Bruce" <yu.bruce.chang@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Incrementally check for rewinding
Date: Wed, 10 Jun 2020 15:03:58 +0100	[thread overview]
Message-ID: <159179783861.19008.3331899086436292993@build.alporthouse.com> (raw)
In-Reply-To: <bf5c088a-731a-7bc4-ff90-492f18e55045@intel.com>

Quoting Chang, Bruce (2020-06-10 05:25:39)
> On 6/9/2020 8:17 AM, Chris Wilson wrote:
> > In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context
> > reload when rewinding RING_TAIL"), we placed the check for rewinding a
> > context on actually submitting the next request in that context. This
> > was so that we only had to check once, and could do so with precision
> > avoiding as many forced restores as possible. For example, to ensure
> > that we can resubmit the same request a couple of times, we include a
> > small wa_tail such that on the next submission, the ring->tail will
> > appear to move forwards when resubmitting the same request. This is very
> > common as it will happen for every lite-restore to fill the second port
> > after a context switch.
> >
> > However, intel_ring_direction() is limited in precision to movements of
> > upto half the ring size. The consequence being that if we tried to
> > unwind many requests, we could exceed half the ring and flip the sense
> > of the direction, so missing a force restore. As no request can be
> > greater than half the ring (i.e. 2048 bytes in the smallest case), we
> > can check for rollback incrementally. As we check against the tail that
> > would be submitted, we do not lose any sensitivity and allow lite
> > restores for the simple case. We still need to double check upon
> > submitting the context, to allow for multiple preemptions and
> > resubmissions.
> >
> > Fixes: 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > Cc: <stable@vger.kernel.org> # v5.4+
> 
> Verified this has fixed the issue regarding the GPU hang with incomplete 
> error state.

But it does not entirely... tgl b0 still has the issue of a lite restore
being processed while it is doing an [implicit] semaphore wait at just
the wrong time, dies (or something that looks suspiciously like that).
That can be reproduced without any preemption rollback, so I suspect a
placebo effect.
-Chris

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: "Chang, Bruce" <yu.bruce.chang@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Incrementally check for rewinding
Date: Wed, 10 Jun 2020 15:03:58 +0100	[thread overview]
Message-ID: <159179783861.19008.3331899086436292993@build.alporthouse.com> (raw)
In-Reply-To: <bf5c088a-731a-7bc4-ff90-492f18e55045@intel.com>

Quoting Chang, Bruce (2020-06-10 05:25:39)
> On 6/9/2020 8:17 AM, Chris Wilson wrote:
> > In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context
> > reload when rewinding RING_TAIL"), we placed the check for rewinding a
> > context on actually submitting the next request in that context. This
> > was so that we only had to check once, and could do so with precision
> > avoiding as many forced restores as possible. For example, to ensure
> > that we can resubmit the same request a couple of times, we include a
> > small wa_tail such that on the next submission, the ring->tail will
> > appear to move forwards when resubmitting the same request. This is very
> > common as it will happen for every lite-restore to fill the second port
> > after a context switch.
> >
> > However, intel_ring_direction() is limited in precision to movements of
> > upto half the ring size. The consequence being that if we tried to
> > unwind many requests, we could exceed half the ring and flip the sense
> > of the direction, so missing a force restore. As no request can be
> > greater than half the ring (i.e. 2048 bytes in the smallest case), we
> > can check for rollback incrementally. As we check against the tail that
> > would be submitted, we do not lose any sensitivity and allow lite
> > restores for the simple case. We still need to double check upon
> > submitting the context, to allow for multiple preemptions and
> > resubmissions.
> >
> > Fixes: 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > Cc: <stable@vger.kernel.org> # v5.4+
> 
> Verified this has fixed the issue regarding the GPU hang with incomplete 
> error state.

But it does not entirely... tgl b0 still has the issue of a lite restore
being processed while it is doing an [implicit] semaphore wait at just
the wrong time, dies (or something that looks suspiciously like that).
That can be reproduced without any preemption rollback, so I suspect a
placebo effect.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-06-10 14:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09 12:28 [PATCH] drm/i915/gt: Incrementally check for rewinding Chris Wilson
2020-06-09 12:28 ` [Intel-gfx] " Chris Wilson
2020-06-09 12:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2020-06-09 13:08 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-06-09 14:10 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-06-09 15:15 ` [PATCH] " Chris Wilson
2020-06-09 15:15   ` [Intel-gfx] " Chris Wilson
2020-06-09 15:17 ` Chris Wilson
2020-06-09 15:17   ` [Intel-gfx] " Chris Wilson
2020-06-10  4:25   ` Chang, Bruce
2020-06-10  4:25     ` Chang, Bruce
2020-06-10 14:03     ` Chris Wilson [this message]
2020-06-10 14:03       ` Chris Wilson
2020-06-10 12:39   ` Mika Kuoppala
2020-06-10 12:39     ` [Intel-gfx] " Mika Kuoppala
2020-06-09 15:37 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Incrementally check for rewinding (rev2) Patchwork
2020-06-09 15:58 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-06-09 18:30 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=159179783861.19008.3331899086436292993@build.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stable@vger.kernel.org \
    --cc=yu.bruce.chang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.