From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 05/22] drm/i915: Parse command buffer earlier in eb_relocate(slow)
Date: Mon, 30 Mar 2020 16:35:28 +0200 [thread overview]
Message-ID: <20200330143545.4371-5-maarten.lankhorst@linux.intel.com> (raw)
In-Reply-To: <20200330143545.4371-1-maarten.lankhorst@linux.intel.com>
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get called from execbuf
relocation fast and slowpath.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 68 ++++++++++---------
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cc2be6964037..55b06d7a1329 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -285,6 +285,8 @@ struct i915_execbuffer {
struct hlist_head *buckets; /** ht for relocation handles */
};
+static int eb_parse(struct i915_execbuffer *eb);
+
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -814,6 +816,7 @@ static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
+ struct drm_i915_private *i915 = eb->i915;
unsigned int batch = eb_batch_index(eb);
unsigned int i;
int err = 0;
@@ -827,18 +830,37 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
vma = eb_lookup_vma(eb, eb->exec[i].handle);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
- break;
+ goto err;
}
err = eb_validate_vma(eb, &eb->exec[i], vma);
if (unlikely(err)) {
i915_vma_put(vma);
- break;
+ goto err;
}
eb_add_vma(eb, i, batch, vma);
}
+ if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
+ drm_dbg(&i915->drm,
+ "Attempting to use self-modifying batch buffer\n");
+ return -EINVAL;
+ }
+
+ if (range_overflows_t(u64,
+ eb->batch_start_offset, eb->batch_len,
+ eb->batch->vma->size)) {
+ drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
+ return -EINVAL;
+ }
+
+ if (eb->batch_len == 0)
+ eb->batch_len = eb->batch->vma->size - eb->batch_start_offset;
+
+ return 0;
+
+err:
eb->vma[i].vma = NULL;
return err;
}
@@ -1688,7 +1710,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1739,6 +1761,11 @@ static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
}
}
+ /* as last step, parse the command buffer */
+ err = eb_parse(eb);
+ if (err)
+ goto err;
+
/*
* Leave the user relocations as are, this is the painfully slow path,
* and we want to avoid the complication of dropping the lock whilst
@@ -1771,7 +1798,7 @@ static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
return err;
}
-static int eb_relocate(struct i915_execbuffer *eb)
+static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
@@ -1791,11 +1818,11 @@ static int eb_relocate(struct i915_execbuffer *eb)
list_for_each_entry(ev, &eb->relocs, reloc_link) {
if (eb_relocate_vma(eb, ev))
- return eb_relocate_slow(eb);
+ return eb_relocate_parse_slow(eb);
}
}
- return 0;
+ return eb_parse(eb);
}
static int eb_move_to_gpu(struct i915_execbuffer *eb)
@@ -2731,7 +2758,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_context;
- err = eb_relocate(&eb);
+ err = eb_relocate_parse(&eb);
if (err) {
/*
* If the user expects the execobject.offset and
@@ -2744,33 +2771,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
- if (unlikely(eb.batch->flags & EXEC_OBJECT_WRITE)) {
- drm_dbg(&i915->drm,
- "Attempting to use self-modifying batch buffer\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (range_overflows_t(u64,
- eb.batch_start_offset, eb.batch_len,
- eb.batch->vma->size)) {
- drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (eb.batch_len == 0)
- eb.batch_len = eb.batch->vma->size - eb.batch_start_offset;
-
- err = eb_parse(&eb);
- if (err)
- goto err_vma;
-
/*
* snb/ivb/vlv conflate the "batch in ppgtt" bit with the "non-secure
* batch" bit. Hence we need to pin secure batches into the global gtt.
* hsw should have this fixed, but bdw mucks it up again. */
- batch = eb.batch->vma;
if (eb.batch_flags & I915_DISPATCH_SECURE) {
struct i915_vma *vma;
@@ -2784,13 +2788,15 @@ i915_gem_do_execbuffer(struct drm_device *dev,
* fitting due to fragmentation.
* So this is actually safe.
*/
- vma = i915_gem_object_ggtt_pin(batch->obj, NULL, 0, 0, 0);
+ vma = i915_gem_object_ggtt_pin(eb.batch->vma->obj, NULL, 0, 0, 0);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
goto err_parse;
}
batch = vma;
+ } else {
+ batch = eb.batch->vma;
}
/* All GPU relocation batches must be submitted prior to the user rq */
--
2.25.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-03-30 14:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 14:35 [Intel-gfx] [PATCH 01/22] Revert "drm/i915/gem: Drop relocation slowpath" Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 02/22] perf/core: Only copy-to-user after completely unlocking all locks. (CI test) Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 03/22] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2 Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 04/22] drm/i915: Remove locking from i915_gem_object_prepare_read/write Maarten Lankhorst
2020-03-30 14:35 ` Maarten Lankhorst [this message]
2020-03-30 14:35 ` [Intel-gfx] [PATCH 06/22] drm/i915: Use per object locking in execbuf, v7 Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 07/22] drm/i915: Use ww locking in intel_renderstate Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 08/22] drm/i915: Add ww context handling to context_barrier_task Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 09/22] drm/i915: Nuke arguments to eb_pin_engine Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 10/22] drm/i915: Pin engine before pinning all objects, v3 Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 11/22] drm/i915: Rework intel_context pinning to do everything outside of pin_mutex Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 12/22] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 13/22] drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2 Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 14/22] drm/i915: Kill last user of intel_context_create_request outside of selftests Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 15/22] drm/i915: Convert i915_perf to ww locking as well Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 16/22] drm/i915: Dirty hack to fix selftests locking inversion Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 17/22] drm/i915/selftests: Fix locking inversion in lrc selftest Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 18/22] drm/i915: Use ww pinning for intel_context_create_request() Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 19/22] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion, v2 Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 20/22] drm/i915: Add ww locking to vm_fault_gtt Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 21/22] drm/i915: Add ww locking to pin_to_display_plane Maarten Lankhorst
2020-03-30 14:35 ` [Intel-gfx] [PATCH 22/22] drm/i915: Ensure we hold the pin mutex Maarten Lankhorst
2020-03-30 20:37 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [01/22] Revert "drm/i915/gem: Drop relocation slowpath" Patchwork
-- strict thread matches above, loose matches on Subject: below --
2020-03-30 14:09 [Intel-gfx] [PATCH 01/22] " Maarten Lankhorst
2020-03-30 14:09 ` [Intel-gfx] [PATCH 05/22] drm/i915: Parse command buffer earlier in eb_relocate(slow) Maarten Lankhorst
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=20200330143545.4371-5-maarten.lankhorst@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--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