From: Jeff McGee <jeff.mcgee@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/guc: Disable preemption if it fails
Date: Fri, 1 Jun 2018 17:02:03 -0700 [thread overview]
Message-ID: <20180602000203.GA20105@jeffdesk> (raw)
In-Reply-To: <152780165421.15728.3421740484375164024@mail.alporthouse.com>
On Thu, May 31, 2018 at 10:20:54PM +0100, Chris Wilson wrote:
> Quoting Singh, Satyeshwar (2018-05-31 22:17:25)
> > Hi Chris,
> > Isn't this dependent upon the workload submitted to the GuC? Meaning we have one workload that refused to be preempted (really long shader for example) but it went away on its own. Other workloads that come in later are preemptible. However, if we turn off preemption permanently, then all future workloads will not be preempted either which may not be desirable.
>
> Whoever implements the recovery mechanism can clear the flag. You may
> like to clear the flag on reset? We would have to be more careful about
> the manipulation of engine->flags as it's not serialised atm (since it's
> _meant_ to be write-once during init).
> -Chris
The error that would occur here is a failure of GuC to *initiate* the
preemption, and is different from a slow resolution of the preemption on
hardware caused by the workload blocking scenario that Satyeshwar
describes. GuC will wait forever for preemption resolution, as will i915
currently without a timeout mechanism. A failure of GuC to initiate a
preemption would be a very strange and bad thing and probably would
warrant a WARN and disabling. Is anyone actually seeing that with current
firmware? I have not in my own testing. Is it an actual error returned
from GuC or a timeout waiting for GuC response?
-Jeff
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2018-06-02 0:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-31 20:47 [PATCH] drm/i915/guc: Disable preemption if it fails Chris Wilson
2018-05-31 20:57 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-05-31 21:13 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-31 21:16 ` [PATCH] " Michel Thierry
2018-05-31 21:17 ` Singh, Satyeshwar
2018-05-31 21:20 ` Chris Wilson
2018-06-02 0:02 ` Jeff McGee [this message]
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=20180602000203.GA20105@jeffdesk \
--to=jeff.mcgee@intel.com \
--cc=chris@chris-wilson.co.uk \
--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.