From: Andi Shyti <andi.shyti@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
John Harrison <John.C.Harrison@intel.com>,
stable@vger.kernel.org, Andi Shyti <andi.shyti@kernel.org>,
Tvrtko Ursulin <tursulin@ursulin.net>
Subject: Re: [PATCH v5 2/4] drm/i915/gt: Refactor uabi engine class/instance list creation
Date: Tue, 12 Mar 2024 21:49:39 +0100 [thread overview]
Message-ID: <ZfC_4ztSF7Nv0F1m@ashyti-mobl2.lan> (raw)
In-Reply-To: <20240312170833.GL718896@mdroper-desk1.amr.corp.intel.com>
On Tue, Mar 12, 2024 at 10:08:33AM -0700, Matt Roper wrote:
> On Fri, Mar 08, 2024 at 09:22:17PM +0100, Andi Shyti wrote:
> > For the upcoming changes we need a cleaner way to build the list
> > of uabi engines.
> >
> > Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
> > Cc: <stable@vger.kernel.org> # v6.2+
>
> I don't really see why we need patches 2 & 3 in this series.
For patch number '2' We had a round of review with Tvrtko and we
wanted to avoid the change I pasted at the bottom[*], which would
decrease something that was increased earlier.
> If we want
> to restrict the platform to a single CCS engine for now (and give that
> single engine access to all of the cslices), it would be much simpler to
> only create a single intel_engine_cs which which would then cause both
> i915 and userspace to only consider a single engine, even if more than
> one is physically present. That could be done with a simple adjustment
> to engine_mask_apply_compute_fuses() to mask off extra bits from the
> engine mask such that only a single CCS can get returned rather than the
> mask of all CCSs that are present.
>
> Managing all of the engines in the KMD but only exposing one (some) of
> them to userspace might be something we need if you want to add extra
> functionality down to road to "hotplug" extra engines, or to allow
> userspace to explicitly request multi-CCS mode. But none of that seems
> necessary for this series, especially for something you're backporting
> to stable kernels.
It's true, it would even be easier to mask out all the CCS
engines after the first. I thought of this.
On one hand hand, adding a for_each_available_engine() throught
the stable path its a bit of abusing, but it's functional to the
single CCS mode.
I was aiming for a longer term solution. If I add a patch to mask
off CCS engines, then I will need to revert it quite soon for
the stable release.
I'm not sure which one is better, though.
Thanks,
Andi
[*]
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..7041acc77810 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -243,6 +243,15 @@ void intel_engines_driver_register(struct drm_i915_private *i915)
if (engine->uabi_class == I915_NO_UABI_CLASS)
continue;
+ /*
+ * Do not list and do not count CCS engines other than the first
+ */
+ if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
+ engine->uabi_instance > 0) {
+ i915->engine_uabi_class_count[engine->uabi_class]--;
+ continue;
+ }
+
rb_link_node(&engine->uabi_node, prev, p);
rb_insert_color(&engine->uabi_node, &i915->uabi_engines);
next prev parent reply other threads:[~2024-03-12 20:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 20:22 [PATCH v5 0/4] Disable automatic load CCS load balancing Andi Shyti
2024-03-08 20:22 ` [PATCH v5 1/4] drm/i915/gt: Disable HW load balancing for CCS Andi Shyti
2024-03-12 16:58 ` Matt Roper
2024-03-12 20:37 ` Andi Shyti
2024-03-08 20:22 ` [PATCH v5 2/4] drm/i915/gt: Refactor uabi engine class/instance list creation Andi Shyti
2024-03-12 17:08 ` Matt Roper
2024-03-12 20:49 ` Andi Shyti [this message]
2024-03-08 20:22 ` [PATCH v5 3/4] drm/i915/gt: Disable tests for CCS engines beyond the first Andi Shyti
2024-03-08 20:25 ` kernel test robot
2024-03-08 20:22 ` [PATCH v5 4/4] drm/i915/gt: Enable only one CCS for compute workload Andi Shyti
2024-03-08 21:14 ` ✗ Fi.CI.CHECKPATCH: warning for Disable automatic load CCS load balancing (rev7) Patchwork
2024-03-08 21:14 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-03-08 21:28 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-09 12:00 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-03-12 23:32 ` ✗ Fi.CI.BUILD: failure for Disable automatic load CCS load balancing (rev8) 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=ZfC_4ztSF7Nv0F1m@ashyti-mobl2.lan \
--to=andi.shyti@linux.intel.com \
--cc=John.C.Harrison@intel.com \
--cc=andi.shyti@kernel.org \
--cc=chris.p.wilson@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=matthew.d.roper@intel.com \
--cc=stable@vger.kernel.org \
--cc=tursulin@ursulin.net \
/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.