All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 05/16] drm/i915: track ring progression using seqnos
Date: Mon, 22 Apr 2013 16:36:22 +0300	[thread overview]
Message-ID: <8761ze7kmh.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20130421210749.GB5587@bwidawsk.net>

Ben Widawsky <ben@bwidawsk.net> writes:

> On Sat, Apr 20, 2013 at 11:43:51AM -0700, Ben Widawsky wrote:
>> On Thu, Apr 04, 2013 at 06:32:37PM +0300, Mika Kuoppala wrote:
>> > Instead of relying in acthd, track ring seqno progression
>> > to detect if ring has hung.
>> > 
>> > v2: put hangcheck stuff inside struct (Chris Wilson)
>> > 
>> > Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>> 
>> This patch really scares me. I think we don't want to ever stop using
>> ACTHD. AFAICT, ACTHD is aways something we want to track in regards to
>> the GPU not making progress. (unless we're worried about cycles in the
>> CS, but there, seqno would equally not help us track progress).
>> 
>> The two danger cases are:
>> an infinite loop in a shader
>> never called MI_BATCH_BUFFER_END
>> 
>> And for both, *I think* ACTHD won't change.
>
> I'm wrong. I was confusing HEAD with ACTHD. ACTHD is supposed to show
> the address of either the batch, or the ring. HEAD is something we could
> use instead though. Just a thought.

Yes, i confirmed this with my test case. ACTHD will change inside the 
ring and also inside the batchbuffer.

The reason I chose seqnos is because that is the least hw (gen)
dependant way to measure the if progress is being made.
And such most close of what userspace sees as progress.
If batch doesn't get retired for whatever reason, reset will happen.

This way we can detect hangs, looped batchbuffers and infinite,
or more precisely too long loops, inside shaders.

I will need to update the commit message to reflect
the fact that with this patch, the batch needs to complete
in 3 second time window.

-Mika


>> 
>> I believe what the patch really wants is to stop using instdone, but
>> continue to use ACTHD as a fallback.
>> 
>> I think if you can keep ACTHD around, I'd be willing to r-b this.
>> 
>> Discussion moved to IRC.
>> 
>> 
>> [snip]
>> -- 
>> Ben Widawsky, Intel Open Source Technology Center
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Ben Widawsky, Intel Open Source Technology Center

  reply	other threads:[~2013-04-22 13:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-04 15:32 [PATCH v3 00/16] arb robustness enablers v3 Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 01/16] drm/i915: return context from i915_switch_context() Mika Kuoppala
2013-04-20 18:10   ` Ben Widawsky
2013-04-04 15:32 ` [PATCH v3 02/16] drm/i915: cleanup i915_add_request Mika Kuoppala
2013-04-20 18:36   ` Ben Widawsky
2013-04-04 15:32 ` [PATCH v3 03/16] drm/i915: reference count for i915_hw_contexts Mika Kuoppala
2013-04-09 22:18   ` Chris Wilson
2013-04-10  0:12     ` [PATCH] " Ben Widawsky
2013-04-20 18:11       ` Ben Widawsky
2013-04-04 15:32 ` [PATCH v3 04/16] drm/i915: pass seqno to i915_hangcheck_ring_idle Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 05/16] drm/i915: track ring progression using seqnos Mika Kuoppala
2013-04-20 18:43   ` Ben Widawsky
2013-04-21 21:07     ` Ben Widawsky
2013-04-22 13:36       ` Mika Kuoppala [this message]
2013-04-04 15:32 ` [PATCH v3 06/16] drm/i915: introduce i915_hangcheck_ring_hung Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 07/16] drm/i915: detect hang using per ring hangcheck_score Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 08/16] drm/i915: remove i915_hangcheck_hung Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 09/16] drm/i915: add struct i915_ctx_hang_stats Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 10/16] drm/i915: add i915_gem_context_get_hang_stats() Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 11/16] drm/i915: add batch object and context to i915_add_request() Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 12/16] drm/i915: mark rings which were waiting when hang happened Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 13/16] drm/i915: find guilty batch buffer on ring resets Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 14/16] drm/i915: refuse to submit more batchbuffers from guilty context Mika Kuoppala
2013-04-11 15:13   ` Mika Kuoppala
2013-04-16 11:32   ` [PATCH " Mika Kuoppala
2013-04-16 13:59     ` Chris Wilson
2013-04-17 10:11       ` [PATCH v3 " Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 15/16] drm/i915: add i915_reset_count Mika Kuoppala
2013-04-04 15:32 ` [PATCH v3 16/16] drm/i915: add i915_get_reset_stats_ioctl Mika Kuoppala
2013-04-24 23:27 ` [PATCH v3 00/16] arb robustness enablers v3 Ben Widawsky

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=8761ze7kmh.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=ben@bwidawsk.net \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.