From: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: intel-gfx@lists.freedesktop.org, chris.p.wilson@intel.com
Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915: peel dma-fence-chains wait fences
Date: Sun, 12 Apr 2020 18:32:16 -0700 [thread overview]
Message-ID: <20200413013216.GA64842@intel.com> (raw)
In-Reply-To: <2fca650f-baac-2b71-8ab4-e3fc2a4c23fb@intel.com>
On 20/04/11 11:50, Lionel Landwerlin wrote:
> On 10/04/2020 19:51, Venkata Sandeep Dhanalakota wrote:
> > From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >
> > To allow faster engine to engine synchronization, peel the layer of
> > dma-fence-chain to expose potential i915 fences so that the
> > i915-request code can emit HW semaphore wait/signal operations in the
> > ring which is faster than waking up the host to submit unblocked
> > workloads after interrupt notification.
> >
> > Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 39 +++++++++++++++++--
> > 1 file changed, 35 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 8dd651cdca39..e43b76d7e9fd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -2508,6 +2508,7 @@ await_fence_array(struct i915_execbuffer *eb,
> > for (n = 0; n < nfences; n++) {
> > struct drm_syncobj *syncobj;
> > + struct dma_fence_chain *chain;
> > unsigned int flags;
> > syncobj = ptr_unpack_bits(fences[n].syncobj, &flags, 2);
> > @@ -2515,10 +2516,40 @@ await_fence_array(struct i915_execbuffer *eb,
> > if (!fences[n].dma_fence)
> > continue;
> > - err = i915_request_await_dma_fence(eb->request,
> > - fences[n].dma_fence);
> > - if (err < 0)
> > - return err;
> > + /*
> > + * If we're dealing with a dma-fence-chain, peel the chain by
> > + * adding all of the unsignaled fences
> > + * (dma_fence_chain_for_each does that for us) the chain
> > + * points to.
> > + *
> > + * This enables us to identify waits on i915 fences and allows
> > + * for faster engine-to-engine synchronization using HW
> > + * semaphores.
> > + */
> > + chain = to_dma_fence_chain(fences[n].dma_fence);
> > + if (chain) {
> > + struct dma_fence *iter;
> > +
> > + dma_fence_chain_for_each(iter, fences[n].dma_fence) {
>
>
> The kbuild bot made me think of an interesting case.
>
> It is possible to build a chain where the first element isn't a
> dma_fence_chain.
>
Yes agreed, we could have a valid fence-chain with first element as normal
dma_fence and so iter_chain can be null. Will address this in next
revision of the patch.
>
> We should handle this here like this :
>
>
> if (iter_chain)
>
> err = i915_request_await_dma_fence(eb->request, iter_chain->fence);
>
> else
>
> err = i915_request_await_dma_fence(eb->request, iter);
>
> if (err < 0) {
>
> dma_fence_put(iter);
>
> return err;
>
> }
>
>
> > + struct dma_fence_chain *iter_chain =
> > + to_dma_fence_chain(iter);
> > +
> > + GEM_BUG_ON(!iter_chain);
> > +
> > + err = i915_request_await_dma_fence(eb->request,
> > + iter_chain->fence);
> > + if (err < 0) {
> > + dma_fence_put(iter);
> > + return err;
> > + }
> > + }
> > +
> > + } else {
> > + err = i915_request_await_dma_fence(eb->request,
> > + fences[n].dma_fence);
> > + if (err < 0)
> > + return err;
> > + }
> > }
> > return 0;
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-04-13 1:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-10 16:51 [Intel-gfx] [PATCH 1/4] drm/i915: introduce a mechanism to extend execbuf2 Venkata Sandeep Dhanalakota
2020-04-10 16:51 ` [Intel-gfx] [PATCH 2/4] drm/i915: add syncobj timeline support Venkata Sandeep Dhanalakota
2020-04-10 16:51 ` [Intel-gfx] [PATCH 3/4] drm/i915: peel dma-fence-chains wait fences Venkata Sandeep Dhanalakota
2020-04-11 5:09 ` kbuild test robot
2020-04-11 5:09 ` kbuild test robot
2020-04-11 8:50 ` Lionel Landwerlin
2020-04-13 1:32 ` Venkata Sandeep Dhanalakota [this message]
2020-04-10 16:51 ` [Intel-gfx] [PATCH 4/4] drm/selftests: selftest for timeline semaphore Venkata Sandeep Dhanalakota
2020-04-10 21:11 ` kbuild test robot
2020-04-10 21:11 ` kbuild test robot
2020-04-14 13:19 ` Lionel Landwerlin
2020-04-10 16:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: introduce a mechanism to extend execbuf2 Patchwork
2020-04-10 17:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-04-10 17:23 ` [Intel-gfx] ✗ Fi.CI.BAT: 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=20200413013216.GA64842@intel.com \
--to=venkata.s.dhanalakota@intel.com \
--cc=chris.p.wilson@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lionel.g.landwerlin@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.