[PATCH v2 1/2] drm/xe/xe2_lpg: Introduce performance guide changes

[Matt Roper]

On Wed, Jan 10, 2024 at 11:45:30AM +0530, Shekhar Chauhan wrote:
> Add various performance guide changes to Xe2LPG.
> 
> BSpec: 72161
> Signed-off-by: Shekhar Chauhan <shekhar.chauhan at intel.com>
> ---
>  drivers/gpu/drm/xe/regs/xe_gt_regs.h |  9 +++++++++
>  drivers/gpu/drm/xe/xe_tuning.c       | 15 ++++++++++++++-
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/regs/xe_gt_regs.h b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> index 4017319c6300..77dd11be9816 100644
> --- a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> +++ b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> @@ -144,6 +144,10 @@
>  
>  #define GSCPSMI_BASE				XE_REG(0x880c)
>  
> +#define CCCHKNREG1				XE_REG_MCR(0x8828)
> +#define   COMPOVFDIS				REG_BIT(25)

I don't see this bit defined in this register on page 59251.  There's
just a generic placeholder field from 31:24 for extra chicken bits.

> +#define   ENCOMPPERFFIX				REG_BIT(18)
> +
>  /* Fuse readout registers for GT */
>  #define XEHP_FUSE4				XE_REG(0x9114)
>  #define   CFEG_WMTP_DISABLE			REG_BIT(20)
> @@ -289,12 +293,17 @@
>  #define XEHP_L3NODEARBCFG			XE_REG_MCR(0xb0b4)
>  #define   XEHP_LNESPARE				REG_BIT(19)
>  
> +#define L3SQCREG3				XE_REG_MCR(0xb108)
> +#define   COMPPWOVERFETCHEN			REG_BIT(28)
> +
>  #define XEHP_L3SQCREG5				XE_REG_MCR(0xb158)
>  #define   L3_PWM_TIMER_INIT_VAL_MASK		REG_GENMASK(9, 0)
>  
>  #define XEHP_L3SCQREG7				XE_REG_MCR(0xb188)
>  #define   BLEND_FILL_CACHING_OPT_DIS		REG_BIT(3)
>  
> +#define L3SCRUB_LBCF_GFX			XE_REG_MCR(0xb18c)
> +
>  #define XEHPC_L3CLOS_MASK(i)			XE_REG_MCR(0xb194 + (i) * 8)
>  
>  #define XE2LPM_L3SQCREG5			XE_REG_MCR(0xb658)
> diff --git a/drivers/gpu/drm/xe/xe_tuning.c b/drivers/gpu/drm/xe/xe_tuning.c
> index 53ccd338fd8c..c0bc86f131a7 100644
> --- a/drivers/gpu/drm/xe/xe_tuning.c
> +++ b/drivers/gpu/drm/xe/xe_tuning.c
> @@ -37,7 +37,20 @@ static const struct xe_rtp_entry_sr gt_tunings[] = {
>  	  XE_RTP_ACTIONS(FIELD_SET(XE2LPM_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
>  				   REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f)))
>  	},
> -
> +	{ XE_RTP_NAME("Tuning: L3 Scrubber Parameters"),
> +	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(2004, XE_RTP_END_VERSION_UNDEFINED)),
> +	  XE_RTP_ACTIONS(SET(L3SCRUB_LBCF_GFX, 0x1006))

It's a bit unclear whether this setting applies to Xe2 or not.  It was a
setting added to that bspec page for PVC, but the way they tagged the
row has made it unclear which other platform(s) it should also apply
to; we may want to check on that offline before trying to adjust this
setting.

Also, even though the bspec people are sometimes lazy and just slap a
raw hex value on the tuning page, it's better if we still define the
specific bits we're changing.  That way we can confirm on future
platforms that the bits still have the same meaning and still apply (and
we won't accidentally clobber any unrelated bits if there are changes
elsewhere in the register between platforms.

> +	},
> +	{ XE_RTP_NAME("Tuning: Compression Overfetch"),
> +	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(2004, XE_RTP_END_VERSION_UNDEFINED)),
> +	  XE_RTP_ACTIONS(SET(CCCHKNREG1,
> +			     COMPOVFDIS |
> +			     ENCOMPPERFFIX)),

As noted above, I don't see any mention of COMPOVFDIS / bit 25 on the
tuning page.  However there are actually two different rows for this
same register in the table which just differ based on the value of bit
18, and in theory we're supposed to select between them based on
characteristics of the platform SKU.  We don't have a good way to
directly determine those characteristics directly in code, but LNL SKUs
should correspond to the rightmost column on bspec 71051, which in turn
implies that we want the first setting (the "disable" row).


> +	},
> +	{ XE_RTP_NAME("Tuning: Compressible Partial Write Overfetch Optimization"),
> +	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(2004, XE_RTP_END_VERSION_UNDEFINED)),
> +	  XE_RTP_ACTIONS(SET(L3SQCREG3, COMPPWOVERFETCHEN))
> +	},

This is another one where the bspec tagging isn't really handled right.
Reading through the backstory, it sounds like it's probably correct to
apply this to Xe2, although I've requested confirmation on the
associated record.  We can go forward with this one, but keep an eye on
the ticket in case we get a response that says otherwise.


Matt

>  	{}
>  };
>  
> -- 
> 2.34.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation