From: Matthew Brost <matthew.brost@intel.com>
To: <intel-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Subject: [Intel-gfx] [PATCH] drm/i915: Flip guc_id allocation partition
Date: Thu, 13 Jan 2022 08:27:47 -0800 [thread overview]
Message-ID: <20220113162747.4017-1-matthew.brost@intel.com> (raw)
Move the multi-lrc guc_id from the lower allocation partition (0 to
number of multi-lrc guc_ids) to upper allocation partition (number of
single-lrc to max guc_ids).
This will help when a native driver transitions to a PF after driver
load time. If the perma-pin guc_ids (kernel contexts) are in a low range
it is easy reduce total number of guc_ids as the allocated slrc are in a
valid range the mlrc range moves to an unused range. Assuming no mlrc
are allocated and few slrc are used the native to PF transition is
seamless for the guc_id resource.
v2:
(Michal / Tvrtko)
- Add an explaination to commit message of why this patch is needed
(Michal / Piotr)
- Replace marcos with functions
(Michal)
- Rework logic flow in new_mlrc_guc_id
- Unconditionally call bitmap_free
v3:
(Michal)
- Move allocation of mlrc bitmap back submission init
(CI)
- Resend for CI
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 77 ++++++++++++++-----
1 file changed, 56 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 23a40f10d376d..fce58365b3ff8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -138,17 +138,6 @@ guc_create_parallel(struct intel_engine_cs **engines,
#define GUC_REQUEST_SIZE 64 /* bytes */
-/*
- * We reserve 1/16 of the guc_ids for multi-lrc as these need to be contiguous
- * per the GuC submission interface. A different allocation algorithm is used
- * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
- * partition the guc_id space. We believe the number of multi-lrc contexts in
- * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
- * multi-lrc.
- */
-#define NUMBER_MULTI_LRC_GUC_ID(guc) \
- ((guc)->submission_state.num_guc_ids / 16)
-
/*
* Below is a set of functions which control the GuC scheduling state which
* require a lock.
@@ -1746,6 +1735,7 @@ void intel_guc_submission_reset_finish(struct intel_guc *guc)
}
static void destroyed_worker_func(struct work_struct *w);
+static int number_mlrc_guc_id(struct intel_guc *guc);
/*
* Set up the memory resources to be shared with the GuC (via the GGTT)
@@ -1778,7 +1768,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
destroyed_worker_func);
guc->submission_state.guc_ids_bitmap =
- bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
+ bitmap_zalloc(number_mlrc_guc_id(guc), GFP_KERNEL);
if (!guc->submission_state.guc_ids_bitmap)
return -ENOMEM;
@@ -1864,6 +1854,57 @@ static void guc_submit_request(struct i915_request *rq)
spin_unlock_irqrestore(&sched_engine->lock, flags);
}
+/*
+ * We reserve 1/16 of the guc_ids for multi-lrc as these need to be contiguous
+ * per the GuC submission interface. A different allocation algorithm is used
+ * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
+ * partition the guc_id space. We believe the number of multi-lrc contexts in
+ * use should be low and 1/16 should be sufficient.
+ */
+#define MLRC_GUC_ID_RATIO 16
+
+static int number_mlrc_guc_id(struct intel_guc *guc)
+{
+ return guc->submission_state.num_guc_ids / MLRC_GUC_ID_RATIO;
+}
+
+static int number_slrc_guc_id(struct intel_guc *guc)
+{
+ return guc->submission_state.num_guc_ids - number_mlrc_guc_id(guc);
+}
+
+static int mlrc_guc_id_base(struct intel_guc *guc)
+{
+ return number_slrc_guc_id(guc);
+}
+
+static int new_mlrc_guc_id(struct intel_guc *guc, struct intel_context *ce)
+{
+ int ret;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+ GEM_BUG_ON(!guc->submission_state.guc_ids_bitmap);
+
+ ret = bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
+ number_mlrc_guc_id(guc),
+ order_base_2(ce->parallel.number_children
+ + 1));
+ if (unlikely(ret < 0))
+ return ret;
+
+ return ret + mlrc_guc_id_base(guc);
+}
+
+static int new_slrc_guc_id(struct intel_guc *guc, struct intel_context *ce)
+{
+ GEM_BUG_ON(intel_context_is_parent(ce));
+
+ return ida_simple_get(&guc->submission_state.guc_ids,
+ 0, number_slrc_guc_id(guc),
+ GFP_KERNEL | __GFP_RETRY_MAYFAIL |
+ __GFP_NOWARN);
+}
+
static int new_guc_id(struct intel_guc *guc, struct intel_context *ce)
{
int ret;
@@ -1871,16 +1912,10 @@ static int new_guc_id(struct intel_guc *guc, struct intel_context *ce)
GEM_BUG_ON(intel_context_is_child(ce));
if (intel_context_is_parent(ce))
- ret = bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
- NUMBER_MULTI_LRC_GUC_ID(guc),
- order_base_2(ce->parallel.number_children
- + 1));
+ ret = new_mlrc_guc_id(guc, ce);
else
- ret = ida_simple_get(&guc->submission_state.guc_ids,
- NUMBER_MULTI_LRC_GUC_ID(guc),
- guc->submission_state.num_guc_ids,
- GFP_KERNEL | __GFP_RETRY_MAYFAIL |
- __GFP_NOWARN);
+ ret = new_slrc_guc_id(guc, ce);
+
if (unlikely(ret < 0))
return ret;
--
2.34.1
next reply other threads:[~2022-01-13 16:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 16:27 Matthew Brost [this message]
2022-01-13 17:10 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flip guc_id allocation partition (rev3) Patchwork
2022-01-13 18:11 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flip guc_id allocation partition (rev4) Patchwork
2022-01-13 20:24 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flip guc_id allocation partition (rev5) Patchwork
2022-01-13 21:39 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-02-02 22:15 ` [Intel-gfx] [PATCH] drm/i915: Flip guc_id allocation partition Michal Wajdeczko
2022-02-03 17:37 ` Matthew Brost
-- strict thread matches above, loose matches on Subject: below --
2022-01-13 3:38 Matthew Brost
2022-01-11 16:30 Matthew Brost
2022-01-12 8:54 ` Tvrtko Ursulin
2022-01-12 17:09 ` Piotr Piórkowski
2022-01-12 17:23 ` Matthew Brost
2022-01-12 23:21 ` Michal Wajdeczko
2022-01-12 23:26 ` Matthew Brost
2022-01-13 14:18 ` Michal Wajdeczko
2022-01-13 16:00 ` Matthew Brost
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=20220113162747.4017-1-matthew.brost@intel.com \
--to=matthew.brost@intel.com \
--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