On Tue, Dec 16, 2025 at 12:02:21AM +0000, Jia Yao wrote:
> Previous fix enabled LSC chicken bit FORCE_1_SUB_MESSAGE_PER_FRAGMENT.
> This caused side effects on 128EU SKUs. Updated solution limits SLM
> allocation to 96KB which is done at UMD to avoid these issues and
> ensure stable behavior.
I don't think we can make a change like this, at least not without more
supporting information proving that it's safe and won't cause any
regressions. The workaround documentation effectively says "Either the
KMD needs to do XXX or the UMD needs to do YYY." The lines being
removed below are the "XXX" in this case, but we run the risk of causing
a regression if someone is using an old build of the userspace driver,
but upgrades to a new kernel that has removed this code --- they could
be left without coverage of this workaround from either the KMD or the
UMD.
I think there are a couple options here:
- If all of the UMDs (Mesa and compute) have been limiting SLM
allocation to 96KB since the very beginning of their DG2-G11 support
(i.e., it's never been possible to build a UMD driver that runs on
DG2-G11 and _doesn't_ do that), then it's safe to remove the KMD
handling below since we're guarnateed to always be covered by the
UMD, no matter how old the UMD build is. To take this option, we
need to prove via git history for those UMD drivers that this is
always the cause.
- If there's a real problem with the workaround as documented today
and it turns out that the programming we're doing in the KMD never
had any benefit, then we can remove the KMD code. To take this
option, we'd need formal clarification on that from the hardware
teams, including an official update by them to the text of the
workaround in the WA DB so that we're sure that removing it can only
improve the situation, never harm it.
- If this workaround had been updating a per-context register, then
if there had been a way for the KMD to detect that the UMD already
set this 96KB limit (either automatically, or via some kind of
"opt-in" flag in the uapi), then it could have been okay to
conditionally skip applying this code when that case is detected, and
only apply the workaround in cases where it was not detected.
However in this case it appears we're programming a system-wide
register (not a per-context register) so the setting here will affect
every process on the system, including those that haven't started
running yet. Even if we detect one UMD that's applying the 96K
limit, there may be other UMDs or other versions of the same UMD also
on the system (e.g., in a container) that won't apply the limit.
That means we don't know the behavior of future processes that
haven't started yet, and we can't take this option for this
workaround.
- The final option is to just leave things as is. Even if the UMD
limit performs better than the KMD workaround implementation, the "no
regressions even with old userspace" rule takes precedence, so we
can't justify risking a regression for some users just to boost
performance for other users.
Matt
>
> Bspec: 54833
> Fixes: 645cc0b9d972 ("drm/i915/dg2: Add initial gt/ctx/engine workarounds")
> Signed-off-by: Jia Yao <[email protected]>
> Cc: Alex Zuo <[email protected]>
> Cc: Shuicheng Lin <[email protected]>
> Cc: Xin Wang <[email protected]>
> Cc: [email protected]
> Cc: Matt Roper <[email protected]>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index ece88c612e27..abb47c65f43a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2866,10 +2866,6 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> MAXREQS_PER_BANK,
> REG_FIELD_PREP(MAXREQS_PER_BANK, 2));
>
> - /* Wa_22013059131:dg2 */
> - wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0,
> - FORCE_1_SUB_MESSAGE_PER_FRAGMENT);
> -
> /*
> * Wa_22012654132
> *
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
