From: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Subject: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Spread virtual engines over idle engines
Date: Wed, 17 Nov 2021 14:49:53 -0800 [thread overview]
Message-ID: <20211117224955.28999-2-vinay.belgaumkar@intel.com> (raw)
In-Reply-To: <20211117224955.28999-1-vinay.belgaumkar@intel.com>
From: Chris Wilson <chris@chris-wilson.co.uk>
Everytime we come to the end of a virtual engine's context, re-randomise
it's siblings[]. As we schedule the siblings' tasklets in the order they
are in the array, earlier entries are executed first (when idle) and so
will be preferred when scheduling the next virtual request. Currently,
we only update the array when switching onto a new idle engine, so we
prefer to stick on the last execute engine, keeping the work compact.
However, it can be beneficial to spread the work out across idle
engines, so choose another sibling as our preferred target at the end of
the context's execution.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
---
.../drm/i915/gt/intel_execlists_submission.c | 80 ++++++++++++-------
1 file changed, 52 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index ca03880fa7e4..b95bbc8fb91a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -539,6 +539,41 @@ static void execlists_schedule_in(struct i915_request *rq, int idx)
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
}
+static void virtual_xfer_context(struct virtual_engine *ve,
+ struct intel_engine_cs *engine)
+{
+ unsigned int n;
+
+ if (likely(engine == ve->siblings[0]))
+ return;
+
+ if (!intel_engine_has_relative_mmio(engine))
+ lrc_update_offsets(&ve->context, engine);
+
+ /*
+ * Move the bound engine to the top of the list for
+ * future execution. We then kick this tasklet first
+ * before checking others, so that we preferentially
+ * reuse this set of bound registers.
+ */
+ for (n = 1; n < ve->num_siblings; n++) {
+ if (ve->siblings[n] == engine) {
+ swap(ve->siblings[n], ve->siblings[0]);
+ break;
+ }
+ }
+}
+
+static int ve_random_sibling(struct virtual_engine *ve)
+{
+ return prandom_u32_max(ve->num_siblings);
+}
+
+static int ve_random_other_sibling(struct virtual_engine *ve)
+{
+ return 1 + prandom_u32_max(ve->num_siblings - 1);
+}
+
static void
resubmit_virtual_request(struct i915_request *rq, struct virtual_engine *ve)
{
@@ -578,8 +613,23 @@ static void kick_siblings(struct i915_request *rq, struct intel_context *ce)
rq->execution_mask != engine->mask)
resubmit_virtual_request(rq, ve);
- if (READ_ONCE(ve->request))
+ /*
+ * Reschedule with a new "preferred" sibling.
+ *
+ * The tasklets are executed in the order of ve->siblings[], so
+ * siblings[0] receives preferrential treatment of greedily checking
+ * for execution of the virtual engine. At this point, the virtual
+ * engine is no longer in the current GPU cache due to idleness or
+ * contention, so it can be executed on any without penalty. We
+ * re-randomise at this point in order to spread light loads across
+ * the system, heavy overlapping loads will continue to be greedily
+ * executed by the first available engine.
+ */
+ if (READ_ONCE(ve->request)) {
+ virtual_xfer_context(ve,
+ ve->siblings[ve_random_other_sibling(ve)]);
tasklet_hi_schedule(&ve->base.sched_engine->tasklet);
+ }
}
static void __execlists_schedule_out(struct i915_request * const rq,
@@ -1030,32 +1080,6 @@ first_virtual_engine(struct intel_engine_cs *engine)
return NULL;
}
-static void virtual_xfer_context(struct virtual_engine *ve,
- struct intel_engine_cs *engine)
-{
- unsigned int n;
-
- if (likely(engine == ve->siblings[0]))
- return;
-
- GEM_BUG_ON(READ_ONCE(ve->context.inflight));
- if (!intel_engine_has_relative_mmio(engine))
- lrc_update_offsets(&ve->context, engine);
-
- /*
- * Move the bound engine to the top of the list for
- * future execution. We then kick this tasklet first
- * before checking others, so that we preferentially
- * reuse this set of bound registers.
- */
- for (n = 1; n < ve->num_siblings; n++) {
- if (ve->siblings[n] == engine) {
- swap(ve->siblings[n], ve->siblings[0]);
- break;
- }
- }
-}
-
static void defer_request(struct i915_request *rq, struct list_head * const pl)
{
LIST_HEAD(list);
@@ -3590,7 +3614,7 @@ static void virtual_engine_initial_hint(struct virtual_engine *ve)
* NB This does not force us to execute on this engine, it will just
* typically be the first we inspect for submission.
*/
- swp = prandom_u32_max(ve->num_siblings);
+ swp = ve_random_sibling(ve);
if (swp)
swap(ve->siblings[swp], ve->siblings[0]);
}
--
2.34.0
next prev parent reply other threads:[~2021-11-17 22:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 22:49 [Intel-gfx] [PATCH 0/3] drm/i915/gt: RPS tuning for light media playback Vinay Belgaumkar
2021-11-17 22:49 ` Vinay Belgaumkar [this message]
2021-11-23 9:39 ` [Intel-gfx] [PATCH 1/3] drm/i915/gt: Spread virtual engines over idle engines Tvrtko Ursulin
2021-11-23 19:52 ` Rodrigo Vivi
2021-11-24 8:56 ` Tvrtko Ursulin
2021-11-24 13:55 ` Rodrigo Vivi
2021-11-24 15:09 ` Rodrigo Vivi
2021-11-17 22:49 ` [Intel-gfx] [PATCH 2/3] drm/i915/gt: Compare average group occupancy for RPS evaluation Vinay Belgaumkar
2021-11-23 17:35 ` Belgaumkar, Vinay
2021-11-17 22:49 ` [Intel-gfx] [PATCH 3/3] drm/i915/gt: Improve "race-to-idle" at low frequencies Vinay Belgaumkar
2021-11-22 18:44 ` Rodrigo Vivi
2021-11-23 9:17 ` Tvrtko Ursulin
2021-11-23 16:53 ` Vivi, Rodrigo
2021-11-23 17:37 ` Belgaumkar, Vinay
2021-11-17 23:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: RPS tuning for light media playback Patchwork
2021-11-18 0:31 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-11-18 20:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: RPS tuning for light media playback (rev2) Patchwork
2021-11-18 20:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-20 0:37 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: RPS tuning for light media playback (rev3) Patchwork
2021-11-20 1:09 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-20 5:13 ` [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=20211117224955.28999-2-vinay.belgaumkar@intel.com \
--to=vinay.belgaumkar@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--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