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
next 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