dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 09/11] dma-buf: add shared fence usage flags
Date: Mon, 17 May 2021 22:36:53 +0200	[thread overview]
Message-ID: <YKLT5WO+7dKUVhyP@phenom.ffwll.local> (raw)
In-Reply-To: <20210517141129.2225-10-christian.koenig@amd.com>

On Mon, May 17, 2021 at 04:11:27PM +0200, Christian König wrote:
> Add usage flags for shared fences and improve the documentation.
> 
> This allows driver to better specify what shared fences
> are doing with the resource.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>

> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 16b869d9b1d6..c9bbc4630afc 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -700,7 +700,7 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
>  		return ret;
>  	}
>  
> -	dma_resv_add_shared_fence(bo->base.resv, fence);
> +	dma_resv_add_shared(bo->base.resv, fence, DMA_RESV_USAGE_RW);

Entirely aside, but I ended up scratching my head a lot for why exactly
this here is a shared fence, and why that's ok. Since just looking at this
it seems like waiting for the memory allocation to actually be owned by
this driver is optional.

Is this ok because the next thing we'll do is a move, which will then set
the exclusive fence here. Which will then wait on the shared one here, so
it doesn't matter? Or well, allows us to pipeline the eviction of ttm_man
against whatever might be currently keeping the bo busy in it's current
place?

Might be good candidate to explain this in a comment or something like
that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2021-05-17 20:37 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 14:11 [RFC] Add DMA_RESV_USAGE flags Christian König
2021-05-17 14:11 ` [PATCH 01/11] dma-buf: fix invalid debug print Christian König
2021-05-17 14:11 ` [PATCH 02/11] dma-buf: add SPDX header and fix style in dma-resv.c Christian König
2021-05-17 14:11 ` [PATCH 03/11] dma-buf: cleanup dma-resv shared fence debugging a bit Christian König
2021-05-17 14:11 ` [PATCH 04/11] dma-buf: rename and cleanup dma_resv_get_excl Christian König
2021-05-17 14:11 ` [PATCH 05/11] dma-buf: rename and cleanup dma_resv_get_list Christian König
2021-05-17 14:11 ` [PATCH 06/11] dma-buf: add dma_resv_list_fence helper Christian König
2021-05-17 14:11 ` [PATCH 07/11] dma-buf: add dma_resv_replace_shared Christian König
2021-05-17 14:11 ` [PATCH 08/11] dma-buf: improve shared fence abstraction Christian König
2021-05-17 14:11 ` [PATCH 09/11] dma-buf: add shared fence usage flags Christian König
2021-05-17 20:36   ` Daniel Vetter [this message]
2021-05-18 12:54     ` Christian König
2021-05-17 14:11 ` [PATCH 10/11] drm/i915: also wait for shared dmabuf fences before flip Christian König
2021-05-17 14:11 ` [PATCH 11/11] drm/amdgpu: fix shared access to exported DMA-bufs Christian König
2021-05-17 15:04 ` [RFC] Add DMA_RESV_USAGE flags Daniel Vetter
2021-05-17 19:38   ` Christian König
2021-05-17 20:15     ` Jason Ekstrand
2021-05-17 20:15     ` Daniel Vetter
2021-05-17 22:49       ` Jason Ekstrand
2021-05-18  5:59         ` Daniel Vetter
2021-05-18 10:29           ` Daniel Vetter
2021-05-18 12:49           ` Christian König
2021-05-18 13:26             ` Daniel Stone
2021-05-18 13:51               ` Christian König
2021-05-18 16:48             ` Daniel Vetter
2021-05-18 17:40               ` Christian König
2021-05-18 21:17                 ` Daniel Vetter
2021-05-18 22:06                   ` Jason Ekstrand
2021-05-19 10:52                     ` Michel Dänzer
2021-05-19 15:21                       ` Jason Ekstrand
2021-05-19 15:48                         ` Michel Dänzer
2021-05-20  7:55                           ` Daniel Vetter
2021-05-20  8:13                             ` Michel Dänzer
2021-05-20 10:00                               ` Christian König
2021-05-20 14:18                               ` Daniel Vetter
2021-05-20 14:30                                 ` Michel Dänzer
2021-05-20 17:08                                 ` Jason Ekstrand
2021-05-31 12:49                                 ` Michel Dänzer
2021-05-20 10:50                             ` Christian König
2021-05-20 17:23                               ` Jason Ekstrand
2021-05-20 19:04                                 ` Jason Ekstrand
2021-05-20 19:14                                   ` Daniel Vetter
2021-05-21  7:27                                     ` Christian König
2021-05-21  9:36                                     ` Bas Nieuwenhuizen
2021-05-21  7:24                                 ` Christian König
2021-05-19 11:43                     ` Christian König
2021-05-19 15:35                       ` Jason Ekstrand
2021-05-19 11:24                   ` Christian König
2021-05-20  7:58                     ` Daniel Vetter
2021-05-18 21:31                 ` Dave Airlie

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=YKLT5WO+7dKUVhyP@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).