All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 06/14] drm/i915: Protect the request->global_seqno with the engine->timeline lock
Date: Wed, 22 Feb 2017 12:38:22 +0000	[thread overview]
Message-ID: <20170222123822.GQ10557@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <95425e59-6379-ef25-4b83-3e15e4b613c9@linux.intel.com>

On Fri, Feb 17, 2017 at 02:43:05PM +0000, Tvrtko Ursulin wrote:
> 
> On 14/02/2017 09:54, Chris Wilson wrote:
> >@@ -947,7 +948,11 @@ bool __i915_spin_request(const struct drm_i915_gem_request *req,
> >
> > 	timeout_us += local_clock_us(&cpu);
> > 	do {
> >-		if (__i915_gem_request_completed(req))
> >+		if (seqno != i915_gem_request_global_seqno(req))
> >+			break;
> 
> You don't want to keep spinning for the allotted timeslice after the
> seqno transitions from zero to something and if is the currently
> executing seqno?

The intent was that we only spin for the active (on hw) request. If it
was removed from the execution queue, it is unlikely(?) to be put back
as the next request.

Yes, I'd love to spin out the timeslice, used to give some nice boosts
to some synmarks that kept hitting readbacks. Hopefully, they've been
fixed now to use gpu pipelines!

> >@@ -1073,7 +1081,8 @@ long i915_wait_request(struct drm_i915_gem_request *req,
> >
> > 		timeout = io_schedule_timeout(timeout);
> >
> >-		if (intel_wait_complete(&wait))
> >+		if (intel_wait_complete(&wait) &&
> >+		    i915_gem_request_global_seqno(req) == wait.seqno)
> > 			break;
> 
> Hm, the second part of the conditional sounds like it is always
> true. Since we know seqno is not zero, given that the first part of
> the wait has completed, so it has to be the expected one at this
> point. Otherwise a GEM_BUG_ON that it is different. Or I missed
> something?

Yes. We are preparing for global_seqno changing mid-wait due to request
reordering
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-22 12:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-14  9:53 Prep work for preemption and GEM bugfixes Chris Wilson
2017-02-14  9:54 ` [PATCH v2 01/14] drm/i915: Keep a global seqno per-engine Chris Wilson
2017-02-15 17:05   ` Tvrtko Ursulin
2017-02-15 21:49     ` Chris Wilson
2017-02-15 22:20       ` Chris Wilson
2017-02-15 22:36       ` Chris Wilson
2017-02-16  8:10       ` Tvrtko Ursulin
2017-02-16  8:28         ` Chris Wilson
2017-02-14  9:54 ` [PATCH v2 02/14] drm/i915: Use a local to shorten req->i915->gpu_error.wait_queue Chris Wilson
2017-02-15 17:06   ` Tvrtko Ursulin
2017-02-14  9:54 ` [PATCH v2 03/14] drm/i915: Add ourselves to the gpu error waitqueue for the entire wait Chris Wilson
2017-02-15 17:11   ` Tvrtko Ursulin
2017-02-14  9:54 ` [PATCH v2 04/14] drm/i915: Inline __i915_gem_request_wait_for_execute() Chris Wilson
2017-02-17 14:04   ` Tvrtko Ursulin
2017-02-14  9:54 ` [PATCH v2 05/14] drm/i915: Deconstruct execute fence Chris Wilson
2017-02-17 14:26   ` Tvrtko Ursulin
2017-02-17 14:41     ` Chris Wilson
2017-02-17 14:55       ` Tvrtko Ursulin
2017-02-14  9:54 ` [PATCH v2 06/14] drm/i915: Protect the request->global_seqno with the engine->timeline lock Chris Wilson
2017-02-17 14:43   ` Tvrtko Ursulin
2017-02-22 12:38     ` Chris Wilson [this message]
2017-02-14  9:54 ` [PATCH v2 07/14] drm/i915: Take a reference whilst processing the signaler request Chris Wilson
2017-02-14  9:54 ` [PATCH v2 08/14] drm/i915: Allow an request to be cancelled Chris Wilson
2017-02-14  9:54 ` [PATCH v2 09/14] drm/i915: Remove the preempted request from the execution queue Chris Wilson
2017-02-14  9:54 ` [PATCH v2 10/14] drm/i915: Exercise request cancellation using a mock selftest Chris Wilson
2017-02-14  9:54 ` [PATCH v2 11/14] drm/i915: Replace reset_wait_queue with default_wake_function Chris Wilson
2017-02-14  9:54 ` [PATCH v2 12/14] drm/i915: Refactor direct GPU reset from request waiters Chris Wilson
2017-02-14  9:54 ` [PATCH v2 13/14] drm/i915: Immediately process a reset before starting waiting Chris Wilson
2017-02-14  9:54 ` [PATCH v2 14/14] drm/i915: Remove one level of indention from wait-for-execute Chris Wilson
2017-02-14 11:52 ` ✓ Fi.CI.BAT: success for series starting with [v2,01/14] drm/i915: Keep a global seqno per-engine 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=20170222123822.GQ10557@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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.