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.
Thanks, Jia > -----Original Message----- > From: Joonas Lahtinen <[email protected]> > Sent: Tuesday, September 22, 2026 11:52 PM > To: Yao, Jia <[email protected]>; [email protected]; sashiko- > [email protected] > Cc: [email protected]; [email protected]; Roper, > Matthew D <[email protected]>; Tvrtko Ursulin > <[email protected]> > 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 <[email protected]> > > > Sent: Monday, September 21, 2026 11:47 PM > > > To: Yao, Jia <[email protected]>; [email protected]; sashiko- > > > [email protected] > > > Cc: [email protected]; > > > [email protected]; Roper, Matthew D > > > <[email protected]>; Tvrtko Ursulin <[email protected]> > > > 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
