Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	Chris Wilson <chris.p.wilson@linux.intel.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 1/3] drm/i915/gt: Support fixed CCS mode
Date: Fri, 5 Jan 2024 10:39:31 +0000	[thread overview]
Message-ID: <73f0a8e9-3fd6-45a9-a084-b5308900ca8f@linux.intel.com> (raw)
In-Reply-To: <ZZchsRQ5Kc-x9dlk@ashyti-mobl2.lan>


On 04/01/2024 21:23, Andi Shyti wrote:
> Hi Tvrtko,
> 
> [1]
> 
>>> +	/*
>>> +	 * Loop over all available slices and assign each a user engine.
>>> +	 *
>>> +	 * With 1 engine (ccs0):
>>> +	 *   slice 0, 1, 2, 3: ccs0
>>> +	 *
>>> +	 * With 2 engines (ccs0, ccs1):
>>> +	 *   slice 0, 2: ccs0
>>> +	 *   slice 1, 3: ccs1
>>> +	 *
>>> +	 * With 4 engines (ccs0, ccs1, ccs2, ccs3):
>>> +	 *   slice 0: ccs0
>>> +	 *   slice 1: ccs1
>>> +	 *   slice 2: ccs2
>>> +	 *   slice 3: ccs3
>>> +	 *
>>> +	 * Since the number of slices and the number of engines is
>>> +	 * known, and we ensure that there is an exact multiple of
>>> +	 * engines for slices, the double loop becomes a loop over each
>>> +	 * slice.
>>> +	 */
>>> +	for (i = num_slices / num_engines; i < num_slices; i++) {
>>> +		struct intel_engine_cs *engine;
>>> +		intel_engine_mask_t tmp;
>>> +
>>> +		for_each_engine_masked(engine, gt, ALL_CCS(gt), tmp) {
>>> +			/* If a slice is fused off, leave disabled */
>>> +			while (!(CCS_MASK(gt) & BIT(slice)))
>>> +				slice++;
>>> +
>>> +			mode &= ~XEHP_CCS_MODE_CSLICE(slice, XEHP_CCS_MODE_CSLICE_MASK);
>>> +			mode |= XEHP_CCS_MODE_CSLICE(slice, engine->instance);
>>> +
>>> +			/* assign the next slice */
>>> +			slice++;
>>> +		}
>>> +	}
>>> +
>>> +	intel_uncore_write(gt->uncore, XEHP_CCS_MODE, mode);
>>> +}
>>> +
>>> +void intel_gt_apply_ccs_mode(struct intel_gt *gt)
>>> +{
>>> +	mutex_lock(&gt->ccs.mutex);
>>> +	__intel_gt_apply_ccs_mode(gt);
>>> +	mutex_unlock(&gt->ccs.mutex);
>>> +}
>>> +
>>> +void intel_gt_init_ccs_mode(struct intel_gt *gt)
>>> +{
>>> +	mutex_init(&gt->ccs.mutex);
>>> +	gt->ccs.mode = 1;
>>
>> What is '1'? And this question carries over to the sysfs interface in the
>> following patch - who will use it and where it is documented how to use it?
> 
> The value '1' is explained in the comment above[1] and in the

Do you mean this is mode '1':

  * With 1 engine (ccs0):
  *   slice 0, 1, 2, 3: ccs0

?

But I don't see where it says what do different modes mean on different 
SKU configurations.

It also does not say what should the num_slices sysfs file be used for.

Does "mode N" mean "assign each command streamer N compute slices"? Or 
"assign each compute slice N command streamers"?

I wonder if we should add something user friendly into 
Documentation/ABI/*/sysfs-... Joonas your thoughts?

> comment below[2]. Maybe we should give it an enum meaning? But
> that would be something like CCS_MODE_1/2/4, I thinks
> ccs.mode = 1/2/4 is more understandable.
> 
>> Also, should this setting somehow be gated by an applicable platform? Or if
>> not on setting then when acting on it in __intel_gt_apply_ccs_mode?
>>
>> Creation of sysfs files as well should be gated by platform too in the
>> following patch?
> 
> The idea of this series is to disable the CCS load balancing
> (which automatically chooses between mode 1/2/4) and used the
> a fixed scheme chosen by the user.
> 
> (I'm preparing v3 as Chris was so kind to recommend some changes
> offline)

Okay lets wait for v2 and I will then see if I will this that will make 
it clearer to casual observers.

Regards,

Tvrtko


> Thanks,
> Andi
> 
> [2]
> 
>>> +	/*
>>> +	 * Track fixed mapping between CCS engines and compute slices.
>>> +	 *
>>> +	 * In order to w/a HW that has the inability to dynamically load
>>> +	 * balance between CCS engines and EU in the compute slices, we have to
>>> +	 * reconfigure a static mapping on the fly. We track the current CCS
>>> +	 * configuration (set by thr user through a sysfs interface) and compare
>>> +	 * it against the current CCS_MODE (which maps CCS engines to compute
>>> +	 * slices). If there is only a single engine selected, we can map it to
>>> +	 * all available compute slices for maximal single task performance
>>> +	 * (fast/narrow). If there are more then one engine selected, we have to
>>> +	 * reduce the number of slices allocated to each engine (wide/slow),
>>> +	 * fairly distributing the EU between the equivalent engines.
>>> +	 */
>>> +	struct {
>>> +		struct mutex mutex;
>>> +		u32 mode;
>>> +	} ccs;

  reply	other threads:[~2024-01-05 10:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-04 14:35 [PATCH v2 0/3] Disable dynamic load balancing and support fixed balancing Andi Shyti
2024-01-04 14:35 ` [PATCH v2 1/3] drm/i915/gt: Support fixed CCS mode Andi Shyti
2024-01-04 15:07   ` Tvrtko Ursulin
2024-01-04 21:23     ` Andi Shyti
2024-01-05 10:39       ` Tvrtko Ursulin [this message]
2024-01-08 15:13         ` Joonas Lahtinen
2024-01-09  8:46           ` Tvrtko Ursulin
2024-01-04 14:35 ` [PATCH v2 2/3] drm/i915/gt: Allow user to set up the CSS mode Andi Shyti
2024-01-04 14:35 ` [PATCH v2 3/3] drm/i915/gt: Disable HW load balancing for CCS Andi Shyti
2024-01-04 15:04 ` ✗ Fi.CI.CHECKPATCH: warning for Disable dynamic load balancing and support fixed balancing Patchwork
2024-01-04 15:04 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-04 15:23 ` ✗ Fi.CI.BAT: 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=73f0a8e9-3fd6-45a9-a084-b5308900ca8f@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=andi.shyti@linux.intel.com \
    --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 \
    /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