[Intel-gfx] [PATCH v4 12/18] drm/i915/xehpsdv: Define MOCS table for XeHP SDV
Matt Roper
matthew.d.roper at intel.com
Fri Jul 30 17:01:19 UTC 2021
On Fri, Jul 30, 2021 at 12:16:14AM -0700, Siddiqui, Ayaz A wrote:
>
>
> > -----Original Message-----
> > From: De Marchi, Lucas <lucas.demarchi at intel.com>
> > Sent: Thursday, July 29, 2021 11:01 PM
> > To: Roper, Matthew D <matthew.d.roper at intel.com>
> > Cc: intel-gfx at lists.freedesktop.org; Siddiqui, Ayaz A
> > <ayaz.siddiqui at intel.com>; Daniel Vetter <daniel.vetter at 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 at 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 at intel.com>
> > >Signed-off-by: Lucas De Marchi <lucas.demarchi at intel.com>
> > >Signed-off-by: Stuart Summers <stuart.summers at intel.com>
> > >Signed-off-by: Matt Roper <matthew.d.roper at 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 at 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
More information about the Intel-gfx
mailing list