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 jia.yao@intel.com Cc: Alex Zuo alex.zuo@intel.com Cc: Shuicheng Lin shuicheng.lin@intel.com Cc: Xin Wang x.wang@intel.com Cc: stable@vger.kernel.org Cc: Matt Roper matthew.d.roper@intel.com
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