Re: [PATCH] drm/xe/xe2: synchronise CS_CHICKEN1 with WMTP support

[Nirmoy Das <nirmoy.das@intel.com>]

Hi Matt,

On 1/2/2024 6:59 PM, Matt Roper wrote:
> On Wed, Dec 27, 2023 at 04:22:49PM +0100, Nirmoy Das wrote:
>> Recommendation is to read FUSE4 register to check if WMTP has been
>> enabled/disabled by HW. If enabled we don't need to do anything special,
>> however if disabled recommendation is to also disable the WMTP mode in
>> the FF_SLICE_CS_CHICKEN2 register, falling back to thread-group and
>> mid-batch preemption only. However on Linux, the per-context CS_CHICKEN1
>> is how userspace controls pre-emption, so instead use the default lrc to
>> disable WMPT using CS_CHICKEN1, if disabled by HW. Userspace is still
>> free to set CS_CHICKEN1 to whatever they want later.
>>
>> HSD: 16016466292
> We don't need this line.
I will remove it.
>
>> Cc: Matt Roper <matthew.d.roper@intel.com>
>> Co-developed-by: Matthew Auld <matthew.auld@intel.com>
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>> ---
>>   drivers/gpu/drm/xe/regs/xe_gt_regs.h |  1 +
>>   drivers/gpu/drm/xe/xe_hw_engine.c    | 28 ++++++++++++++++++++++++++++
>>   2 files changed, 29 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/regs/xe_gt_regs.h b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
>> index 6aaaf1f63c72..37bb54187d1d 100644
>> --- a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
>> +++ b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
>> @@ -148,6 +148,7 @@
>>   #define XEHP_FUSE4				XE_REG(0x9114)
>>   #define   CCS_EN_MASK				REG_GENMASK(19, 16)
>>   #define   GT_L3_EXC_MASK			REG_GENMASK(6, 4)
>> +#define   CFEG_WMTP_DISABLE			REG_BIT(20)
> Nitpick:  bits are usually defined in descending order so this should be
> above the 19-16 field.
Will do that.
>
>>   
>>   #define	MIRROR_FUSE3				XE_REG(0x9118)
>>   #define   XE2_NODE_ENABLE_MASK			REG_GENMASK(31, 16)
>> diff --git a/drivers/gpu/drm/xe/xe_hw_engine.c b/drivers/gpu/drm/xe/xe_hw_engine.c
>> index 832989c83a25..c212ca2c8625 100644
>> --- a/drivers/gpu/drm/xe/xe_hw_engine.c
>> +++ b/drivers/gpu/drm/xe/xe_hw_engine.c
>> @@ -316,6 +316,26 @@ static bool xe_hw_engine_match_fixed_cslice_mode(const struct xe_gt *gt,
>>   	       xe_rtp_match_first_render_or_compute(gt, hwe);
>>   }
>>   
>> +static bool xe_rtp_cfeg_wmtp_disabled(const struct xe_gt *gt,
>> +				      const struct xe_hw_engine *hwe)
>> +{
>> +
>> +	bool mtp_disabled;
>> +
>> +	if (GRAPHICS_VER(gt_to_xe(gt)) < 20)
>> +		return false;
>> +
>> +	if (hwe->class != XE_ENGINE_CLASS_COMPUTE &&
>> +	    hwe->class != XE_ENGINE_CLASS_RENDER)
>> +		return false;
>> +
>> +	mtp_disabled = REG_FIELD_GET(CFEG_WMTP_DISABLE,
>> +				     xe_mmio_read32(hwe->gt,
>> +						    XEHP_FUSE4));
>> +	return mtp_disabled;
>> +
>> +}
>> +
>>   void
>>   xe_hw_engine_setup_default_lrc_state(struct xe_hw_engine *hwe)
>>   {
>> @@ -346,6 +366,14 @@ xe_hw_engine_setup_default_lrc_state(struct xe_hw_engine *hwe)
>>   		  XE_RTP_ACTIONS(FIELD_SET(RCU_MODE, RCU_MODE_FIXED_SLICE_CCS_MODE,
>>   					   RCU_MODE_FIXED_SLICE_CCS_MODE))
>>   		},
>> +		{ XE_RTP_NAME("16016466292"),
> ID numbers only get used for workarounds (i.e., the lineage number to
> let us correlate the status across multiple platforms).  For
> functional/feature-based programming, we should just use a descriptive
> string instead of a number.
Sorry, I missed that from your last review.
>
>> +		  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(2000, XE_RTP_END_VERSION_UNDEFINED),
>> +			       FUNC(xe_rtp_cfeg_wmtp_disabled)),
> The xe_rtp_cfeg_wmtp_disabled function already checks the graphics
> version, so filtering based on graphics version again here is redundant.
>
>> +		  XE_RTP_ACTIONS(FIELD_SET(CS_CHICKEN1(0),
>> +					   PREEMPT_GPGPU_LEVEL_MASK,
>> +					   PREEMPT_GPGPU_THREAD_GROUP_LEVEL)),
>> +		  XE_RTP_ENTRY_FLAG(FOREACH_ENGINE)
>> +		},
>>   		{}
>>   	};
> It sounds like it might be important to also convey this information to
> the userspace drivers so that they'll be aware of whether WMTP is
> available or not, so we'll probably need to add that to the uapi at some
> point.  But that's separate from the work here and can be done as a
> follow-up after this patch lands.

Agreed, I am planning to have discussion in out xe-sync on how to do 
that(query,sysfs or other)


thanks,

Nirmoy

>
>
> Matt
>
>>   
>> -- 
>> 2.42.0
>>