Re: [PATCH v9] drm/i915/dg2: Add per-context control for Wa_22013059131

["Yao, Jia" <jia.yao@intel.com>]

On 9/23/2026 9:54 AM, Joonas Lahtinen wrote:
> Quoting Yao, Jia (2026-09-23 19:01:32)
>> Hi @Joonas Lahtinen,
>>
>> When shifting from WA option #2 to option #1,    removing a global setting ->   adding a per-context setting.  We thought it was a per-context operation.  However, due to the "weakest link" effect, this remains a global operation.
>> Thus, making it per-client has no effect either.  Containers will interfere with each other.
> They would not. On the impacted SKU, the RCS and CCS at any given time
> can only run workloads with matching address space. Those workloads must
> originate from the same DRM client as there is no address space sharing
> across DRM clients implemented in i915.
>
> It's only when multi-CCS SKU would need the same W/A, we would need
> further scheduling decision to ensure 2 CCS workloads are not competing
> for the global setting.
>
> With per DRM client enforcement, both RCS and CCS should be able to
> write the global setting without a conflict. And when a context from new
> DRM client is scheduled it, it should be able to program the global
> value to its liking as the same address space limitation guarantees the
> other workloads are not in the HW anymore.
>
> Regards, Joonas

I understand the benefit of address-space isolation.

However, The bit 15 appears to be a global register rather than an 
address-space-specific state.

If the register itself is not address-space isolated,

I'm struggling to see how address-space isolation alone resolves the 
concern.

Thanks,

Jia

>> Thanks,
>> Jia
>>> -----Original Message-----
>>> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>> Sent: Tuesday, September 22, 2026 11:52 PM
>>> To: Yao, Jia <jia.yao@intel.com>; sashiko-bot@kernel.org; sashiko-
>>> reviews@lists.linux.dev
>>> Cc: dri-devel@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Roper,
>>> Matthew D <matthew.d.roper@intel.com>; Tvrtko Ursulin
>>> <tursulin@ursulin.net>
>>> Subject: RE: [PATCH v9] drm/i915/dg2: Add per-context control for
>>> Wa_22013059131
>>>
>>> Quoting Yao, Jia (2026-09-22 17:34:08)
>>>> Hi @Joonas Lahtinen,
>>>>
>>>> For RCS -> UNSET
>>>> For CCS
>>>> 1. Old compute runtime -> UNSET
>>>> 2. New compute runtime -> USER
>>>>
>>>> If we take there's only one compute runtime version, and priority USER >
>>> UNSET?  Where's the conflict come from?
>>>
>>> See below.
>>>
>>>> But if we take there's more than one compute runtime version, and their
>>> priority is equal,  UNSET can cover USER,  USER can cover UNSET,  even with
>>> two clients they could cover each other.
>>>
>>> I didn't follow this part. How does the priority come into play?
>>>
>>> We have to keep switching the mode as the DRM clients come and go.
>>>
>>>> We should take it easy.
>>>> Once we reached USER, set by new compute, we should latch it, for the WA
>>> has been implemented by USER.
>>>
>>> That won't work. If you are running two different containers, you may have
>>> different compute runtime versions. Also, Mesa can be submitting to CCS too
>>> for async compute, AFAIK.
>>>
>>> To properly cover things, we should make it into per DRM-client setting and
>>> switch the mode accordingly when different DRM client is run.
>>>
>>> And for the given SKU with only one CCS, as explained earlier, it should be
>>> already guaranteed that two different DRM clients are not active on the
>>> hardware at the same time due to the address space mathing requirement
>>> between RCS and CCS.
>>>
>>> If this needs to be extended to multi CCS SKUs, then it'd be a bigger
>>> implementation effort.
>>>
>>> Regards, Joonas
>>>
>>>> Thanks,
>>>> Jia
>>>>
>>>>> -----Original Message-----
>>>>> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>>> Sent: Monday, September 21, 2026 11:47 PM
>>>>> To: Yao, Jia <jia.yao@intel.com>; sashiko-bot@kernel.org; sashiko-
>>>>> reviews@lists.linux.dev
>>>>> Cc: dri-devel@lists.freedesktop.org;
>>>>> intel-gfx@lists.freedesktop.org; Roper, Matthew D
>>>>> <matthew.d.roper@intel.com>; Tvrtko Ursulin <tursulin@ursulin.net>
>>>>> Subject: RE: [PATCH v9] drm/i915/dg2: Add per-context control for
>>>>> Wa_22013059131
>>>>>
>>>>> Quoting Yao, Jia (2026-09-21 20:33:03)
>>>>>> Hi @Lahtinen, Joonas,
>>>>>>
>>>>>> The key is LSC_CHICKEN_BIT_0 is a global register.
>>>>>>
>>>>>> Even we use per-client,  we should consider the following cases:
>>>>>>
>>>>>> 1. Should conflicting configurations within a client be rejected?
>>>>>> I recommend the first setting should be latched.
>>>>>  From uAPI perspective it would be simpler to set this at the DRM
>>>>> client level at once. However we don't seem to have such uAPI in
>>>>> active use currently (all
>>>>> drm_noop) so you'd have to compare the complexity between indirectly
>>>>> setting it at DRM client level by first created context or adding
>>>>> such an uAPI to set it explicitly per client.
>>>>>
>>>>>> 2. Should conflicting configurations across different clients be rejected?
>>>>>> I think the latter setting can cover previous one.
>>>>> DRM clients need to be indepenent from the driver perspective, we
>>>>> can't do that.
>>>>>
>>>>> The whole point of making it per DRM client is that given the
>>>>> impacted SKU only has 1 CCS engine. We have the address space
>>>>> matching requirement between CCS and RCS, so when both CCS and RCS
>>>>> are running, we know they belong to the same DRM client and thus
>>>>> they will not conflict with the WA mode. And if only one of them is
>>>>> running, there can be no conflict either as it's just one context.
>>>>>
>>>>>> Even like this, still can't cover all the race condition.
>>>>> Which race conditions do you think would remain? We definitely have
>>>>> to eliminate any race conditions to land this.
>>>>>
>>>>> Regards, Joonas