All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/sseu: Don't overallocate subslice storage
Date: Fri, 11 Mar 2022 12:52:33 -0800	[thread overview]
Message-ID: <20220311205233.gouq77jvvxv73tie@ldmartin-desk2> (raw)
In-Reply-To: <Yiu0fIwiRNfPWqVI@mdroper-desk1.amr.corp.intel.com>

On Fri, Mar 11, 2022 at 12:43:40PM -0800, Matt Roper wrote:
>On Fri, Mar 11, 2022 at 12:38:17PM -0800, Matt Roper wrote:
>> On Fri, Mar 11, 2022 at 11:00:09AM -0800, Lucas De Marchi wrote:
>> > On Thu, Mar 10, 2022 at 10:15:42PM -0800, Matt Roper wrote:
>> > > Xe_HP removed "slice" as a first-class unit in the hardware design.
>> > > Instead we now have a single pool of subslices (which are now referred
>> > > to as "DSS") that different hardware units have different ways of
>> > > grouping ("compute slices," "geometry slices," etc.).  For the purposes
>> > > of topology representation, we treat Xe_HP-based platforms as having a
>> > > single slice that contains all of the platform's DSS.  There's no need
>> > > to allocate storage space for (max legacy slices * max dss); let's
>> > > update some of our macros to minimize the storage requirement for sseu
>> > > topology.  We'll also document some of the constants to make it a little
>> > > bit more clear what they represent.
>> > >
>> > > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>> > > ---
>> > > drivers/gpu/drm/i915/gt/intel_engine_types.h |  2 +-
>> > > drivers/gpu/drm/i915/gt/intel_sseu.h         | 47 +++++++++++++++-----
>> > > 2 files changed, 36 insertions(+), 13 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h
>> > > index 4fbf45a74ec0..f9e246004bc0 100644
>> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
>> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
>> > > @@ -645,7 +645,7 @@ intel_engine_has_relative_mmio(const struct intel_engine_cs * const engine)
>> > >
>> > > #define for_each_instdone_gslice_dss_xehp(dev_priv_, sseu_, iter_, gslice_, dss_) \
>> > > 	for ((iter_) = 0, (gslice_) = 0, (dss_) = 0; \
>> > > -	     (iter_) < GEN_MAX_SUBSLICES; \
>> > > +	     (iter_) < GEN_SS_MASK_SIZE; \
>> > > 	     (iter_)++, (gslice_) = (iter_) / GEN_DSS_PER_GSLICE, \
>> > > 	     (dss_) = (iter_) % GEN_DSS_PER_GSLICE) \
>> > > 		for_each_if(intel_sseu_has_subslice((sseu_), 0, (iter_)))
>> > > diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h b/drivers/gpu/drm/i915/gt/intel_sseu.h
>> > > index 8a79cd8eaab4..4f59eadbb61a 100644
>> > > --- a/drivers/gpu/drm/i915/gt/intel_sseu.h
>> > > +++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
>> > > @@ -15,26 +15,49 @@ struct drm_i915_private;
>> > > struct intel_gt;
>> > > struct drm_printer;
>> > >
>> > > -#define GEN_MAX_SLICES		(3) /* SKL upper bound */
>> > > -#define GEN_MAX_SUBSLICES	(32) /* XEHPSDV upper bound */
>> > > -#define GEN_SSEU_STRIDE(max_entries) DIV_ROUND_UP(max_entries, BITS_PER_BYTE)
>> > > -#define GEN_MAX_SUBSLICE_STRIDE GEN_SSEU_STRIDE(GEN_MAX_SUBSLICES)
>> > > -#define GEN_MAX_EUS		(16) /* TGL upper bound */
>> > > -#define GEN_MAX_EU_STRIDE GEN_SSEU_STRIDE(GEN_MAX_EUS)
>> > > +/*
>> > > + * Maximum number of legacy slices.  Legacy slices no longer exist starting on
>> > > + * Xe_HP ("gslices," "cslices," etc. on Xe_HP and beyond are a different
>> > > + * concept and are not expressed through fusing).
>> > > + */
>> > > +#define GEN_MAX_LEGACY_SLICES		3
>> > > +
>> > > +/*
>> > > + * Maximum number of subslices that can exist within a legacy slice.  This is
>> > > + * only relevant to pre-Xe_HP platforms (Xe_HP and beyond use the GEN_MAX_DSS
>> > > + * value below).
>> > > + */
>> > > +#define GEN_MAX_LEGACY_SUBSLICES	6
>> >
>> > instead of calling the old legacy, maybe just add the XEHP_ prefix to
>> > the new ones?
>>
>> Maybe a "HSW_" prefix on the old ones would be better?  People still use
>> the termm 'subslice' in casual discussion when talking about DSS, so I
>> want to somehow distinguish that what we're talking about here is a
>> different, older design than we have on modern platforms.
>
>Hmm, or maybe just "GEN_MAX_SUBSLICES_PER_LEGACY_SLICE" to tie it into
>the slice definition above?

I'm not too fond of calling it "legacy" when everywhere else in the driver
we just use the platform as prefix/suffix. Some may see legacy as
< ver 12, others as 12.50, etc.

Well... but I will leave that up to you if you are convinced one is
better than the other.

thanks
Lucas De Marchi

  reply	other threads:[~2022-03-11 20:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11  6:15 [Intel-gfx] [PATCH 1/2] drm/i915/sseu: Don't overallocate subslice storage Matt Roper
2022-03-11  6:15 ` Matt Roper
2022-03-11  6:15 ` [Intel-gfx] [PATCH 2/2] drm/i915/xehp: Update topology dumps for Xe_HP Matt Roper
2022-03-11  6:15   ` Matt Roper
2022-03-11 14:44   ` [Intel-gfx] " kernel test robot
2022-03-11 14:44   ` kernel test robot
2022-03-11 19:33   ` [RFC PATCH] drm/i915/xehp: intel_sseu_get_geometry_subslices() can be static kernel test robot
2022-03-11 19:33     ` [Intel-gfx] " kernel test robot
2022-03-11 19:33   ` [Intel-gfx] [PATCH 2/2] drm/i915/xehp: Update topology dumps for Xe_HP kernel test robot
2022-03-11 19:59   ` Lucas De Marchi
2022-03-11  6:31 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/sseu: Don't overallocate subslice storage Patchwork
2022-03-11  6:32 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-03-11  7:03 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-11  9:17 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-11 19:00 ` [Intel-gfx] [PATCH 1/2] " Lucas De Marchi
2022-03-11 20:38   ` Matt Roper
2022-03-11 20:43     ` Matt Roper
2022-03-11 20:52       ` Lucas De Marchi [this message]
2022-03-11 21:01         ` Ville Syrjälä
2022-03-11 21:11           ` Matt Roper

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=20220311205233.gouq77jvvxv73tie@ldmartin-desk2 \
    --to=lucas.demarchi@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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 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.