All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	daniel.vetter@ffwll.ch, sumit.semwal@linaro.org,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Subject: [RFC] replacing dma_resv API
Date: Wed, 21 Aug 2019 14:31:37 +0200	[thread overview]
Message-ID: <20190821123147.110736-1-christian.koenig@amd.com> (raw)

Hi everyone,

In previous discussion it surfaced that different drivers use the shared and explicit fences in the dma_resv object with different meanings.

This is problematic when we share buffers between those drivers and requirements for implicit and explicit synchronization leaded to quite a number of workarounds related to this.

So I started an effort to get all drivers back to a common understanding of what the fences in the dma_resv object mean and be able to use the object for different kind of workloads independent of the classic DRM command submission interface.

The result is this patch set which modifies the dma_resv API to get away from a single explicit fence and multiple shared fences, towards a notation where we have explicit categories for writers, readers and others.

To do this I came up with a new container called dma_resv_fences which can store both a single fence as well as multiple fences in a dma_fence_array.

This turned out to actually be even be quite a bit simpler, since we don't need any complicated dance between RCU and sequence count protected updates any more.

Instead we can just grab a reference to the dma_fence_array under RCU and so keep the current state of synchronization alive until we are done with it.

This results in both a small performance improvement since we don't need so many barriers any more, as well as fewer lines of code in the actual implementation.

Please review and/or comment,
Christian. 



WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	daniel.vetter@ffwll.ch, sumit.semwal@linaro.org,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Subject: [RFC] replacing dma_resv API
Date: Wed, 21 Aug 2019 14:31:37 +0200	[thread overview]
Message-ID: <20190821123147.110736-1-christian.koenig@amd.com> (raw)

Hi everyone,

In previous discussion it surfaced that different drivers use the shared and explicit fences in the dma_resv object with different meanings.

This is problematic when we share buffers between those drivers and requirements for implicit and explicit synchronization leaded to quite a number of workarounds related to this.

So I started an effort to get all drivers back to a common understanding of what the fences in the dma_resv object mean and be able to use the object for different kind of workloads independent of the classic DRM command submission interface.

The result is this patch set which modifies the dma_resv API to get away from a single explicit fence and multiple shared fences, towards a notation where we have explicit categories for writers, readers and others.

To do this I came up with a new container called dma_resv_fences which can store both a single fence as well as multiple fences in a dma_fence_array.

This turned out to actually be even be quite a bit simpler, since we don't need any complicated dance between RCU and sequence count protected updates any more.

Instead we can just grab a reference to the dma_fence_array under RCU and so keep the current state of synchronization alive until we are done with it.

This results in both a small performance improvement since we don't need so many barriers any more, as well as fewer lines of code in the actual implementation.

Please review and/or comment,
Christian. 


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2019-08-21 12:31 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 12:31 Christian König [this message]
2019-08-21 12:31 ` [RFC] replacing dma_resv API Christian König
2019-08-21 12:31 ` [PATCH 01/10] dma-buf: make to_dma_fence_array NULL safe Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 12:31 ` [PATCH 02/10] dma-buf: add dma_fence_array_alloc/free Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 12:31 ` [PATCH 03/10] dma-buf: add dma_fence_array_recycle Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 16:24   ` Chris Wilson
2019-08-21 16:24     ` Chris Wilson
2019-08-22  8:38     ` Christian König
2019-08-22  8:38       ` Christian König
2019-08-21 12:31 ` [PATCH 04/10] dma-buf: add dma_fence_array_for_each Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 12:31 ` [PATCH 05/10] dma-buf/resv: add dma_resv_prune_fences Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 14:55   ` Chris Wilson
2019-08-21 14:55     ` Chris Wilson
2019-08-21 14:56     ` Chris Wilson
2019-08-21 14:56       ` Chris Wilson
2019-08-21 12:31 ` [PATCH 06/10] dma-buf/resv: stop pruning shared fences when exclusive is added Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 12:31 ` [PATCH 07/10] dma-buf/resv: add new fences container implementation Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 16:04   ` Daniel Vetter
2019-08-21 16:04     ` Daniel Vetter
2019-08-22  8:23     ` Christian König
2019-08-22  8:23       ` Christian König
2019-08-22 13:02       ` Daniel Vetter
2019-08-22 13:02         ` Daniel Vetter
2019-08-22 13:53         ` Koenig, Christian
2019-08-22 13:53           ` Koenig, Christian
2019-08-21 12:31 ` [PATCH 08/10] dma-buf/resv: replace shared fence with new fences container Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 15:24   ` Chris Wilson
2019-08-21 15:24     ` Chris Wilson
2019-08-21 17:35     ` Chris Wilson
2019-08-21 17:35       ` Chris Wilson
2019-08-22  8:37       ` Christian König
2019-08-22  8:37         ` Christian König
2019-08-22  9:16         ` Christian König
2019-08-22  9:16           ` Christian König
2019-08-21 16:21   ` Chris Wilson
2019-08-21 16:21     ` Chris Wilson
2019-08-24 13:22   ` Chris Wilson
2019-08-24 13:22     ` Chris Wilson
2019-08-21 12:31 ` [PATCH 09/10] dma-buf/resv: replace exclusive " Christian König
2019-08-21 12:31   ` Christian König
2019-08-21 12:31 ` [PATCH 10/10] dma-buf/resv: add other operations Christian König
2019-08-21 12:31   ` Christian König
2019-08-22 12:28   ` Ville Syrjälä
2019-08-22 12:28     ` Ville Syrjälä
2019-08-21 16:13 ` [RFC] replacing dma_resv API Daniel Vetter
2019-08-21 16:13   ` Daniel Vetter
2019-08-21 20:05   ` Daniel Vetter
2019-08-21 20:05     ` Daniel Vetter
2019-08-22  9:27     ` Christian König
2019-08-22  9:27       ` Christian König
2019-08-21 20:11 ` Chris Wilson
2019-08-21 20:11   ` Chris Wilson
2019-08-21 20:22   ` Daniel Vetter
2019-08-21 20:22     ` Daniel Vetter
2019-08-22  9:14     ` Christian König
2019-08-22  9:14       ` Christian König
2019-08-22 10:00       ` Daniel Vetter
2019-08-22 10:00         ` Daniel Vetter

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=20190821123147.110736-1-christian.koenig@amd.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sumit.semwal@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 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.