Hi, this is a regression from mesa 24.3.4-3. I'm filing with RC severity because this affects not only me but also other users on the BananaPI [1] and by preventing mesa from transitioning to testing, downgrading mesa is much easier than when having to cherry-pick it from snapshot.d.o. I plan to bisect mesa between 24.3.4-3 and 25.0.0-1. Do you have a recipe that you use for this purpose that you can share with me? I've done it a few months ago but lost my notes from back then. Thanks! cheers, josch [1] https://community.mnt.re/t/display-flickering-on-pocket-reform-related-to-mesa-25-0-0/3133
Dear maintainer(s), dear Johannes, dear everyone. Potentially related – happens with mesa 25.0.0-1 on Devuan Ceres (which uses Debian unstable packages for most of the installed packages including mesa) with KDE Plasma 6.3 desktop on Qt 6.7.2: Flickering and various graphics related glitches with mesa 25.0.0-1 on ThinkPad T14 AMD Gen 5 with AMD Ryzen 7 PRO 8840U w/ Radeon 780M Graphics: % lspci -nn | grep VGA c4:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix3 [1002:1900] (rev d0) Not found on ThinkPad T14 AMD Gen 2 with older integrated AMD graphics. Not found on older 24.x mesa on either of those machines. Happens after a while of working with the machine after a fresh start. Flickering, graphical glitches, looks like graphical memory being corrupted. Did not yet run any hardware checks but I doubt any hardware failure is at play here. Usually nothing in kernel log. Once I had something, not sure whether it would be related but it was just a soft timeout: 2025-02-27_08:09:58.38198 kern.err: [16371.675177] amdgpu 0000:c4:00.0: amdgpu: ring gfx_0.0.0 timeout, but soft recovered Can produce the rest of this back trace in case it would be relevant. But I believe it is unrelated. Not opening a different issue at the moment. Can do so if you like. If so please advice on which exact package to use for the report. Thanks,
Hi, MNT Reform forum user deianara identified upstream commit e0f48568c7f2a638213dee317fde03c23775556f as the origin of the regression on BananaPI CM4. I verified that reverting this commit on top of mesa 25 indeed fixes the problem. Patch attached. your flicker effects are probably unrelated to the ones that this bug is about because the fix for this bug is a change in mesa's panfrost driver which is unrelated to your radeon card. Thanks! cheers, josch
Hi, I have a Pine64 PineTab2 (rk3566) which also has an Arm Mali-G52 GPU and I was NOT able to reproduce the issue. I played the exact same MNT video in Firefox, but also playing a (local) video in mpv didn't show any issues. I'm using sway as wayland compositor. So I looked a bit further into the differences and noticed it's using an Amlogic A311D SoC. That the bisected commit mentions "Some MTK display controller drivers" indicates the problem could be in that direction. But even before reading about the bisected commit, I had a look at the dts[i] files for BananaPI (``arch/arm64/boot/dts/amlogic/meson-g12b*``). There was 1 property in particular that I was 'missing' and that was ``mali-supply``, so I'd recommend to test if adding that makes a difference. See also the example in the DT binding schema: ``Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml`` I'll leave possibly changing the severity up to the maintainer, but I don't think "making it easier to downgrade" is a valid reason in itself. You can add a line to sources.list referencing a particular date in the snapshot.d.o archive and then constructing (and sharing in the MNT forums) a line/command like this: ``aptitude install <mesa-pkg1>=<24.x> <mesa-pkg2>=<24.x>`` HTH, Diederik
Given the bisected commit, this is not actually a bug in panfrost/mesa. This is likely a bug in the display controller not handling the relevant AFBC formats correctly. We're seeing the same on Mediatek devices at the moment. If you could dump the output of /sys/kernel/debug/dri/*/framebuffer while running into these issues that would be very helpful (as that will show the modifiers in use). It would also be helpful if you could mention the display stack you're using (e.g. which compositor). At least in my testing gnome wasn't impacted as that didn't seem to be using modifiers. If you're using weston you could try with WESTON_DISABLE_GBM_MODIFIERS=1 set in the environment to avoid modifier usage. Regards, Sjoerd
Quoting Diederik de Haas (2025-03-04 11:42:17) yesterday and it seems that this issue does not even affect all users of Mali-G52 graphics: https://oftc.irclog.whitequark.org/panfrost/2025-03-05 I am lowering severity accordingly. Thanks! cheers, josch
Hi Sjoerd, sorry for having failed to follow up on this. I didn't check whether this bug report had new messages. Diederik has kindly pinged me that your message still needs a response. Thank you, Diederik! I've put Lukas F. Hartmann as the CEO of MNT Research in CC. I built a kernel without 32x8 AFBC disabled and am now back with a machine where I observe the regular flicker effect. I attached the contents of /sys/kernel/debug/dri/ff900000.vpu/framebuffer to this mail. I've also attached the output of `drm_info /dev/dri/card0`. I'm running sway (as shown in the framebuffer attachment). Thanks! cheers, josch
Hey, On Sat, 2025-04-12 at 08:10 +0200, Johannes Schauer Marin Rodrigues wrote: <snip> Modifier: ARM_AFBC(BLOCK_SIZE = 32x8, SPLIT, SPARSE) (0x800000000000062 Which pretty much means that this is an issue with the meson display driver not handling AFBC entirely correct. Which likely never surfaced before as mesa wasn't actively using that. So same issue as we're chasing on some MTK devices atm.
Hi, In case it could be useful, I started sway on my PineTab2 and collected the same info. I only started sway and then foot to run the commands. See attachments. Cheers, Diederik
1) my output had several properties that yours didn't 2) the reported sizes, which seem related to resolution, were much larger then with me There was a recent thread on linux-rockchip about AFBC and that rk3399 doesn't support that with resolutions > 2560x1600 https://lore.kernel.org/linux-rockchip/20250417065759.5948-1-mail@etehtsea.me/ Dunno if such an issue could be at play, but I figured I'd share it in case it could help. Cheers, Diederik