From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Subject: [Intel-gfx] [PATCH 11/22] drm/i915/gem: Allow combining submit-fences with syncobj
Date: Mon, 4 May 2020 05:48:52 +0100 [thread overview]
Message-ID: <20200504044903.7626-11-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20200504044903.7626-1-chris@chris-wilson.co.uk>
We allow exported sync_file fences to be used as submit fences, but they
are not the only source of user fences. We also accept an array of
syncobj, and as with sync_file these are dma_fences underneath and so
feature the same set of controls. The submit-fence allows for a request
to be scheduled at the same time as the signaler, rather than as normal
after. Userspace can combine submit-fence with its own semaphores for
intra-batch scheduling.
Not exposing submit-fences to syncobj was at the time just a matter of
pragmatic expediency.
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 ++++++----
drivers/gpu/drm/i915/i915_request.c | 26 ++++++++++++++++++-
include/uapi/drm/i915_drm.h | 7 ++---
3 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8b854f87a249..67ba33b3de60 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2432,7 +2432,7 @@ static void
__free_fence_array(struct drm_syncobj **fences, unsigned int n)
{
while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ drm_syncobj_put(ptr_mask_bits(fences[n], 3));
kvfree(fences);
}
@@ -2489,7 +2489,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
- fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+ fences[n] = ptr_pack_bits(syncobj, fence.flags, 3);
}
return fences;
@@ -2520,7 +2520,7 @@ await_fence_array(struct i915_execbuffer *eb,
struct dma_fence *fence;
unsigned int flags;
- syncobj = ptr_unpack_bits(fences[n], &flags, 2);
+ syncobj = ptr_unpack_bits(fences[n], &flags, 3);
if (!(flags & I915_EXEC_FENCE_WAIT))
continue;
@@ -2544,7 +2544,11 @@ await_fence_array(struct i915_execbuffer *eb,
spin_unlock(&syncobj->lock);
}
- err = i915_request_await_dma_fence(eb->request, fence);
+ if (flags & I915_EXEC_FENCE_WAIT_SUBMIT)
+ err = i915_request_await_execution(eb->request, fence,
+ eb->engine->bond_execute);
+ else
+ err = i915_request_await_dma_fence(eb->request, fence);
dma_fence_put(fence);
if (err < 0)
return err;
@@ -2565,7 +2569,7 @@ signal_fence_array(struct i915_execbuffer *eb,
struct drm_syncobj *syncobj;
unsigned int flags;
- syncobj = ptr_unpack_bits(fences[n], &flags, 2);
+ syncobj = ptr_unpack_bits(fences[n], &flags, 3);
if (!(flags & I915_EXEC_FENCE_SIGNAL))
continue;
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 8583fe5bb3b6..92fa5267bcce 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1326,6 +1326,26 @@ __i915_request_await_execution(struct i915_request *to,
&from->fence);
}
+static int execution_proxy(struct await_proxy *ap)
+{
+ return i915_request_await_execution(ap->request, ap->fence, ap->data);
+}
+
+static int
+i915_request_await_proxy_execution(struct i915_request *rq,
+ struct dma_fence *fence,
+ void (*hook)(struct i915_request *rq,
+ struct dma_fence *signal))
+{
+ /*
+ * We have to wait until the real request is known in order to
+ * be able to hook into its execution, as opposed to waiting for
+ * its completion.
+ */
+ return __i915_request_await_proxy(rq, fence, I915_FENCE_TIMEOUT,
+ execution_proxy, hook);
+}
+
int
i915_request_await_execution(struct i915_request *rq,
struct dma_fence *fence,
@@ -1362,10 +1382,14 @@ i915_request_await_execution(struct i915_request *rq,
ret = __i915_request_await_execution(rq,
to_request(fence),
hook);
+ else if (dma_fence_is_proxy(fence))
+ ret = i915_request_await_proxy_execution(rq,
+ fence,
+ hook);
else
ret = i915_sw_fence_await_dma_fence(&rq->submit, fence,
I915_FENCE_TIMEOUT,
- GFP_KERNEL);
+ I915_FENCE_GFP);
if (ret < 0)
return ret;
} while (--nchild);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd6b54b..704dd0e3bc1d 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1040,9 +1040,10 @@ struct drm_i915_gem_exec_fence {
*/
__u32 handle;
-#define I915_EXEC_FENCE_WAIT (1<<0)
-#define I915_EXEC_FENCE_SIGNAL (1<<1)
-#define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SIGNAL << 1))
+#define I915_EXEC_FENCE_WAIT (1u << 0)
+#define I915_EXEC_FENCE_SIGNAL (1u << 1)
+#define I915_EXEC_FENCE_WAIT_SUBMIT (1u << 2)
+#define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_WAIT_SUBMIT << 1))
__u32 flags;
};
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-05-04 4:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 4:48 [Intel-gfx] [PATCH 01/22] drm/i915: Allow some leniency in PCU reads Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 02/22] drm/i915/gem: Specify address type for chained reloc batches Chris Wilson
2020-05-04 11:49 ` Tvrtko Ursulin
2020-05-04 11:53 ` Chris Wilson
2020-05-04 12:15 ` Tvrtko Ursulin
2020-05-04 4:48 ` [Intel-gfx] [PATCH 03/22] drm/i915/gem: Implement legacy MI_STORE_DATA_IMM Chris Wilson
2020-05-04 12:58 ` Tvrtko Ursulin
2020-05-04 13:08 ` Chris Wilson
2020-05-04 13:22 ` [Intel-gfx] [PATCH v2] " Chris Wilson
2020-05-04 13:33 ` Tvrtko Ursulin
2020-05-04 4:48 ` [Intel-gfx] [PATCH 04/22] drm/i915/gt: Small tidy of gen8+ breadcrumb emission Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 05/22] drm/i915: Mark concurrent submissions with a weak-dependency Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 06/22] drm/i915/selftests: Repeat the rps clock frequency measurement Chris Wilson
2020-05-04 17:17 ` Mika Kuoppala
2020-05-04 4:48 ` [Intel-gfx] [PATCH 07/22] drm/i915/gt: Stop holding onto the pinned_default_state Chris Wilson
2020-05-05 20:08 ` Andi Shyti
2020-05-05 20:13 ` Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 08/22] dma-buf: Proxy fence, an unsignaled fence placeholder Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 09/22] drm/syncobj: Allow use of dma-fence-proxy Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 10/22] drm/i915/gem: Teach execbuf how to wait on future syncobj Chris Wilson
2020-05-04 4:48 ` Chris Wilson [this message]
2020-05-04 4:48 ` [Intel-gfx] [PATCH 12/22] drm/i915/gt: Declare when we enabled timeslicing Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 13/22] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 14/22] drm/i915: Drop I915_RESET_TIMEOUT and friends Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 15/22] drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 16/22] drm/i915: Always defer fenced work to the worker Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 17/22] drm/i915/gem: Assign context id for async work Chris Wilson
2020-05-04 4:48 ` [Intel-gfx] [PATCH 18/22] drm/i915: Export a preallocate variant of i915_active_acquire() Chris Wilson
2020-05-04 4:49 ` [Intel-gfx] [PATCH 19/22] drm/i915/gem: Separate the ww_mutex walker into its own list Chris Wilson
2020-05-04 4:49 ` [Intel-gfx] [PATCH 20/22] drm/i915/gem: Asynchronous GTT unbinding Chris Wilson
2020-05-04 4:49 ` [Intel-gfx] [PATCH 21/22] drm/i915/gem: Bind the fence async for execbuf Chris Wilson
2020-05-04 4:49 ` [Intel-gfx] [PATCH 22/22] drm/i915/gem: Lazily acquire the device wakeref for freeing objects Chris Wilson
2020-05-04 5:16 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/22] drm/i915: Allow some leniency in PCU reads Patchwork
2020-05-04 5:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-05-04 9:52 ` [Intel-gfx] [PATCH 01/22] " Mika Kuoppala
2020-05-04 10:00 ` Chris Wilson
2020-05-04 13:43 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/22] drm/i915: Allow some leniency in PCU reads (rev2) Patchwork
2020-05-04 13:49 ` [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/22] drm/i915: Allow some leniency in PCU reads Patchwork
2020-05-04 14:07 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/22] drm/i915: Allow some leniency in PCU reads (rev2) Patchwork
2020-05-05 1:31 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=20200504044903.7626-11-chris@chris-wilson.co.uk \
--to=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;
as well as URLs for NNTP newsgroup(s).