All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
	linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	tvrtko.ursulin@linux.intel.com
Subject: Re: [PATCH 24/28] drm: use new iterator in drm_gem_plane_helper_prepare_fb v2
Date: Thu, 21 Oct 2021 13:31:08 +0200	[thread overview]
Message-ID: <YXFPfBL0uSpD33rj@phenom.ffwll.local> (raw)
In-Reply-To: <35416546-b60b-d5cf-7fe9-abaa0dde63e2@gmail.com>

On Tue, Oct 19, 2021 at 05:51:38PM +0200, Christian König wrote:
> Am 19.10.21 um 16:30 schrieb Daniel Vetter:
> > On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote:
> > > Am 13.10.21 um 16:23 schrieb Daniel Vetter:
> > > > On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
> > > > > Makes the handling a bit more complex, but avoids the use of
> > > > > dma_resv_get_excl_unlocked().
> > > > > 
> > > > > v2: improve coding and documentation
> > > > > 
> > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > ---
> > > > >    drivers/gpu/drm/drm_gem_atomic_helper.c | 13 +++++++++++--
> > > > >    1 file changed, 11 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > > > index e570398abd78..8534f78d4d6d 100644
> > > > > --- a/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > > > @@ -143,6 +143,7 @@
> > > > >     */
> > > > >    int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct drm_plane_state *state)
> > > > >    {
> > > > > +	struct dma_resv_iter cursor;
> > > > >    	struct drm_gem_object *obj;
> > > > >    	struct dma_fence *fence;
> > > > > @@ -150,9 +151,17 @@ int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct drm_plane_st
> > > > >    		return 0;
> > > > >    	obj = drm_gem_fb_get_obj(state->fb, 0);
> > > > > -	fence = dma_resv_get_excl_unlocked(obj->resv);
> > > > > -	drm_atomic_set_fence_for_plane(state, fence);
> > > > > +	dma_resv_iter_begin(&cursor, obj->resv, false);
> > > > > +	dma_resv_for_each_fence_unlocked(&cursor, fence) {
> > > > > +		/* TODO: We only use the first write fence here and need to fix
> > > > > +		 * the drm_atomic_set_fence_for_plane() API to accept more than
> > > > > +		 * one. */
> > > > I'm confused, right now there is only one write fence. So no need to
> > > > iterate, and also no need to add a TODO. If/when we add more write fences
> > > > then I think this needs to be revisited, and ofc then we do need to update
> > > > the set_fence helpers to carry an entire array of fences.
> > > Well could be that I misunderstood you, but in your last explanation it
> > > sounded like the drm_atomic_set_fence_for_plane() function needs fixing
> > > anyway because a plane could have multiple BOs.
> > > 
> > > So in my understanding what we need is a
> > > drm_atomic_add_dependency_for_plane() function which records that a certain
> > > fence needs to be signaled before a flip.
> > Yeah that's another issue, but in practice there's no libva which decodes
> > into planar yuv with different fences between the planes. So not a bug in
> > practice.
> > 
> > But this is entirely orthogonal to you picking up the wrong fence here if
> > there's not exclusive fence set:
> > 
> > - old code: Either pick the exclusive fence, or not fence if the exclusive
> >    one is not set.
> > 
> > - new code: Pick the exclusive fence or the first shared fence
> 
> Hui what?
> 
> We use "dma_resv_iter_begin(&cursor, obj->resv, *false*);" here which means
> that only the exclusive fence is returned and no shared fences whatsoever.
> 
> My next step is to replace the boolean with a bunch of use case describing
> enums. I hope that will make it much clearer what's going on here.

Yeah I got that entirely wrong, which is kinda bad since that's about the
only thing worth checking in these conversions :-/

I'll go recheck them again and slap some more r-b on stuff.
-Daniel

> 
> Christian.
> 
> > New behaviour is busted, because scanning out and reading from a buffer at
> > the same time (for the next frame, e.g. to copy over damaged areas or some
> > other tricks) is very much a supported thing. Atomic _only_ wants to look
> > at the exclusive fence slot, which mean "there is an implicitly synced
> > write to this buffers". Implicitly synced reads _must_ be ignored.
> 
> 
> > 
> > Now amdgpu doesn't have this distinction in its uapi, but many drivers do.
> > -Daniel
> > 
> > > Support for more than one write fence then comes totally naturally.
> > > 
> > > Christian.
> > > 
> > > > -Daniel
> > > > 
> > > > > +		dma_fence_get(fence);
> > > > > +		break;
> > > > > +	}
> > > > > +	dma_resv_iter_end(&cursor);
> > > > > +	drm_atomic_set_fence_for_plane(state, fence);
> > > > >    	return 0;
> > > > >    }
> > > > >    EXPORT_SYMBOL_GPL(drm_gem_plane_helper_prepare_fb);
> > > > > -- 
> > > > > 2.25.1
> > > > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
	linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	tvrtko.ursulin@linux.intel.com
Subject: Re: [Intel-gfx] [PATCH 24/28] drm: use new iterator in drm_gem_plane_helper_prepare_fb v2
Date: Thu, 21 Oct 2021 13:31:08 +0200	[thread overview]
Message-ID: <YXFPfBL0uSpD33rj@phenom.ffwll.local> (raw)
In-Reply-To: <35416546-b60b-d5cf-7fe9-abaa0dde63e2@gmail.com>

On Tue, Oct 19, 2021 at 05:51:38PM +0200, Christian König wrote:
> Am 19.10.21 um 16:30 schrieb Daniel Vetter:
> > On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote:
> > > Am 13.10.21 um 16:23 schrieb Daniel Vetter:
> > > > On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
> > > > > Makes the handling a bit more complex, but avoids the use of
> > > > > dma_resv_get_excl_unlocked().
> > > > > 
> > > > > v2: improve coding and documentation
> > > > > 
> > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > ---
> > > > >    drivers/gpu/drm/drm_gem_atomic_helper.c | 13 +++++++++++--
> > > > >    1 file changed, 11 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > > > index e570398abd78..8534f78d4d6d 100644
> > > > > --- a/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > > > > @@ -143,6 +143,7 @@
> > > > >     */
> > > > >    int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct drm_plane_state *state)
> > > > >    {
> > > > > +	struct dma_resv_iter cursor;
> > > > >    	struct drm_gem_object *obj;
> > > > >    	struct dma_fence *fence;
> > > > > @@ -150,9 +151,17 @@ int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct drm_plane_st
> > > > >    		return 0;
> > > > >    	obj = drm_gem_fb_get_obj(state->fb, 0);
> > > > > -	fence = dma_resv_get_excl_unlocked(obj->resv);
> > > > > -	drm_atomic_set_fence_for_plane(state, fence);
> > > > > +	dma_resv_iter_begin(&cursor, obj->resv, false);
> > > > > +	dma_resv_for_each_fence_unlocked(&cursor, fence) {
> > > > > +		/* TODO: We only use the first write fence here and need to fix
> > > > > +		 * the drm_atomic_set_fence_for_plane() API to accept more than
> > > > > +		 * one. */
> > > > I'm confused, right now there is only one write fence. So no need to
> > > > iterate, and also no need to add a TODO. If/when we add more write fences
> > > > then I think this needs to be revisited, and ofc then we do need to update
> > > > the set_fence helpers to carry an entire array of fences.
> > > Well could be that I misunderstood you, but in your last explanation it
> > > sounded like the drm_atomic_set_fence_for_plane() function needs fixing
> > > anyway because a plane could have multiple BOs.
> > > 
> > > So in my understanding what we need is a
> > > drm_atomic_add_dependency_for_plane() function which records that a certain
> > > fence needs to be signaled before a flip.
> > Yeah that's another issue, but in practice there's no libva which decodes
> > into planar yuv with different fences between the planes. So not a bug in
> > practice.
> > 
> > But this is entirely orthogonal to you picking up the wrong fence here if
> > there's not exclusive fence set:
> > 
> > - old code: Either pick the exclusive fence, or not fence if the exclusive
> >    one is not set.
> > 
> > - new code: Pick the exclusive fence or the first shared fence
> 
> Hui what?
> 
> We use "dma_resv_iter_begin(&cursor, obj->resv, *false*);" here which means
> that only the exclusive fence is returned and no shared fences whatsoever.
> 
> My next step is to replace the boolean with a bunch of use case describing
> enums. I hope that will make it much clearer what's going on here.

Yeah I got that entirely wrong, which is kinda bad since that's about the
only thing worth checking in these conversions :-/

I'll go recheck them again and slap some more r-b on stuff.
-Daniel

> 
> Christian.
> 
> > New behaviour is busted, because scanning out and reading from a buffer at
> > the same time (for the next frame, e.g. to copy over damaged areas or some
> > other tricks) is very much a supported thing. Atomic _only_ wants to look
> > at the exclusive fence slot, which mean "there is an implicitly synced
> > write to this buffers". Implicitly synced reads _must_ be ignored.
> 
> 
> > 
> > Now amdgpu doesn't have this distinction in its uapi, but many drivers do.
> > -Daniel
> > 
> > > Support for more than one write fence then comes totally naturally.
> > > 
> > > Christian.
> > > 
> > > > -Daniel
> > > > 
> > > > > +		dma_fence_get(fence);
> > > > > +		break;
> > > > > +	}
> > > > > +	dma_resv_iter_end(&cursor);
> > > > > +	drm_atomic_set_fence_for_plane(state, fence);
> > > > >    	return 0;
> > > > >    }
> > > > >    EXPORT_SYMBOL_GPL(drm_gem_plane_helper_prepare_fb);
> > > > > -- 
> > > > > 2.25.1
> > > > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2021-10-21 11:31 UTC|newest]

Thread overview: 131+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 11:37 Deploying new iterator interface for dma-buf Christian König
2021-10-05 11:37 ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 01/28] dma-buf: add dma_resv_for_each_fence_unlocked v8 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 02/28] dma-buf: add dma_resv_for_each_fence v2 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-06  8:24   ` Christian König
2021-10-06  8:24     ` [Intel-gfx] " Christian König
2021-10-06  8:40   ` Tvrtko Ursulin
2021-10-06  8:40     ` [Intel-gfx] " Tvrtko Ursulin
2021-10-06  8:52     ` Tvrtko Ursulin
2021-10-06  8:52       ` [Intel-gfx] " Tvrtko Ursulin
2021-10-05 11:37 ` [PATCH 03/28] dma-buf: add dma_resv selftest v3 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:04   ` Daniel Vetter
2021-10-13 14:04     ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 04/28] dma-buf: use new iterator in dma_resv_copy_fences Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 05/28] dma-buf: use new iterator in dma_resv_get_fences v3 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 06/28] dma-buf: use new iterator in dma_resv_wait_timeout Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 07/28] dma-buf: use new iterator in dma_resv_test_signaled Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 08/28] dma-buf: use the new iterator in dma_buf_debug_show Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 09/28] dma-buf: use the new iterator in dma_resv_poll Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 10/28] drm/ttm: use the new iterator in ttm_bo_flush_all_fences Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 11/28] drm/amdgpu: use the new iterator in amdgpu_sync_resv Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:06   ` Daniel Vetter
2021-10-13 14:06     ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 12/28] drm/amdgpu: use new iterator in amdgpu_ttm_bo_eviction_valuable Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:07   ` Daniel Vetter
2021-10-13 14:07     ` [Intel-gfx] " Daniel Vetter
2021-10-19 11:36     ` Christian König
2021-10-19 11:36       ` [Intel-gfx] " Christian König
2021-10-19 16:30       ` Felix Kuehling
2021-10-19 16:30         ` [Intel-gfx] " Felix Kuehling
2021-10-21 11:29         ` Daniel Vetter
2021-10-21 11:29           ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 13/28] drm/amdgpu: use new iterator in amdgpu_vm_prt_fini Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:12   ` Daniel Vetter
2021-10-13 14:12     ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 14/28] drm/msm: use new iterator in msm_gem_describe Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:14   ` Daniel Vetter
2021-10-13 14:14     ` [Intel-gfx] " Daniel Vetter
2021-10-19 11:49     ` Christian König
2021-10-19 11:49       ` [Intel-gfx] " Christian König
2021-10-21 11:30       ` Daniel Vetter
2021-10-21 11:30         ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 15/28] drm/radeon: use new iterator in radeon_sync_resv Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:15   ` Daniel Vetter
2021-10-13 14:15     ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 16/28] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-17 14:40   ` Nicolas Frattaroli
2021-10-17 14:40     ` [Intel-gfx] " Nicolas Frattaroli
2021-10-17 15:26     ` Christian König
2021-10-17 15:26       ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 17/28] drm/i915: use the new iterator in i915_gem_busy_ioctl v2 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 12:40   ` Tvrtko Ursulin
2021-10-05 12:40     ` [Intel-gfx] " Tvrtko Ursulin
2021-10-05 12:44     ` Christian König
2021-10-05 12:44       ` [Intel-gfx] " Christian König
2021-10-13 14:19       ` Daniel Vetter
2021-10-13 14:19         ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 18/28] drm/i915: use the new iterator in i915_sw_fence_await_reservation v3 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 19/28] drm/i915: use the new iterator in i915_request_await_object v2 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 20/28] drm/i915: use new iterator in i915_gem_object_wait_reservation Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-14 12:04   ` Maarten Lankhorst
2021-10-14 12:04     ` [Intel-gfx] " Maarten Lankhorst
2021-10-05 11:37 ` [PATCH 21/28] drm/i915: use new iterator in i915_gem_object_wait_priority Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 22/28] drm/i915: use new cursor in intel_prepare_plane_fb Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-05 11:37 ` [PATCH 23/28] drm: use new iterator in drm_gem_fence_array_add_implicit v3 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:21   ` Daniel Vetter
2021-10-13 14:21     ` [Intel-gfx] " Daniel Vetter
2021-10-19 12:54     ` Christian König
2021-10-19 12:54       ` [Intel-gfx] " Christian König
2021-10-19 13:59       ` Daniel Vetter
2021-10-19 13:59         ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 24/28] drm: use new iterator in drm_gem_plane_helper_prepare_fb v2 Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:23   ` Daniel Vetter
2021-10-13 14:23     ` [Intel-gfx] " Daniel Vetter
2021-10-19 13:02     ` Christian König
2021-10-19 13:02       ` [Intel-gfx] " Christian König
2021-10-19 14:30       ` Daniel Vetter
2021-10-19 14:30         ` Daniel Vetter
2021-10-19 15:51         ` Christian König
2021-10-19 15:51           ` [Intel-gfx] " Christian König
2021-10-21 11:31           ` Daniel Vetter [this message]
2021-10-21 11:31             ` Daniel Vetter
2021-10-21 11:33   ` Daniel Vetter
2021-10-21 11:33     ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 25/28] drm/nouveau: use the new iterator in nouveau_fence_sync Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:27   ` Daniel Vetter
2021-10-13 14:27     ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 26/28] drm/nouveau: use the new interator in nv50_wndw_prepare_fb Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:29   ` Daniel Vetter
2021-10-13 14:29     ` [Intel-gfx] " Daniel Vetter
2021-10-22 13:17     ` Christian König
2021-10-22 13:17       ` [Intel-gfx] " Christian König
2021-10-28 15:26       ` Daniel Vetter
2021-10-28 15:26         ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 27/28] drm/etnaviv: use new iterator in etnaviv_gem_describe Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:31   ` Daniel Vetter
2021-10-13 14:31     ` [Intel-gfx] " Daniel Vetter
2021-10-05 11:37 ` [PATCH 28/28] drm/etnaviv: replace dma_resv_get_excl_unlocked Christian König
2021-10-05 11:37   ` [Intel-gfx] " Christian König
2021-10-13 14:32   ` Daniel Vetter
2021-10-13 14:32     ` [Intel-gfx] " Daniel Vetter
2021-10-05 13:27 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/28] dma-buf: add dma_resv_for_each_fence_unlocked v8 Patchwork
2021-10-05 13:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-05 14:01 ` [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=YXFPfBL0uSpD33rj@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.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.