All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel@ffwll.ch
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: peel dma-fence-chains wait fences
Date: Wed, 29 Jul 2020 14:36:09 +0200	[thread overview]
Message-ID: <20200729123609.GL6419@phenom.ffwll.local> (raw)
In-Reply-To: <20200708131751.334457-4-lionel.g.landwerlin@intel.com>

On Wed, Jul 08, 2020 at 04:17:51PM +0300, Lionel Landwerlin wrote:
> 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.
> 
> v2: Also deal with chains where the last node is not a dma-fence-chain
> 
> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> ---
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 39 ++++++++++++++++++-
>  1 file changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d8814e637e71..3ffd95d1dc2c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2403,6 +2403,7 @@ await_fence_array(struct i915_execbuffer *eb)
>  
>  	for (n = 0; n < eb->n_fences; n++) {
>  		struct drm_syncobj *syncobj;
> +		struct dma_fence_chain *chain;
>  		struct dma_fence *fence;
>  		unsigned int flags;
>  
> @@ -2423,7 +2424,43 @@ await_fence_array(struct i915_execbuffer *eb)
>  				continue;
>  		}
>  
> -		err = i915_request_await_dma_fence(eb->request, fence);
> +		chain = to_dma_fence_chain(fence);
> +		if (chain) {
> +			struct dma_fence *iter;
> +
> +			/*
> +			 * 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.
> +			 */
> +			dma_fence_chain_for_each(iter, fence) {
> +				struct dma_fence_chain *iter_chain =
> +					to_dma_fence_chain(iter);
> +
> +				/*
> +				 * It is possible that the last item in the
> +				 * chain is not a dma_fence_chain.
> +				 */
> +				if (iter_chain) {
> +					err = i915_request_await_dma_fence(eb->request,
> +									   iter_chain->fence);
> +				} else {
> +					err = i915_request_await_dma_fence(eb->request, iter);

I'm kinda wondering whether there should be a limit to how deep we go
before we just give up and wait on the chain, since all we're doing here
(in the worst case at least) is rebuilding the chain.

But hey we can figure this out later on when it actually hurts ...

On the series:

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> +				}
> +				if (err < 0) {
> +					dma_fence_put(iter);
> +					break;
> +				}
> +			}
> +		} else {
> +			err = i915_request_await_dma_fence(eb->request, fence);
> +		}
> +
>  		dma_fence_put(fence);
>  		if (err < 0)
>  			return err;
> -- 
> 2.27.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-07-29 12:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-08 13:17 [Intel-gfx] [PATCH v12 0/3] drm/i915: timeline semaphore support Lionel Landwerlin
2020-07-08 13:17 ` [Intel-gfx] [PATCH v12 1/3] drm/i915: introduce a mechanism to extend execbuf2 Lionel Landwerlin
2020-07-08 13:17 ` [Intel-gfx] [PATCH v12 2/3] drm/i915: add syncobj timeline support Lionel Landwerlin
2020-07-29 12:24   ` Daniel Vetter
2020-07-29 12:24     ` Daniel Vetter
2020-07-29 17:51     ` Linus Torvalds
2020-07-29 17:51       ` Linus Torvalds
2020-07-29 19:19       ` Kees Cook
2020-07-29 19:19         ` Kees Cook
2020-07-29 12:34   ` daniel
2020-07-08 13:17 ` [Intel-gfx] [PATCH v12 3/3] drm/i915: peel dma-fence-chains wait fences Lionel Landwerlin
2020-07-29 12:36   ` daniel [this message]
2020-07-08 14:28 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: timeline semaphore support Patchwork
2020-07-08 14:29 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-07-08 14:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-07-08 17:57 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-07-15 11:11 ` [Intel-gfx] [PATCH v12 0/3] " Lionel Landwerlin
2020-07-22  7:10   ` Lionel Landwerlin

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=20200729123609.GL6419@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --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.