All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 01/17] drm/i915: Apply batch location restrictions before pinning
Date: Sun, 10 Jun 2018 20:43:09 +0100	[thread overview]
Message-ID: <20180610194325.13467-2-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20180610194325.13467-1-chris@chris-wilson.co.uk>

We special case the position of the batch within the GTT to prevent
negative self-relocation deltas from underflowing. However, that
restriction is being applied after a trial pin of the batch in its
current position. Thus we are not rejecting an invalid location if the
batch has been before, leading to an assertion if we happen to need to
rearrange the entire payload. In the worst case, this may cause a GPU
hang on gen7 or perhaps missing state.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105720
Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 49 ++++++++++++----------
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index eefd449502e2..2d2eb3075960 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -489,7 +489,9 @@ eb_validate_vma(struct i915_execbuffer *eb,
 }
 
 static int
-eb_add_vma(struct i915_execbuffer *eb, unsigned int i, struct i915_vma *vma)
+eb_add_vma(struct i915_execbuffer *eb,
+	   unsigned int i, unsigned batch_idx,
+	   struct i915_vma *vma)
 {
 	struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
 	int err;
@@ -522,6 +524,24 @@ eb_add_vma(struct i915_execbuffer *eb, unsigned int i, struct i915_vma *vma)
 	eb->flags[i] = entry->flags;
 	vma->exec_flags = &eb->flags[i];
 
+	/*
+	 * SNA is doing fancy tricks with compressing batch buffers, which leads
+	 * to negative relocation deltas. Usually that works out ok since the
+	 * relocate address is still positive, except when the batch is placed
+	 * very low in the GTT. Ensure this doesn't happen.
+	 *
+	 * Note that actual hangs have only been observed on gen7, but for
+	 * paranoia do it everywhere.
+	 */
+	if (i == batch_idx) {
+		if (!(eb->flags[i] & EXEC_OBJECT_PINNED))
+			eb->flags[i] |= __EXEC_OBJECT_NEEDS_BIAS;
+		if (eb->reloc_cache.has_fence)
+			eb->flags[i] |= EXEC_OBJECT_NEEDS_FENCE;
+
+		eb->batch = vma;
+	}
+
 	err = 0;
 	if (eb_pin_vma(eb, entry, vma)) {
 		if (entry->offset != vma->node.start) {
@@ -716,7 +736,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
 {
 	struct radix_tree_root *handles_vma = &eb->ctx->handles_vma;
 	struct drm_i915_gem_object *obj;
-	unsigned int i;
+	unsigned int i, batch;
 	int err;
 
 	if (unlikely(i915_gem_context_is_closed(eb->ctx)))
@@ -728,6 +748,8 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
 	INIT_LIST_HEAD(&eb->relocs);
 	INIT_LIST_HEAD(&eb->unbound);
 
+	batch = eb_batch_index(eb);
+
 	for (i = 0; i < eb->buffer_count; i++) {
 		u32 handle = eb->exec[i].handle;
 		struct i915_lut_handle *lut;
@@ -770,33 +792,16 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
 		lut->handle = handle;
 
 add_vma:
-		err = eb_add_vma(eb, i, vma);
+		err = eb_add_vma(eb, i, batch, vma);
 		if (unlikely(err))
 			goto err_vma;
 
 		GEM_BUG_ON(vma != eb->vma[i]);
 		GEM_BUG_ON(vma->exec_flags != &eb->flags[i]);
+		GEM_BUG_ON(drm_mm_node_allocated(&vma->node) &&
+			   eb_vma_misplaced(&eb->exec[i], vma, eb->flags[i]));
 	}
 
-	/* take note of the batch buffer before we might reorder the lists */
-	i = eb_batch_index(eb);
-	eb->batch = eb->vma[i];
-	GEM_BUG_ON(eb->batch->exec_flags != &eb->flags[i]);
-
-	/*
-	 * SNA is doing fancy tricks with compressing batch buffers, which leads
-	 * to negative relocation deltas. Usually that works out ok since the
-	 * relocate address is still positive, except when the batch is placed
-	 * very low in the GTT. Ensure this doesn't happen.
-	 *
-	 * Note that actual hangs have only been observed on gen7, but for
-	 * paranoia do it everywhere.
-	 */
-	if (!(eb->flags[i] & EXEC_OBJECT_PINNED))
-		eb->flags[i] |= __EXEC_OBJECT_NEEDS_BIAS;
-	if (eb->reloc_cache.has_fence)
-		eb->flags[i] |= EXEC_OBJECT_NEEDS_FENCE;
-
 	eb->args->flags |= __EXEC_VALIDATED;
 	return eb_reserve(eb);
 
-- 
2.17.1

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

  reply	other threads:[~2018-06-10 19:43 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-10 19:43 Haswell full-ppgtt Chris Wilson
2018-06-10 19:43 ` Chris Wilson [this message]
2018-06-11  9:57   ` [PATCH 01/17] drm/i915: Apply batch location restrictions before pinning Joonas Lahtinen
2018-06-11 10:08     ` Chris Wilson
2018-06-10 19:43 ` [PATCH 02/17] drm/i915/ringbuffer: Brute force context restore Chris Wilson
2018-06-11 10:00   ` Tvrtko Ursulin
2018-06-11 10:04     ` Chris Wilson
2018-06-11 10:23       ` Tvrtko Ursulin
2018-06-11 10:33         ` Chris Wilson
2018-06-11 10:07   ` Mika Kuoppala
2018-06-11 10:11   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 03/17] drm/i915/ringbuffer: Fix context restore upon reset Chris Wilson
2018-06-11 10:28   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 04/17] drm/i915: Wrap around the tail offset before setting ring->tail Chris Wilson
2018-06-11 10:16   ` Mika Kuoppala
2018-06-11 10:26     ` Chris Wilson
2018-06-11 10:40       ` Mika Kuoppala
2018-06-11 10:30   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 05/17] drm/i915/gtt: Invalidate GGTT caches after writing the gen6 page directories Chris Wilson
2018-06-11 10:37   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 06/17] drm/i915/ringbuffer: Serialize load of PD_DIR Chris Wilson
2018-06-11 10:12   ` Chris Wilson
2018-06-11 10:43   ` Joonas Lahtinen
2018-06-11 10:47     ` Chris Wilson
2018-06-10 19:43 ` [PATCH 07/17] drm/i915/gtt: Subclass gen6_hw_ppgtt Chris Wilson
2018-06-10 19:43 ` [PATCH 08/17] drm/i915/gtt: Onionify error handling for gen6_ppgtt_create Chris Wilson
2018-06-11 10:48   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 09/17] drm/i915/gtt: Make gen6 page directories evictable Chris Wilson
2018-06-11 10:56   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 10/17] drm/i915/gtt: Only keep gen6 page directories pinned while active Chris Wilson
2018-06-10 19:43 ` [PATCH 11/17] drm/i915/gtt: Lazily allocate page directories for gen7 Chris Wilson
2018-06-11 11:03   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 12/17] drm/i915/gtt: Free unused page tables on unbind the context Chris Wilson
2018-06-11 11:09   ` Joonas Lahtinen
2018-06-10 19:43 ` [PATCH 13/17] drm/i915/gtt: Skip initializing PT with scratch if full Chris Wilson
2018-06-10 19:43 ` [PATCH 14/17] drm/i915/gtt: Cache the PTE encoding of the scratch page Chris Wilson
2018-06-10 19:43 ` [PATCH 15/17] drm/i915/gtt: Reduce a pair of runtime asserts Chris Wilson
2018-06-10 19:43 ` [PATCH 16/17] drm/i915/gtt: Skip clearing the GGTT under gen6+ full-ppgtt Chris Wilson
2018-06-11  9:28   ` Matthew Auld
2018-06-10 19:43 ` [PATCH 17/17] drm/i915/gtt: Enable full-ppgtt by default everywhere Chris Wilson
2018-06-10 20:00 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/17] drm/i915: Apply batch location restrictions before pinning Patchwork
2018-06-10 20:05 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-06-10 20:18 ` ✓ Fi.CI.BAT: success " Patchwork
2018-06-10 21:10 ` ✓ 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=20180610194325.13467-2-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.