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

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

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?

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