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

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

On 9/24/2026 12:21 AM, Joonas Lahtinen wrote:
> Quoting Yao, Jia (2026-09-24 00:20:51)
>> On 9/23/2026 1:29 PM, Matt Roper wrote:
>>> On Wed, Sep 23, 2026 at 11:06:56AM -0700, Yao, Jia wrote:
>>>> 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.
>>> That's why we're doing the special dance with INDIRECT_CTX --- by
>>> re-writing the register on every context switch, we've somewhat turned a
>>> global register into a per-context register.
>>>
>>> If it were possible for two completely unrelated contexts to be running
>>> at the same time (e.g., one on RCS and one on CCS), then we'd wind up
>>> with a case where:
>>>
>>>    * LRC A switches in on engine X and sets the register the way it wants
>>>    * LRC B switches in on engine Y and changes the register to the other
>>>      setting, even though LRC A is still running in parallel
>>>
>>> But fortunately that's not possible on DG2-G11.  On that platform
>>> there's only a single CCS engine (so no possibility for conflicts
>>> between, for example, CCS0 and CCS1).  And there's also another
>>> workaround (implemented in the GuC's scheduler) that ensures that the
>>> RCS and CCS engines are only allowed to run concurrently for LRCs that
>>> have the same address space.  If you try to run two unrelated contexts
>>> at the same on the RCS and CCS, then they'll run sequentially rather
>>> than in parallel.
>>>
>>>
>>> Matt
>> I see. However, if the GuC scheduler already guarantees that workloads
>> from different address spaces are serialized, why don't we use a per-VM
>> (per-address-space) setting instead of a per-client one?
> That is a possibility, that was one of the early suggestions.
>
> However per-VM level control is not foreseen at this time. So we
> probably should still enforce all VMs within DRM client to match.
>
> It all boils down what leads to the most simple implementation.
>
> Regards, Joonas

Agreed, let's go with per-client.

I will do indirectly setting it at DRM client level by first created 
context.
>> Thanks,
>>
>> Jia
>>
>>>> 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