Arch Linux

Similar report appeared in upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7352

Same issue here, it seems most Qt app happened, some characters disappear (i.e. not render and left space).
With AMD Renoir/Cezanne iGPU,
in KDE Plasma 5.25.90 (a.k.a. 5.26 beta) Waylan
Downgrading to 22.1.7 workaround the problem.

Seeing this breakage with Gnome too. Downgrading mesa was the fix I had to apply.

just to add, Navi (OpenGL: renderer: AMD Radeon RX 6750 XT (navy_flounder)) is also affected with KDE X11 (wayland untested)

The stability issues / concerns have already been mentioned at phoronix [1] on Sept. 20th. It seems that mesa-22.2.0 is a bit rushed. The official release notes warn, although included in every major new mesa release, that one should wait for the minor point release, which means 22.2.1.

In case more issues arrive, it would be a good time to consider downgrading if officially. That's up to the maintainer of course, I just wanted to point out, that 22.2.0 is a bit special, because there was no more update in about a month in the 22.2 branch after rc3 and then out of a sudden a stable release. This was also discussed on the mesa mailing list [2].

So, just a heads up, there might even be more issues.


[1]: https://www.phoronix.com/news/Mesa-22.2-Released
[2]: https://lists.freedesktop.org/archives/mesa-dev/2022-September/225849.html

Just to add more data, I'm also getting rendering glitches on a RX 580. Reverting to extra/multilib mesa fixes the issues.

I can confirm that testing/mesa 22.2.0 is a bit munted.

Downgrading to 22.1.7 resolves all graphical issues.

Vega 56 user here, downgrading was a must since KDE (Wayland) was very much broken with 22.2.0.

It seems like disabling LTO for mesa fixes these issues. This bug was reported a few weeks ago upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6911


So setting

options=('debug' '!lto')

and adding

-D b_lto=false \

to the arch-meson call to disable LTO could be a temporary fix.

Having the same issue on GNOME wayland running an RX 570, my GNOME shell and GNOME apps are almost entirely borked but other applications are running just fine.

I can confirm that the changes suggested by @scrumplex regarding lto lead to a working mesa 22.2 on my Navi GPU. Typing this while running a self-built non-lto mesa 22.2 based on the official PKGBUILD with only the 2 lto changes made.

If that can be a viable workaround for the packages is up to the maintainers to decide.

+1 under sway with a Ryzen 7 5850U/Cezanne. Foot (terminal) & Steam badly b0rked.

+1 under KDE. Everything is very borked, including the desktop environment itself and the rendering on VMs using virgl using an RX 480.

Running KDE on Wayland [not X11] with mesa 22.2 and AMD graphics (Radeon RX 6700) and I'm having the same bugs.

I've disabled lto for a temporary fix in 22.2.0-2.

The upstream bug report mentions that one can disable the d3d12 gallium driver as well, which might be a preferable approach?

No problem for me with version 22.2.0-2 using my Ryzen3 2200G GPU by default.

Weirdly, Gnome (Wayland) seems fine for me on 22.2.1 however some games do not. StarCraft 2 in particular just flashes black and then insta-quits. 5700XT and rolling back to 22.1.7 fixes it.

Hello. After upgrading mesa from 22.1.7-1 to 22.2.1-1, Houdini crashes. Downgrading back to 22.1.7-1 restores functionality.

Houdini crash report indicates mesa problems:


> [michael@pocket3 ~] $ cat /tmp/houdini_temp/crash.HFTNAII_START_v002_023_freestyle_010.michael_7016_log.txt
Crash report from michael; Houdini FX Version 19.5.303 [linux-x86_64-gcc9.3]
Uptime 92 seconds
Fri Nov 4 00:59:11 2022
Caught signal 6

Traceback from 7016 ThreadId=0x7f9774714ec0
AP_Interface::coreDumpChaser(UTsignalHandlerArg) <libHoudiniUI.so>
AP_Interface::si_CrashHandler::chaser(UTsignalHandlerArg) <libHoudiniUI.so>
signalCallback(UTsignalHandlerArg) <libHoudiniUT.so>
UT_Signal::UT_ComboSignalHandler::operator()(int, siginfo_t*, void*) const <libHoudiniUT.so>
UT_Signal::processSignal(int, siginfo_t*, void*) <libHoudiniUT.so>
__sigaction <libc.so.6>
pthread_key_delete <libc.so.6>
raise <libc.so.6>
abort <libc.so.6>
[0x98c1f] <iris_dri.so>
nouveau_drm_screen_create <iris_dri.so>
__driDriverGetExtensions_d3d12 <iris_dri.so>
__driDriverGetExtensions_d3d12 <iris_dri.so>
glPrimitiveBoundingBox <libGLX_mesa.so.0>
glAreTexturesResidentEXT <libGLX_mesa.so.0>
glIsTextureEXT <libGLX_mesa.so.0>
qt_plugin_instance <libqxcb-glx-integration.so>
QOpenGLContext::swapBuffers(QSurface*) <libQt5Gui.so.5>
RE_Server::GLSwapBuffers(RE_Window*) <libHoudiniUI.so>
UI_Window::swapBuffers() <libHoudiniUI.so>
UI_Window::doRedrawSubclass() <libHoudiniUI.so>
dm_ViewLayoutWindow::doRedrawSubclass() <libHoudiniAPPS3.so>
UI_Window::doRedraw() <libHoudiniUI.so>
UI_Queue::doWindowRedraws() <libHoudiniUI.so>
UI_Queue::processNextEvent() <libHoudiniUI.so>
UI_Queue::drain() <libHoudiniUI.so>
UI_Queue::eventLoop() <libHoudiniUI.so>
main <libHoudiniUI.so>
__libc_init_first <libc.so.6>
__libc_start_main <libc.so.6>
main <houdini-bin>

22.2.2 fixes it for me!

just a heads up @lordheavy @felixonmars @AndyRTR
I compiled mesa-22.3.0-rc4 against staging with lto re-enabled. The original issue of rendering breakage still happens. lto disabled and the issue does not appear. Seems like this needs to stay for longer.

Hello! Thanks for testing Mesa3D with LTO; could you build some latest git (or at least 22.3.x) and try to find the smallest test on which it fails together with backtrace (with debug symbols)? I recently enabled LTO build testing in our CI, but it doesn't show any issue.

22.3.2 is still affected, even when build against llvm/clang 15.0.6 on staging.

I am not skilled enough to develop/look for tests or backtraces. I usually build the mesa-packages with modifying the PKGBUILD from the Arch repo, install the packages and reboot, if the issue still appears my DE looks like in the attached screenshot (distorted taskbar and missing/broken fonts) in which case I reinstall the packages without LTO and reboot again.

I don't have time to compile the git package at the moment, will report back when I had time.

I don't see the issue on mesa 22.3.2 compiled with LTO enabled. As well as with latest mesa-git.

I found some time, mesa 22.3.3 against staging with LTO is still affected.

mesa-git with LTO is fixed at least when built against staging.

@lordheavy @felixonmars @AndyRTR

I have compiled and used mesa23 since mesa23-rc2 with LTO reenabled, and have now used the PKGBUILD from testing with the 2 lines changed to reenable LTO and rebuild it for my systems: No rendering breakage occured, and no other issues appeared.

At least for what I can test, I'd say it's now safe to reenable LTO again.