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 <[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
