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 28/36] drm/i915/gem: Allow combining submit-fences with syncobj
Date: Mon, 1 Jun 2020 08:24:38 +0100 [thread overview]
Message-ID: <20200601072446.19548-28-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20200601072446.19548-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 | 25 +++++++++++++++++++
include/uapi/drm/i915_drm.h | 7 +++---
3 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4fddbe34efa6..cb4872ccfe58 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2397,7 +2397,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);
}
@@ -2454,7 +2454,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;
@@ -2485,7 +2485,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;
@@ -2509,7 +2509,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;
@@ -2530,7 +2534,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 02747c171c54..a570a1f43d70 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1385,6 +1385,27 @@ __i915_request_await_proxy(struct i915_request *rq,
return 0;
}
+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(rq->i915),
+ execution_proxy, hook);
+}
+
int
i915_request_await_execution(struct i915_request *rq,
struct dma_fence *fence,
@@ -1424,6 +1445,10 @@ 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_request_await_external(rq, fence);
if (ret < 0)
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-06-01 7:25 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 7:24 [Intel-gfx] [PATCH 01/36] drm/i915: Handle very early engine initialisation failure Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 02/36] drm/i915/gt: Split low level gen2-7 CS emitters Chris Wilson
2020-06-02 9:04 ` Mika Kuoppala
2020-06-01 7:24 ` [Intel-gfx] [PATCH 03/36] drm/i915/gt: Move legacy context wa to intel_workarounds Chris Wilson
2020-06-02 9:05 ` Mika Kuoppala
2020-06-01 7:24 ` [Intel-gfx] [PATCH 04/36] drm/i915: Trim the ironlake+ irq handler Chris Wilson
2020-06-01 11:49 ` Mika Kuoppala
2020-06-01 12:00 ` Chris Wilson
2020-06-01 12:08 ` Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 05/36] Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq" Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 06/36] drm/i915/gt: Couple tasklet scheduling for all CS interrupts Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 07/36] drm/i915/gt: Support creation of 'internal' rings Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 08/36] drm/i915/gt: Use client timeline address for seqno writes Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 09/36] drm/i915: Support inter-engine semaphores on gen6/7 Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 10/36] drm/i915/gt: Infrastructure for ring scheduling Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 11/36] drm/i915/gt: Enable busy-stats for ring-scheduler Chris Wilson
2020-06-01 8:03 ` [Intel-gfx] [PATCH] " Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 12/36] drm/i915/gt: Track if an engine requires forcewake w/a Chris Wilson
2020-06-01 12:17 ` Mika Kuoppala
2020-06-01 7:24 ` [Intel-gfx] [PATCH 13/36] drm/i915: Relinquish forcewake immediately after manual grouping Chris Wilson
2020-06-01 12:20 ` Mika Kuoppala
2020-06-01 7:24 ` [Intel-gfx] [PATCH 14/36] drm/i915/gt: Implement ring scheduler for gen6/7 Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 15/36] drm/i915/gt: Enable ring scheduling " Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 16/36] drm/i915/gem: Mark the buffer pool as active for the cmdparser Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 17/36] drm/i915/gem: Async GPU relocations only Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 18/36] drm/i915: Add list_for_each_entry_safe_continue_reverse Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 19/36] drm/i915/gem: Separate reloc validation into an earlier step Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 20/36] drm/i915/gem: Lift GPU relocation allocation Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 21/36] drm/i915/gem: Build the reloc request first Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 22/36] drm/i915/gem: Add all GPU reloc awaits/signals en masse Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 23/36] dma-buf: Proxy fence, an unsignaled fence placeholder Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 24/36] drm/i915: Unpeel awaits on a proxy fence Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 25/36] drm/i915/gem: Make relocations atomic within execbuf Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 26/36] drm/syncobj: Allow use of dma-fence-proxy Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 27/36] drm/i915/gem: Teach execbuf how to wait on future syncobj Chris Wilson
2020-06-01 7:24 ` Chris Wilson [this message]
2020-06-01 7:24 ` [Intel-gfx] [PATCH 29/36] drm/i915/gt: Declare when we enabled timeslicing Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 30/36] drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 31/36] drm/i915: Always defer fenced work to the worker Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 32/36] drm/i915/gem: Assign context id for async work Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 33/36] drm/i915: Export a preallocate variant of i915_active_acquire() Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 34/36] drm/i915/gem: Separate the ww_mutex walker into its own list Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 35/36] drm/i915/gem: Asynchronous GTT unbinding Chris Wilson
2020-06-01 7:24 ` [Intel-gfx] [PATCH 36/36] drm/i915/gem: Bind the fence async for execbuf Chris Wilson
2020-06-01 7:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure Patchwork
2020-06-01 7:36 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-06-01 7:56 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-06-01 8:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure (rev2) Patchwork
2020-06-01 8:31 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-06-01 8:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-06-01 11:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-06-01 11:39 ` Chris Wilson
2020-06-01 11:31 ` [Intel-gfx] [PATCH 01/36] drm/i915: Handle very early engine initialisation failure Mika Kuoppala
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=20200601072446.19548-28-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).