dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Ekstrand <jason@jlekstrand.net>
To: dri-devel@lists.freedesktop.org
Cc: "Jason Ekstrand" <jason.ekstrand@intel.com>,
	"Dave Airlie" <airlied@redhat.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: [PATCH 0/7] drm/syncobj: Add full-featured wait support (v3)
Date: Tue, 15 Aug 2017 21:13:48 -0700	[thread overview]
Message-ID: <1502856835-9433-1-git-send-email-jason.ekstrand@intel.com> (raw)

This is the third full re-send of my syncobj patches.  The final patch is
somewhere between v2 and v3.  After I sent out v2, Christian suggested that
I use wait_event_interruptible_timeout so I did in v3 with a few other
improvements.  Then Chris suggested I rework things to use proxy fences so
I did.  When Christian NAK'd the proxy fence approach, I suggested we fall
back to v3.  However, he didn't like the fact that using waitqueues with
the syncobj callbacks leaves us with two layers of callbacks.  That brings
us to this version.

christian's suggestion to get rid of a layer of callbacks was to use a
waitqueue in drm_syncobj instead of making our own callback list.  This is
problematic, however, because we really need to be able to wait on two
kinds of things: syncobj fence replacement and dma-fence triggering and we
need to wait on both simultaneously.  This leaves us with two options:

 1) Rework dma-fence to use waitqueues instead of its own call-back
    mechanism then add waitqueue code to perform a wait_any operation.

 2) Fall back to the approach in v2 and not bother with waitqueues.

I prefer the second option because we have userspace code that is waiting
for this kernel feature and I'd like to land it sooner rather than later.
Blocking syncobj wait support on additions to the core kernel waitqueue
code sounds like it will delay things significantly.  I'd be moderately ok
with spending some time working on this refactoring if people really think
it's worth the time but I'd rather not block on it.

This version takes the old approach (without waitqueues) of v2 but carries
the improvements and bugfixes from v3 and v4.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>

Dave Airlie (1):
  drm/syncobj: add sync obj wait interface. (v8)

Jason Ekstrand (6):
  drm/syncobj: Rename fence_get to find_fence
  drm/syncobj: Add a race-free drm_syncobj_fence_get helper (v2)
  i915: Use drm_syncobj_fence_get
  drm/syncobj: Add a reset ioctl
  drm/syncobj: Add a callback mechanism for replace_fence (v2)
  drm/syncobj: Allow wait for submit and signal behavior (v5)

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c     |   2 +-
 drivers/gpu/drm/drm_internal.h             |   4 +
 drivers/gpu/drm/drm_ioctl.c                |   4 +
 drivers/gpu/drm/drm_syncobj.c              | 400 ++++++++++++++++++++++++++++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   4 +-
 include/drm/drm_syncobj.h                  |  57 +++-
 include/uapi/drm/drm.h                     |  19 ++
 7 files changed, 475 insertions(+), 15 deletions(-)

-- 
2.5.0.400.gff86faf

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

             reply	other threads:[~2017-08-16  4:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16  4:13 Jason Ekstrand [this message]
2017-08-16  4:13 ` [PATCH 1/7] drm/syncobj: Rename fence_get to find_fence Jason Ekstrand
2017-08-16  4:13 ` [PATCH 2/7] drm/syncobj: Add a race-free drm_syncobj_fence_get helper (v2) Jason Ekstrand
2017-08-16  4:13 ` [PATCH 3/7] i915: Use drm_syncobj_fence_get Jason Ekstrand
2017-08-16  4:13 ` [PATCH 4/7] drm/syncobj: add sync obj wait interface. (v8) Jason Ekstrand
2017-08-16  4:13 ` [PATCH 5/7] drm/syncobj: Add a reset ioctl Jason Ekstrand
2017-08-16  4:13 ` [PATCH 6/7] drm/syncobj: Add a callback mechanism for replace_fence (v2) Jason Ekstrand
2017-08-16  4:13 ` [PATCH 7/7] drm/syncobj: Allow wait for submit and signal behavior (v5) Jason Ekstrand

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=1502856835-9433-1-git-send-email-jason.ekstrand@intel.com \
    --to=jason@jlekstrand.net \
    --cc=airlied@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason.ekstrand@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox