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>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/i915: Track the last-active inside the i915_vma
Date: Thu, 05 Jul 2018 13:02:01 +0100	[thread overview]
Message-ID: <153079212103.2087.6724176038272181337@cwilso3-mobl.ger.intel.com> (raw)
In-Reply-To: <f46d4eb7-5c12-a1ed-f26a-7ecb8b6bbe02@linux.intel.com>

Quoting Tvrtko Ursulin (2018-07-05 12:38:46)
> 
> On 04/07/2018 09:34, Chris Wilson wrote:
> > Using a VMA on more than one timeline concurrently is the exception
> > rather than the rule (using it concurrently on multiple engines). As we
> > expect to only use one active tracker, store the most recently used
> > tracker inside the i915_vma itself and only fallback to the rbtree if
> > we need a second or more concurrent active trackers.
> > 
> > v2: Comments on how we overwrite any existing last_active cache.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_vma.c | 50 +++++++++++++++++++++++++++++++--
> >   drivers/gpu/drm/i915/i915_vma.h |  1 +
> >   2 files changed, 49 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> > index cd94ffc7f079..33925e00f7e8 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -119,6 +119,12 @@ i915_vma_retire(struct i915_gem_active *base, struct i915_request *rq)
> >       __i915_vma_retire(active->vma, rq);
> >   }
> >   
> > +static void
> > +i915_vma_last_retire(struct i915_gem_active *base, struct i915_request *rq)
> > +{
> > +     __i915_vma_retire(container_of(base, struct i915_vma, last_active), rq);
> > +}
> > +
> >   static struct i915_vma *
> >   vma_create(struct drm_i915_gem_object *obj,
> >          struct i915_address_space *vm,
> > @@ -136,6 +142,7 @@ vma_create(struct drm_i915_gem_object *obj,
> >   
> >       vma->active = RB_ROOT;
> >   
> > +     init_request_active(&vma->last_active, i915_vma_last_retire);
> >       init_request_active(&vma->last_fence, NULL);
> >       vma->vm = vm;
> >       vma->ops = &vm->vma_ops;
> > @@ -895,6 +902,22 @@ static struct i915_gem_active *lookup_active(struct i915_vma *vma, u64 idx)
> >   {
> >       struct i915_vma_active *active;
> >       struct rb_node **p, *parent;
> > +     struct i915_request *old;
> > +
> > +     /*
> > +      * We track the most recently used timeline to skip a rbtree search
> > +      * for the common case, under typical loads we never need the rbtree
> > +      * at all. We can reuse the last_active slot if it is empty, that is
> > +      * after the previous activity has been retired, or if the active
> > +      * matches the current timeline.
> > +      */
> > +     old = i915_gem_active_raw(&vma->last_active,
> > +                               &vma->vm->i915->drm.struct_mutex);
> > +     if (!old || old->fence.context == idx)
> > +             goto out;
> 
> Is the situation that retire can be out of order relative to 
> move_to_active? In other words, last_active can retire before the rbtree 
> record, and so the following new move_to_active will find last_active 
> empty and so could create a double entry for the same timeline?

We don't mind a double entry, and do expect that last_active and the
rbtree entry will still be active, tracking different requests.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-07-05 12:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 22:54 [PATCH 1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active() Chris Wilson
2018-06-29 22:54 ` [PATCH 2/6] drm/i915: Export i915_request_skip() Chris Wilson
2018-07-02 11:37   ` Tvrtko Ursulin
2018-06-29 22:54 ` [PATCH 3/6] drm/i915: Start returning an error from i915_vma_move_to_active() Chris Wilson
2018-07-02 11:41   ` Tvrtko Ursulin
2018-06-29 22:54 ` [PATCH 4/6] drm/i915: Move i915_vma_move_to_active() to i915_vma.c Chris Wilson
2018-07-02 11:41   ` Tvrtko Ursulin
2018-06-29 22:54 ` [PATCH 5/6] drm/i915: Track vma activity per fence.context, not per engine Chris Wilson
2018-07-03 17:28   ` Tvrtko Ursulin
2018-07-03 20:29     ` Chris Wilson
2018-07-04  9:43       ` Tvrtko Ursulin
2018-07-04  9:53         ` Chris Wilson
2018-07-04  9:13   ` [PATCH v3] " Chris Wilson
2018-07-04 11:19     ` Tvrtko Ursulin
2018-06-29 22:54 ` [PATCH 6/6] drm/i915: Track the last-active inside the i915_vma Chris Wilson
2018-07-03 17:40   ` Tvrtko Ursulin
2018-07-04  8:34   ` [PATCH v2] " Chris Wilson
2018-07-04  9:39     ` Tvrtko Ursulin
2018-07-04 11:34       ` Tvrtko Ursulin
2018-07-04 11:47         ` Chris Wilson
2018-07-04 12:30           ` Tvrtko Ursulin
2018-07-05 11:38     ` Tvrtko Ursulin
2018-07-05 12:02       ` Chris Wilson [this message]
2018-07-05 12:29         ` Tvrtko Ursulin
2018-07-05 12:48           ` Chris Wilson
2018-06-29 23:04 ` ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active() Patchwork
2018-06-29 23:19 ` ✓ Fi.CI.BAT: success " Patchwork
2018-06-30  3:03 ` ✓ Fi.CI.IGT: " Patchwork
2018-07-02 11:34 ` [PATCH 1/6] " Tvrtko Ursulin
2018-07-02 11:44   ` Chris Wilson
2018-07-02 12:29     ` Tvrtko Ursulin
2018-07-04  8:52 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active() (rev2) Patchwork
2018-07-04  8:55 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-07-04  9:07 ` ✓ Fi.CI.BAT: success " Patchwork
2018-07-04  9:34 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active() (rev3) Patchwork
2018-07-04  9:37 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-07-04  9:49 ` ✓ Fi.CI.BAT: success " Patchwork
2018-07-04 10:43 ` ✓ Fi.CI.IGT: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2018-06-29  7:53 [PATCH 18/37] drm/i915: Track the last-active inside the i915_vma Chris Wilson
2018-06-29 22:01 ` [PATCH v2] " Chris Wilson

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=153079212103.2087.6724176038272181337@cwilso3-mobl.ger.intel.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.