All of lore.kernel.org
 help / color / mirror / Atom feed
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 05/14] drm/i915: Prevent using semaphores to chain up to external fences
Date: Tue,  5 May 2020 22:52:05 +0100	[thread overview]
Message-ID: <20200505215214.9690-5-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20200505215214.9690-1-chris@chris-wilson.co.uk>

The downside of using semaphores is that we lose metadata passing
along the signaling chain. This is particularly nasty when we
need to pass along a fatal error such as EFAULT or EDEADLK. For
fatal errors we want to scrub the request before it is executed,
which means that we cannot preload the request onto HW and have
it wait upon a semaphore.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_request.c         | 26 +++++++++++++++++++++
 drivers/gpu/drm/i915/i915_scheduler_types.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index dfb1e86ffc7f..e3c691bf082f 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1002,6 +1002,15 @@ emit_semaphore_wait(struct i915_request *to,
 	if (!rcu_access_pointer(from->hwsp_cacheline))
 		goto await_fence;
 
+	/*
+	 * If this or its dependents are waiting on an external fence
+	 * that may fail catastrophically, then we want to avoid using
+	 * sempahores as they bypass the fence signaling metadata, and we
+	 * lose the fence->error propagation.
+	 */
+	if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN)
+		goto await_fence;
+
 	/* Just emit the first semaphore we see as request space is limited. */
 	if (already_busywaiting(to) & mask)
 		goto await_fence;
@@ -1064,12 +1073,29 @@ i915_request_await_request(struct i915_request *to, struct i915_request *from)
 			return ret;
 	}
 
+	if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN)
+		to->sched.flags |= I915_SCHED_HAS_EXTERNAL_CHAIN;
+
 	return 0;
 }
 
+static void mark_external(struct i915_request *rq)
+{
+	/*
+	 * The downside of using semaphores is that we lose metadata passing
+	 * along the signaling chain. This is particularly nasty when we
+	 * need to pass along a fatal error such as EFAULT or EDEADLK. For
+	 * fatal errors we want to scrub the request before it is executed,
+	 * which means that we cannot preload the request onto HW and have
+	 * it wait upon a semaphore.
+	 */
+	rq->sched.flags |= I915_SCHED_HAS_EXTERNAL_CHAIN;
+}
+
 static int
 i915_request_await_external(struct i915_request *rq, struct dma_fence *fence)
 {
+	mark_external(rq);
 	return i915_sw_fence_await_dma_fence(&rq->submit, fence,
 					     fence->context ? I915_FENCE_TIMEOUT : 0,
 					     I915_FENCE_GFP);
diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h b/drivers/gpu/drm/i915/i915_scheduler_types.h
index 7186875088a0..6ab2c5289bed 100644
--- a/drivers/gpu/drm/i915/i915_scheduler_types.h
+++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
@@ -66,6 +66,7 @@ struct i915_sched_node {
 	struct i915_sched_attr attr;
 	unsigned int flags;
 #define I915_SCHED_HAS_SEMAPHORE_CHAIN	BIT(0)
+#define I915_SCHED_HAS_EXTERNAL_CHAIN	BIT(1)
 	intel_engine_mask_t semaphores;
 };
 
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-05-05 21:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 21:52 [PATCH 01/14] drm/i915: Mark concurrent submissions with a weak-dependency Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] " Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 02/14] drm/i915: Propagate error from completed fences Chris Wilson
2020-05-06 15:36   ` Matthew Auld
2020-05-05 21:52 ` [Intel-gfx] [PATCH 03/14] drm/i915: Ignore submit-fences on the same timeline Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 04/14] drm/i915: Pull waiting on an external dma-fence into its routine Chris Wilson
2020-05-05 21:52 ` Chris Wilson [this message]
2020-05-05 21:52 ` [Intel-gfx] [PATCH 06/14] drm/i915: Tidy awaiting on dma-fences Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 07/14] dma-buf: Proxy fence, an unsignaled fence placeholder Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 08/14] drm/syncobj: Allow use of dma-fence-proxy Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 09/14] drm/i915/gem: Teach execbuf how to wait on future syncobj Chris Wilson
2020-05-06  7:48   ` Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 10/14] drm/i915/gem: Allow combining submit-fences with syncobj Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 11/14] drm/i915/gt: Declare when we enabled timeslicing Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 12/14] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 13/14] drm/i915: Drop I915_RESET_TIMEOUT and friends Chris Wilson
2020-05-05 21:52 ` [Intel-gfx] [PATCH 14/14] drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT Chris Wilson
2020-05-05 23:31 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/14] drm/i915: Mark concurrent submissions with a weak-dependency Patchwork
2020-05-05 23:55 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-05-06 10:25 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=20200505215214.9690-5-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.