From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 22/22] drm/i915: Export our request as a dma-buf fence on the reservation object
Date: Thu, 28 Jul 2016 12:32:42 +0200 [thread overview]
Message-ID: <20160728103242.GI6232@phenom.ffwll.local> (raw)
In-Reply-To: <1469618100-15298-23-git-send-email-chris@chris-wilson.co.uk>
On Wed, Jul 27, 2016 at 12:15:00PM +0100, Chris Wilson wrote:
> If the GEM objects being rendered with in this request have been
> exported via dma-buf to a third party, hook ourselves into the dma-buf
> reservation object so that the third party can serialise with our
> rendering via the dma-buf fences.
>
> Testcase: igt/prime_busy
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Style nit: I prefer ww_mutex_lock(&resv->lock, NULL); over
mutex_lock(&resv->lock.base). The former makes it clear it's a ww mutex,
but we don't bother with the multi-lock dance. The latter needles around
in implemenation details, which it really shouldn't. Please change.
The other wonky bit is that changing reservations on multiple objects
without the full ww mutex dance is deadlock-risky. But only when you both
add and wait/stall on fences.
Right now we only either wait (in the modeset/flip code) or only add (in
execbuf, after this patch) and hence there's no risk. I also think that
with the usual use-case of rendering on one gpu and displaying on the
other that's done in current PRIME (instead of e.g. rendering on one, then
compositing on 2nd, and displaying somewhere else) there's also no
immediate need to add that. At least before we have fixed up our locking
scheme ;-)
With the ww_mutex change: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 56 ++++++++++++++++++++++++++++--
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 33 ++++++++++++++++--
> 2 files changed, 83 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 3a00ab3ad06e..bab71ba9c25a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -23,9 +23,13 @@
> * Authors:
> * Dave Airlie <airlied@redhat.com>
> */
> +
> +#include <linux/dma-buf.h>
> +#include <linux/reservation.h>
> +
> #include <drm/drmP.h>
> +
> #include "i915_drv.h"
> -#include <linux/dma-buf.h>
>
> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> {
> @@ -218,25 +222,71 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
> .end_cpu_access = i915_gem_end_cpu_access,
> };
>
> +static void export_fences(struct drm_i915_gem_object *obj,
> + struct dma_buf *dma_buf)
> +{
> + struct reservation_object *resv = dma_buf->resv;
> + struct drm_i915_gem_request *req;
> + unsigned long active;
> + int idx;
> +
> + active = __I915_BO_ACTIVE(obj);
> + if (!active)
> + return;
> +
> + /* Mark the object for future fences before racily adding old fences */
> + obj->base.dma_buf = dma_buf;
> +
> + mutex_lock(&resv->lock.base);
> +
> + for_each_active(active, idx) {
> + rcu_read_lock();
> + req = i915_gem_active_get_rcu(&obj->last_read[idx]);
> + rcu_read_unlock();
> + if (!req)
> + continue;
> +
> + if (reservation_object_reserve_shared(resv) == 0)
> + reservation_object_add_shared_fence(resv, &req->fence);
> +
> + i915_gem_request_put(req);
> + }
> +
> + rcu_read_lock();
> + req = i915_gem_active_get_rcu(&obj->last_write);
> + rcu_read_unlock();
> + if (req) {
> + reservation_object_add_excl_fence(resv, &req->fence);
> + i915_gem_request_put(req);
> + }
> +
> + mutex_unlock(&resv->lock.base);
> +}
> +
> struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
> struct drm_gem_object *gem_obj, int flags)
> {
> struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
> DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dma_buf;
>
> exp_info.ops = &i915_dmabuf_ops;
> exp_info.size = gem_obj->size;
> exp_info.flags = flags;
> exp_info.priv = gem_obj;
>
> -
> if (obj->ops->dmabuf_export) {
> int ret = obj->ops->dmabuf_export(obj);
> if (ret)
> return ERR_PTR(ret);
> }
>
> - return dma_buf_export(&exp_info);
> + dma_buf = dma_buf_export(&exp_info);
> + if (IS_ERR(dma_buf))
> + return dma_buf;
> +
> + export_fences(obj, dma_buf);
> + return dma_buf;
> }
>
> static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 0d28703d991a..e2aba40bf328 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -26,13 +26,17 @@
> *
> */
>
> +#include <linux/dma_remapping.h>
> +#include <linux/reservation.h>
> +#include <linux/uaccess.h>
> +
> #include <drm/drmP.h>
> #include <drm/i915_drm.h>
> +
> #include "i915_drv.h"
> +#include "i915_gem_dmabuf.h"
> #include "i915_trace.h"
> #include "intel_drv.h"
> -#include <linux/dma_remapping.h>
> -#include <linux/uaccess.h>
>
> #define __EXEC_OBJECT_HAS_PIN (1<<31)
> #define __EXEC_OBJECT_HAS_FENCE (1<<30)
> @@ -1193,7 +1197,29 @@ void i915_vma_move_to_active(struct i915_vma *vma,
> list_move_tail(&vma->vm_link, &vma->vm->active_list);
> }
>
> -static void
> +static void eb_export_fence(struct drm_i915_gem_object *obj,
> + struct drm_i915_gem_request *req,
> + unsigned int flags)
> +{
> + struct reservation_object *resv;
> +
> + resv = i915_gem_object_get_dmabuf_resv(obj);
> + if (!resv)
> + return;
> +
> + /* Ignore errors from failing to allocate the new fence, we can't
> + * handle an error right now. Worst case should be missed
> + * synchronisation leading to rendering corruption.
> + */
> + mutex_lock(&resv->lock.base);
> + if (flags & EXEC_OBJECT_WRITE)
> + reservation_object_add_excl_fence(resv, &req->fence);
> + else if (reservation_object_reserve_shared(resv) == 0)
> + reservation_object_add_shared_fence(resv, &req->fence);
> + mutex_unlock(&resv->lock.base);
> +}
> +
> +void
> i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> struct drm_i915_gem_request *req)
> {
> @@ -1212,6 +1238,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> obj->base.read_domains = obj->base.pending_read_domains;
>
> i915_vma_move_to_active(vma, req, vma->exec_entry->flags);
> + eb_export_fence(obj, req, vma->exec_entry->flags);
> trace_i915_gem_object_change_domain(obj, old_read, old_write);
> }
> }
> --
> 2.8.1
>
> _______________________________________________
> 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
next prev parent reply other threads:[~2016-07-28 10:32 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-27 11:14 Getting to RCU and exporting fences Chris Wilson
2016-07-27 11:14 ` [PATCH 01/22] drm/i915: Combine loops within i915_gem_evict_something Chris Wilson
2016-07-29 6:17 ` Joonas Lahtinen
2016-07-29 6:31 ` Chris Wilson
2016-07-27 11:14 ` [PATCH 02/22] drm/i915: Remove surplus drm_device parameter to i915_gem_evict_something() Chris Wilson
2016-07-28 8:07 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 03/22] drm/i915: Double check the active status on the batch pool Chris Wilson
2016-07-28 8:14 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 04/22] drm/i915: Remove request retirement before each batch Chris Wilson
2016-07-28 8:32 ` Joonas Lahtinen
2016-07-28 9:32 ` Chris Wilson
2016-07-28 9:53 ` Joonas Lahtinen
2016-07-28 9:54 ` Daniel Vetter
2016-07-28 10:26 ` Chris Wilson
2016-07-28 11:52 ` Daniel Vetter
2016-07-28 12:24 ` Chris Wilson
2016-07-28 14:21 ` Chris Wilson
2016-07-27 11:14 ` [PATCH 05/22] drm/i915: Remove i915_gem_execbuffer_retire_commands() Chris Wilson
2016-07-28 8:46 ` Joonas Lahtinen
2016-07-28 8:55 ` Chris Wilson
2016-07-28 9:54 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 06/22] drm/i915: Fix up vma alignment to be u64 Chris Wilson
2016-07-28 8:59 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 07/22] drm/i915: Pad GTT views of exec objects up to user specified size Chris Wilson
2016-07-28 9:55 ` Daniel Vetter
2016-07-28 10:33 ` Chris Wilson
2016-07-29 7:59 ` Joonas Lahtinen
2016-07-29 8:08 ` Chris Wilson
2016-07-29 8:55 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 08/22] drm/i915: Reduce WARN(i915_gem_valid_gtt_space) to a debug-only check Chris Wilson
2016-07-28 9:18 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 09/22] drm/i915: Split insertion/binding of an object into the VM Chris Wilson
2016-07-28 9:25 ` Joonas Lahtinen
2016-07-28 9:34 ` Chris Wilson
2016-07-27 11:14 ` [PATCH 10/22] drm/i915: Record allocated vma size Chris Wilson
2016-07-29 6:53 ` Joonas Lahtinen
2016-07-29 7:18 ` Chris Wilson
2016-07-29 10:19 ` [PATCH] drm/i915: Convert 4096 alignment request to 0 for drm_mm allocations Chris Wilson
2016-07-29 10:28 ` Joonas Lahtinen
2016-07-29 10:38 ` Chris Wilson
2016-07-27 11:14 ` [PATCH 11/22] drm/i915: Wrap vma->pin_count accessors with small inline helpers Chris Wilson
2016-07-29 6:59 ` Joonas Lahtinen
2016-07-29 7:23 ` Chris Wilson
2016-07-27 11:14 ` [PATCH 12/22] drm/i915: Start passing around i915_vma from execbuffer Chris Wilson
2016-07-29 8:23 ` Joonas Lahtinen
2016-08-01 7:34 ` Chris Wilson
2016-07-27 11:14 ` [PATCH 13/22] drm/i915: Combine all i915_vma bitfields into a single set of flags Chris Wilson
2016-07-29 7:30 ` Joonas Lahtinen
2016-07-29 7:44 ` Chris Wilson
2016-07-27 11:14 ` [PATCH 14/22] drm/i915: Make i915_vma_pin() small and inline Chris Wilson
2016-07-28 11:06 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 15/22] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin() Chris Wilson
2016-07-28 10:38 ` Joonas Lahtinen
2016-07-28 11:36 ` Chris Wilson
2016-07-28 11:53 ` Joonas Lahtinen
2016-07-28 16:12 ` Chris Wilson
2016-07-29 9:10 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 16/22] drm/i915: Make fb_tracking.lock a spinlock Chris Wilson
2016-07-28 10:02 ` Daniel Vetter
2016-07-28 10:08 ` Daniel Vetter
2016-07-29 8:25 ` Chris Wilson
2016-07-28 10:19 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 17/22] drm/i915: Use atomics to manipulate obj->frontbuffer_bits Chris Wilson
2016-07-28 9:49 ` Joonas Lahtinen
2016-07-28 10:10 ` Chris Wilson
2016-07-28 10:51 ` Joonas Lahtinen
2016-07-28 10:05 ` Daniel Vetter
2016-07-27 11:14 ` [PATCH 18/22] drm/i915: Use dev_priv consistently through the intel_frontbuffer interface Chris Wilson
2016-07-28 9:36 ` Joonas Lahtinen
2016-07-28 10:06 ` Daniel Vetter
2016-07-27 11:14 ` [PATCH 19/22] drm/i915: Move obj->active:5 to obj->flags Chris Wilson
2016-07-29 7:40 ` Joonas Lahtinen
2016-07-29 8:04 ` Chris Wilson
2016-07-29 8:10 ` Chris Wilson
2016-07-29 9:34 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 20/22] drm/i915: Move i915_gem_object_wait_rendering() Chris Wilson
2016-07-28 9:37 ` Joonas Lahtinen
2016-07-27 11:14 ` [PATCH 21/22] drm/i915: Enable lockless lookup of request tracking via RCU Chris Wilson
2016-07-28 10:23 ` Daniel Vetter
2016-07-28 20:49 ` Chris Wilson
2016-07-29 8:41 ` Daniel Vetter
2016-07-29 8:49 ` Chris Wilson
2016-07-29 9:43 ` Chris Wilson
2016-07-29 9:45 ` Daniel Vetter
2016-07-27 11:15 ` [PATCH 22/22] drm/i915: Export our request as a dma-buf fence on the reservation object Chris Wilson
2016-07-28 10:32 ` Daniel Vetter [this message]
2016-07-28 10:40 ` Chris Wilson
2016-07-28 11:59 ` Daniel Vetter
2016-07-28 12:17 ` Chris Wilson
2016-07-28 12:28 ` Daniel Vetter
2016-07-28 12:45 ` Chris Wilson
2016-07-28 20:14 ` Daniel Vetter
2016-07-28 21:08 ` Chris Wilson
2016-07-27 11:23 ` ✗ Ro.CI.BAT: failure for series starting with [01/22] drm/i915: Combine loops within i915_gem_evict_something Patchwork
2016-07-29 10:20 ` ✗ Ro.CI.BAT: failure for series starting with [01/22] drm/i915: Combine loops within i915_gem_evict_something (rev2) 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=20160728103242.GI6232@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox