[MTL] Lite restore causes significant flickering in Firefox

Hello! I understand that MTL support is not POR for xe.ko, but I've been using it reliably every day on my primary work laptop for a long time now.

Recently I upgraded and encountered a lot of flickering and flashing artifacts in Firefox, near the top of windows. Scrolling through the Mesa CI Jenkins website (downloaded to a static .html for consistency) was an easy way to reliably reproduce the issue. See the attached screencast:

Screencast_20250302_211350

I was able to bisect this to:

commit 6ef3bb60557d5e7f5af442c8c9ef0a9190bf3d23
Author:     Fei Yang <fei.yang@intel.com>
AuthorDate: Thu Oct 17 09:27:10 2024 -0700

    drm/xe: enable lite restore

And, I confirmed that drm-tip 2025y-02m-21d-19h-54m-34s with GUC_CTL_ENABLE_LITE_RESTORE removed fixes the misrendering.

For reference, I'm using this hardware:

0000:00:02.0 VGA compatible controller [0300]: Intel Corporation Meteor Lake-P [Intel Arc Graphics] [8086:7d55] (rev 08)

running Archlinux, KDE 6.3.1, and my GuC version is:

[    2.179547] xe 0000:00:02.0: [drm] Using GuC firmware from i915/mtl_guc_70.bin version 70.36.0

I also tried to reproduce this on various platforms:

• Battlemage B570/B580 is working fine
• Meteorlake - broke (reported here)
• Alderlake GT1 - seems to be working fine. I only did a few minutes of testing, but Firefox rendered with zero issues.
• Tigerlake GT2 - firefox seemed okay, but KDE System Settings had some flickering, which seemed to go away with Lite Restore disabled. But, I'm honestly not positive about these results (I had just done a massive system upgrade). I can try to collect clearer data if it's of interest.

I could submit a patch to disable lite restore on Meteorlake (or pre-Xe2?) if that's of interest. Or if you have other ideas for things to try, I'm happy to test out patches or collect data. Thanks!

+@Fei-Yang +@rodrigovivi

added platform: MTL_P regression labels

changed the description

added community label

My first instinct was to send a revert to this. But it does look like some corner case and perhaps due to missing workarounds in MTL. I am using MTL with Xe myself as well, with this enabled and no visible issue.

@johnharr @mattrope thoughts on this?

It sounds like some sort of cache coherency and/or missing synchronisation issue. It could potentially be related to a missing w/a.

The lite restore feature means that GuC will potentially be keeping contexts on the hardware rather than switching between them when an active context gets more work. I.e. if interleaving work on two contexts - A1, B1, A2, B2, A3, B3, ... then unless there is explicit synchronisation that sequence might now be A1, A2, B1, B2, B3, A3, ...

Given that patch has been in the tree since last October, it seems odd that no-one has hit this before. Is there anything special about this system?

If it can't be reproduced on any official Xe platform then I would be tempted to put it down as a quirk of MTL, being an unsupported platform and with w/a's potentially missing. In which case we just disable lite restore on that platform and call it good.

Debugging this is going to be extremely difficult if it can't be isolated to a nice simple test case. And for a non-POR platform, it doesn't seem like the ROI is going to be worth it.

Can't think of much special about this system. It's a production Asus Vivobook S5406MA laptop.

I haven't tested Lunarlake. Alderlake working makes some sense, since...most of the WA are there, and in terms of cache flushing, it has LLC for coherency. Battlemage...is a discrete platform with VRAM. Meteorlake has non-coherent buffers and no LLC, so...more sensitive to that kind of issue, maybe.

My apologies for not reporting it earlier. I'm using distro kernels on my laptop, and according to git tag --contains 6ef3bb, it first appeared in v6.13 (mid-January). I lagged a bit in upgrading and then getting around to bisecting and reporting.

Yeap, perhaps MTL is more sensible or perhaps it is a missed workaround, or both. At this point I agree with @johnharr that perhaps the best approach is to filter MTL out.

Did anyone try enabling the guc lite restore in i915 to see if it suffers from the same problems?

Cc : @Fei-Yang

mentioned in issue #4532

I don't know if this is related, but I'm having a really similar issue on Arch Linux ever since I upgraded to Linux 6.13.1.

• OS: Arch Linux
• Kernel: Linux 6.13.6.arch1-1
• DE/WM: GNOME 47.5 on Wayland (Mutter)
• Resolution: 2560x1440p at 240Hz
• Mesa: 25.1.0-devel (git-9da1af6eb2)
• GPU: Intel Arc A750 (Using Xe driver instead of i915)
• Firefox: 136.0
• Intel Media Driver: 25.1.2

Using Xe driver. GNOME Wayland session. Firefox running natively on Wayland, VAAPI hardware video acceleration is enabled and working.

It only started happening after update to 6.13.1. I can't confirm if the issue is also present in 6.13, as Arch Linux never got it, but I'm pretty sure it is. But I can confirm that it is not present in any 6.12 version. Tried all 6.12 versions from 6.12.10 to 6.12.18, issue just isn't present. That's why I've been running the LTS kenel since the upgrade to 6.13, Firefox is unusable like this. It's also present in 6.14-rc1 as well.

I'm attaching a video of it here. I'm happy to provide logs if you want.

video

Update to Linux 6.13 also resulted in MangoHud reporting 0% GPU utilization as soon as it would hit 100%. As reported here: #4532

Can confirm same issue on desktop with i5-12400F and Intel Arc A770, reverting commit 6ef3bb60 fixes it

FYI: Patch posted by @zhanjund to disable lite restore on MTL: https://patchwork.freedesktop.org/series/146448/

Patch with fix (adding link now that gitlab's back online): https://lists.freedesktop.org/archives/intel-xe/2025-March/073997.html