intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: "Siddiqui, Ayaz A" <ayaz.siddiqui@intel.com>
Cc: "De Marchi, Lucas" <lucas.demarchi@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"Lahtinen, Joonas" <joonas.lahtinen@intel.com>
Subject: Re: [Intel-gfx] [PATCH v4 12/18] drm/i915/xehpsdv: Define MOCS table for XeHP SDV
Date: Fri, 30 Jul 2021 10:01:19 -0700	[thread overview]
Message-ID: <20210730170119.GS1556418@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <BL3PR11MB5746ACB01581D35806A1AA57FCEC9@BL3PR11MB5746.namprd11.prod.outlook.com>

On Fri, Jul 30, 2021 at 12:16:14AM -0700, Siddiqui, Ayaz A wrote:
> 
> 
> > -----Original Message-----
> > From: De Marchi, Lucas <lucas.demarchi@intel.com>
> > Sent: Thursday, July 29, 2021 11:01 PM
> > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; Siddiqui, Ayaz A
> > <ayaz.siddiqui@intel.com>; Daniel Vetter <daniel.vetter@ffwll.ch>
> > Subject: Re: [Intel-gfx] [PATCH v4 12/18] drm/i915/xehpsdv: Define MOCS
> > table for XeHP SDV
> >
> > On Thu, Jul 29, 2021 at 10:00:02AM -0700, Matt Roper wrote:
> > >From: Lucas De Marchi <lucas.demarchi@intel.com>
> > >
> > >Like DG1, XeHP SDV doesn't have LLC/eDRAM control values due to being a
> > >dgfx card. XeHP SDV adds 2 more bits: L3_GLBGO to "push the Go point to
> > >memory for L3 destined transaction" and L3_LKP to "enable Lookup for
> > >uncacheable accesses".
> > >
> > >Bspec: 45101
> > >Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > >Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > >Signed-off-by: Stuart Summers <stuart.summers@intel.com>
> > >Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >
> > +Ayaz,  +Daniel
> >
> > I think this can't land as is since we risk forgetting additional changes that we
> > will have to do. We already made the mistake once of forgetting MOCS
> > changes.
> >
> > There are some patches to initialize unused MOCS entries and similar that
> > should have been sent already to upstream. Ayaz, what's the state of those
> > patches?
> There are two section of patches .
> 1. Programming to  CMD_CCTL for with UC this patch should sent for upstream.
> I'll share the patches for CMD_CCTL programming.
> 2. Programming of unused/unspecified MOCS index to WB, we observed some
> regression on media use cases. So we decided to delay  upstreaming of
> those patches till  MOCS programming are fixed in UMDs.

I don't follow on #2.  At the moment we don't have a complete XeHP SDV
driver upstream (the device IDs aren't even there and won't be for a
while) so there's nothing that can regress yet from an upstream point of
view --- you can't run a UMD at all today.  If internal builds of the
UMDs run against our internal staging trees are still buggy and won't
work properly with the proper MOCS table settings, then that just makes
it more important to upstream these patches now so that the UMD's don't
come to rely on the incorrect table values.  If we wait until later
after the driver is "complete" and we've already enabled first contact
of the UMDs in general, then we won't be able to update the MOCS
programming to the proper values anymore without breaking ABI.

Unless you're talking about regressing older platforms?  In that case we
should be able to restrict the WB programming to just Xe_HP SDV for now;
ultimately we'll probably need to figure out some kind of opt-in
mechanism for the older platforms, but that can be separate from doing
it unconditionally on Xe_HP SDV and beyond I think.


Matt

> Regards
> -Ayaz
> 
> >
> > Lucas De Marchi
> >
> > >---
> > > drivers/gpu/drm/i915/gt/intel_mocs.c | 33
> > +++++++++++++++++++++++++++-
> > > 1 file changed, 32 insertions(+), 1 deletion(-)
> > >
> > >diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > >b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > >index 17848807f111..0c9d0b936c20 100644
> > >--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > >+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > >@@ -40,6 +40,8 @@ struct drm_i915_mocs_table {
> > > #define L3_ESC(value)               ((value) << 0)
> > > #define L3_SCC(value)               ((value) << 1)
> > > #define _L3_CACHEABILITY(value)     ((value) << 4)
> > >+#define L3_GLBGO(value)             ((value) << 6)
> > >+#define L3_LKUP(value)              ((value) << 7)
> > >
> > > /* Helper defines */
> > > #define GEN9_NUM_MOCS_ENTRIES       64  /* 63-64 are reserved, but
> > configured. */
> > >@@ -314,6 +316,31 @@ static const struct drm_i915_mocs_entry
> > dg1_mocs_table[] = {
> > >     MOCS_ENTRY(63, 0, L3_1_UC),
> > > };
> > >
> > >+static const struct drm_i915_mocs_entry xehpsdv_mocs_table[] = {
> > >+    /* wa_1608975824 */
> > >+    MOCS_ENTRY(0, 0, L3_3_WB | L3_LKUP(1)),
> > >+
> > >+    /* UC - Coherent; GO:L3 */
> > >+    MOCS_ENTRY(1, 0, L3_1_UC | L3_LKUP(1)),
> > >+    /* UC - Coherent; GO:Memory */
> > >+    MOCS_ENTRY(2, 0, L3_1_UC | L3_GLBGO(1) | L3_LKUP(1)),
> > >+    /* UC - Non-Coherent; GO:Memory */
> > >+    MOCS_ENTRY(3, 0, L3_1_UC | L3_GLBGO(1)),
> > >+    /* UC - Non-Coherent; GO:L3 */
> > >+    MOCS_ENTRY(4, 0, L3_1_UC),
> > >+
> > >+    /* WB */
> > >+    MOCS_ENTRY(5, 0, L3_3_WB | L3_LKUP(1)),
> > >+
> > >+    /* HW Reserved - SW program but never use. */
> > >+    MOCS_ENTRY(48, 0, L3_3_WB | L3_LKUP(1)),
> > >+    MOCS_ENTRY(49, 0, L3_1_UC | L3_LKUP(1)),
> > >+    MOCS_ENTRY(60, 0, L3_1_UC),
> > >+    MOCS_ENTRY(61, 0, L3_1_UC),
> > >+    MOCS_ENTRY(62, 0, L3_1_UC),
> > >+    MOCS_ENTRY(63, 0, L3_1_UC),
> > >+};
> > >+
> > > enum {
> > >     HAS_GLOBAL_MOCS = BIT(0),
> > >     HAS_ENGINE_MOCS = BIT(1),
> > >@@ -340,7 +367,11 @@ static unsigned int get_mocs_settings(const struct
> > >drm_i915_private *i915,  {
> > >     unsigned int flags;
> > >
> > >-    if (IS_DG1(i915)) {
> > >+    if (IS_XEHPSDV(i915)) {
> > >+            table->size = ARRAY_SIZE(xehpsdv_mocs_table);
> > >+            table->table = xehpsdv_mocs_table;
> > >+            table->n_entries = GEN9_NUM_MOCS_ENTRIES;
> > >+    } else if (IS_DG1(i915)) {
> > >             table->size = ARRAY_SIZE(dg1_mocs_table);
> > >             table->table = dg1_mocs_table;
> > >             table->n_entries = GEN9_NUM_MOCS_ENTRIES;
> > >--
> > >2.25.4
> > >
> > >_______________________________________________
> > >Intel-gfx mailing list
> > >Intel-gfx@lists.freedesktop.org
> > >https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795

  reply	other threads:[~2021-07-30 17:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 16:59 [Intel-gfx] [PATCH v4 00/18] Begin enabling Xe_HP SDV and DG2 platforms Matt Roper
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 01/18] drm/i915/xehp: handle new steering options Matt Roper
2021-08-04 19:53   ` Lucas De Marchi
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 02/18] drm/i915/xehpsdv: Define steering tables Matt Roper
2021-08-04 20:13   ` Lucas De Marchi
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 03/18] drm/i915/dg2: Add forcewake table Matt Roper
2021-08-04  0:15   ` Souza, Jose
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 04/18] drm/i915/dg2: Update LNCF steering ranges Matt Roper
2021-08-04 20:16   ` Lucas De Marchi
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 05/18] drm/i915/dg2: Add SQIDI steering Matt Roper
2021-08-04 20:22   ` Lucas De Marchi
2021-08-05 15:11     ` Matt Roper
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 06/18] drm/i915/xehp: Loop over all gslices for INSTDONE processing Matt Roper
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 07/18] drm/i915/dg2: Report INSTDONE_GEOM values in error state Matt Roper
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 08/18] drm/i915/xehp: Changes to ss/eu definitions Matt Roper
2021-08-04  0:17   ` Souza, Jose
2021-07-29 16:59 ` [Intel-gfx] [PATCH v4 09/18] drm/i915/xehpsdv: Add maximum sseu limits Matt Roper
2021-08-04 20:26   ` Lucas De Marchi
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 10/18] drm/i915/xehpsdv: Add compute DSS type Matt Roper
2021-08-04 20:36   ` Lucas De Marchi
2021-08-04 21:00     ` Matt Roper
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 11/18] drm/i915/dg2: DG2 uses the same sseu limits as XeHP SDV Matt Roper
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 12/18] drm/i915/xehpsdv: Define MOCS table for " Matt Roper
2021-07-29 17:31   ` Lucas De Marchi
2021-07-30  7:16     ` Siddiqui, Ayaz A
2021-07-30 17:01       ` Matt Roper [this message]
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 13/18] drm/i915/dg2: Define MOCS table for DG2 Matt Roper
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 14/18] drm/i915/xehpsdv: factor out function to read RP_STATE_CAP Matt Roper
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 15/18] drm/i915/xehpsdv: Read correct RP_STATE_CAP register Matt Roper
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 16/18] drm/i915/dg2: Add new LRI reg offsets Matt Roper
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 17/18] drm/i915/dg2: Maintain backward-compatible nested batch behavior Matt Roper
2021-07-29 17:00 ` [Intel-gfx] [PATCH v4 18/18] drm/i915/dg2: Configure PCON in DP pre-enable path Matt Roper
2021-07-29 20:59 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Begin enabling Xe_HP SDV and DG2 platforms (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=20210730170119.GS1556418@mdroper-desk1.amr.corp.intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=ayaz.siddiqui@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@intel.com \
    --cc=lucas.demarchi@intel.com \
    --subject='Re: [Intel-gfx] [PATCH v4 12/18] drm/i915/xehpsdv: Define MOCS table for XeHP SDV' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).