You are not logged in.
Maybe I should try to install vulkan-nouveau before trying the export?
That would have been the idea, yes.
But it will only make zink work, mesa should still fall back to llvm
Offline
I want to help by giving as much info as possible, so I will:
- First try to update mesa + export NOUVEAU_USE_ZINK=0
- Then (whether it works or not) update mesa + install vulkan-nouveau + export NOUVEAU_USE_ZINK=1
- If nothing works, cry
Or is anything else useful?
Offline
You do not have to explicitly "export NOUVEAU_USE_ZINK=1" and ultimately you'll want to install vulkan-nouveau (if you intend to keep using nouveau instead of nvidia) no matter what for vulkan support.
If nothing works, cry
There's a mesa bug that needs to be sorted out, we're trying to gather some information to pin it, then the mesa devs will do the crying part
Offline
You do not have to explicitly "export NOUVEAU_USE_ZINK=1"
So I'm still unclear on export/the root cause of the bug: if I update mesa, export ZINK=0, then reboot, it should not try to use zink at the next boot, right? Then why shouldn't I explicitly export ZINK=1 for testing with vulkan-nouveau? (Or is zink the broken one anyway?)
Sorry for the newb questions, those are not problems that arose in my ten years of using Arch (lucky me!).
EDIT²: Wait, I'm a real newb... /etc/profile is a file, so I just add the export line anywhere in it and remove it if I want to switch back? I thought it'd be a line to use in the right directory, sorry. >_>
ultimately you'll want to install vulkan-nouveau (if you intend to keep using nouveau instead of nvidia) no matter what for vulkan support.
This is good to know, so anyway I'll keep this installed.
I'd rather use nouveau than the nvidia drivers which have a proprietary/closed part, if I read correctly.
EDIT: Also tbh the wiki page for nvidia https://wiki.archlinux.org/title/NVIDIA makes it look like I'd need to fiddle with many things, which I'd like to avoid.
There's a mesa bug that needs to be sorted out, we're trying to gather some information to pin it, then the mesa devs will do the crying part
And I am very thankful!!! This is probably not said enough.
Last edited by lama_noob (2025-06-10 14:57:40)
Offline
zink implements opengl on top of vulkan, if vzlkan desn't work, zink doesn't work, opengl doesn't work
which is why the driver should then use the llvmpipe opengl implementation and has done so in the past.
now it's using zink and fails hard.
right now we want to see whether zink actually even works w/ an underlying vulkan support
Offline
Thanks for the explanation!
I wanted to update my system (bar mesa) before trying the two things (ZINK=0 and vulkan-nouveau), but for some reason it broke the graphical display (I can use tty, but wayland/gnome don't seem to work). I have to repair this before, sorry. Will edit the post with information when it's done.
EDIT: I am pleased to report that installing vulkan-nouveau and updating mesa to 1:25.1.3-3 appears to have fixed everything (initial issue and new issue). Apparently several interconnected things (gdm, mesa, etc) were linked and I needed to fully upgrade.
So now booting leads me to the login screen, as intended, and a wayland+gnome session. I will try again later to see that it's not a happy coincidence. ^^"
I will not go further tonight, but if anyone wants any additional testing done, please ask! I cannot guarantee that I can do it fast, but I'll try to help as I can.
Last edited by lama_noob (2025-06-10 17:49:13)
Offline
I have some questions:
1. So, did you just installed vulkan-nouveau and updated to newest mesa or did you additionally export(ed) NOUVEAU_USE_ZINK=0 somewhere and if yes, then where?
2. Does OpenGL apps run without glitches, run slower, faster, or with same speed (fps)?
3. What CPU and nvidia GPU do you have?
Offline
Hi,
1. So, did you just installed vulkan-nouveau and updated to newest mesa or did you additionally export(ed) NOUVEAU_USE_ZINK=0 somewhere and if yes, then where?
I did a full update of the system (minus mesa, this broke the wayland display), but yes the only real change was installing vulkan-nouveau and updating mesa.
I can post the whole update log tomorrow to get the full list of updated packages. (For example, I think gpgmepp was installed by the update as a dependency, but this shouldn't have an impact...)
2. Does OpenGL apps run without glitches, run slower, faster, or with same speed (fps)?
What are good common examples of OpenGL apps so that I can try? ^^; (Sorry)
3. What CPU and nvidia GPU do you have?
From earlier (short version here, details there):
00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-S UHD Graphics (rev 04)
01:00.0 VGA compatible controller: NVIDIA Corporation AD107GLM [RTX 1000 Ada Generation Laptop GPU] (rev a1)
Last edited by lama_noob (2025-06-10 20:55:12)
Offline
Some examples of OpenGL apps to test (starting from simplest up to games, all are in arch repository and display number of fps):
- apps: glxgears, glxgears_fbconfig, glmark2, vkmark
- games: sauerbraten, warsow, xonotic, supertuxkart, armagetronad, etc.
It would be nice to see changes before and after update to new mesa.
Last edited by xerxes_ (2025-06-10 21:44:16)
Offline
None of those is gonna be a particular challenge for the GPU, though?
https://aur.archlinux.org/packages?K=unigine
Offline
None of those is gonna be a particular challenge for the GPU, though?
That depends on hardware and settings, but if that would be much differences, it should be seen in most demanding at least.
Does zink requires additional CPU power? Does 'export NOUVEAU_USE_ZINK=0' disables zink completely and make usage of old llvmpipe opengl implementation?
Last edited by xerxes_ (2025-06-10 21:53:25)
Offline
It's a translation layer, but https://www.collabora.com/news-and-blog … -zink.html
At this point, we're fairly confident that Zink+NVK will be an improvement over Nouveau GL across the board.
The source is of course "trust us, bro", no actual benchmarks…
Does 'export NOUVEAU_USE_ZINK=0' disables zink completely and make usage of old llvmpipe opengl implementation?
It seems to work, so yes. Do does apparently "MESA_LOADER_DRIVER_OVERRIDE=llvmpipe"
Offline
To give the full picture:
- Previous update I ran was on June 4th (enf of the afternoon, Paris time)
- Yesterday I did the following update:
upgraded adwaita-cursors (48.0-1 -> 48.1-1)
upgraded adwaita-icon-theme (48.0-1 -> 48.1-1)
upgraded alsa-card-profiles (1:1.4.4-1 -> 1:1.4.5-1)
upgraded linux-api-headers (6.14-1 -> 6.15-1)
upgraded sqlite (3.50.0-1 -> 3.50.1-1)
upgraded audit (4.0.3-1 -> 4.0.5-1)
upgraded automake (1.17-1 -> 1.18-1)
upgraded s2n-tls (1.5.19-1 -> 1.5.20-1)
upgraded aws-crt-cpp (0.32.6-1 -> 0.32.8-1)
upgraded curl (8.14.0-2 -> 8.14.1-1)
upgraded aws-sdk-cpp-core (1.11.575-1 -> 1.11.579-1)
upgraded aws-sdk-cpp-iam (1.11.575-1 -> 1.11.579-1)
upgraded aws-sdk-cpp-s3 (1.11.575-1 -> 1.11.579-1)
upgraded bolt (0.9.8-1 -> 0.9.9-1)
upgraded llvm-libs (19.1.7-2 -> 20.1.6-3)
upgraded compiler-rt (19.1.7-1 -> 20.1.6-1)
upgraded clang (19.1.7-2 -> 20.1.6-1)
upgraded x265 (4.0-1 -> 4.1-1)
upgraded pixman (0.46.0-1 -> 0.46.2-1)
upgraded leancrypto (1.3.0-1 -> 1.4.0-1)
upgraded mpg123 (1.32.10-1 -> 1.33.0-1)
upgraded libusb (1.0.28-1 -> 1.0.29-1)
upgraded libbpf (1.5.0-1 -> 1.5.1-1)
upgraded ffmpeg (2:7.1.1-3 -> 2:7.1.1-4)
upgraded ffmpeg4.4 (4.4.5-5 -> 4.4.6-1)
upgraded libgdm (48.0-1 -> 48.0-2)
upgraded gtk-update-icon-cache (1:4.18.5-2 -> 1:4.18.6-1)
upgraded gstreamer (1.26.2-1 -> 1.26.2-2)
upgraded gst-plugins-base-libs (1.26.2-1 -> 1.26.2-2)
upgraded gst-plugins-bad-libs (1.26.2-1 -> 1.26.2-2)
upgraded gtk4 (1:4.18.5-2 -> 1:4.18.6-1)
upgraded gnupg (2.4.7-2 -> 2.4.7-3)
upgraded gpgme (1.24.3-2 -> 2.0.0-1)
upgraded volume_key (0.3.12-10 -> 0.3.12-11)
installed gpgmepp (2.0.0-2)
upgraded poppler (25.05.0-1 -> 25.05.0-2)
upgraded poppler-glib (25.05.0-1 -> 25.05.0-2)
upgraded libpipewire (1:1.4.4-1 -> 1:1.4.5-1)
upgraded pipewire (1:1.4.4-1 -> 1:1.4.5-1)
upgraded libgirepository (1.84.0-1 -> 1.84.0-2)
upgraded gobject-introspection-runtime (1.84.0-1 -> 1.84.0-2)
upgraded pipewire-audio (1:1.4.4-1 -> 1:1.4.5-1)
upgraded lua (5.4.7-1 -> 5.4.8-1)
upgraded pipewire-session-manager (1:1.4.4-1 -> 1:1.4.5-1)
upgraded pipewire-pulse (1:1.4.4-1 -> 1:1.4.5-1)
upgraded pulse-native-provider (1:1.4.4-1 -> 1:1.4.5-1)
upgraded gdm (48.0-1 -> 48.0-2)
upgraded libheif (1.19.8-1 -> 1.19.8-3)
upgraded openexr (3.3.3-1 -> 3.3.4-1)
upgraded pacman (7.0.0.r6.gc685ae6-2 -> 7.0.0.r6.gc685ae6-6)
upgraded gimp (3.0.4-2 -> 3.0.4-3)
upgraded gnome-maps (48.3-1 -> 48.4-1)
upgraded gst-devtools-libs (1.26.2-1 -> 1.26.2-2)
upgraded gst-python (1.26.2-1 -> 1.26.2-2)
upgraded gst-editing-services (1.26.2-1 -> 1.26.2-2)
upgraded gst-plugin-gtk (1.26.2-1 -> 1.26.2-2)
upgraded gst-plugin-pipewire (1:1.4.4-1 -> 1:1.4.5-1)
upgraded gst-plugins-bad (1.26.2-1 -> 1.26.2-2)
upgraded gst-plugins-base (1.26.2-1 -> 1.26.2-2)
upgraded gst-plugins-good (1.26.2-1 -> 1.26.2-2)
upgraded iputils (20250602-1 -> 20250605-1)
upgraded ldb (2:4.22.1-1 -> 2:4.22.2-1)
upgraded liborcus (0.20.0-2 -> 0.20.1-1)
upgraded libreoffice-still (24.8.7-1 -> 24.8.7-2)
upgraded libupnp (1.14.22-1 -> 1.14.23-1)
upgraded libvlc (3.0.21-20 -> 3.0.21-21)
upgraded libwbclient (2:4.22.1-1 -> 2:4.22.2-1)
upgraded linux (6.14.9.arch1-1 -> 6.15.1.arch1-2)
upgraded orca (48.1-1 -> 48.2-1)
upgraded ostree (2025.2-2 -> 2025.2-3)
upgraded pacman-contrib (1.11.0-1 -> 1.12.0-1)
upgraded poppler-qt6 (25.05.0-1 -> 25.05.0-2)
upgraded postgresql-libs (17.4-4 -> 17.5-2)
upgraded python-numpy (2.2.6-1 -> 2.3.0-1)
upgraded python-requests (2.32.3-4 -> 2.32.4-1)
upgraded qt5-base (5.15.17+kde+r122-1 -> 5.15.17+kde+r123-1)
upgraded smbclient (2:4.22.1-1 -> 2:4.22.2-1)
upgraded samba (2:4.22.1-1 -> 2:4.22.2-1)
upgraded thunderbird (139.0-1 -> 139.0.1-1)
upgraded vim-runtime (9.1.1376-1 -> 9.1.1431-1)
upgraded vim (9.1.1376-1 -> 9.1.1431-1)
upgraded vlc (3.0.21-20 -> 3.0.21-21)
upgraded wxwidgets-common (3.2.8.1-1 -> 3.2.8.1-2)
upgraded wxwidgets-gtk3 (3.2.8.1-1 -> 3.2.8.1-2)
- This broke something for wayland/gdm/gnome, at reboot: a big "Something failed" with a sad emoji. Able to use Ctrl+Alt+F2 to get a tty and login. There was a gdm session running, but display failed for some reason.
- I installed vulkan-nouveau, but still had this new problem:
installed vulkan-nouveau (1:25.1.3-3)
- I tried fiddling by downgrading gdm and libgdm, to no avail. I then tried upgrading mesa:
upgraded mesa (1:25.0.5-1 -> 1:25.1.3-3)
- At reboot, everything worked!
- apps: glxgears, glxgears_fbconfig, glmark2, vkmark
- games: sauerbraten, warsow, xonotic, supertuxkart, armagetronad, etc.
I have none of these, so I cannot assess any change, sorry. I can still install one and report on stability?
Offline
You held back mesa, which was rebuilt against LLVM 20 which will have broken. The bug that prompted you to hold back mesa was likely fixed in 25.1.1 or even earlier already. Generally speaking - don't hold back system packages. and if you're forced to, check the version numbers and retry when that gets increased.
Offline
I finally updated to newest mesa (1:25.1.3-3), but not in one run.
First I have set earlier to ignore mesa and lib32-mesa packages in pacman.conf, do whole system update and after that I lost opengl or drm device (directly after update, without rebooting), so nouveau opengl was not working as it coudn't find device nor any opengl apps. After reboot the situation didn't change, so I searched what package(s) from last update could change it and found libdrm (2.4.124-1 -> 2.4.125-1, but lib32-libdrm stays at version 2.4.124-1). Then I had 2 options: downgrade libdrm or stop blocking mesa update. I choose second option and it looks like it works now: nouveau opengl is working again.
I have set earlier before update 'nvidia_drm.modeset=1' in kernel boot options (but i don't know if that changes something in my case - single gpu).
I don't exported anywhere 'export NOUVEAU_USE_ZINK=0' nor 'export MESA_LOADER_DRIVER_OVERRIDE=llvmpipe' - if everything looks like is working, then why?
I'm experiencing a minor fps drop in games: sauerbraten, warsow, xonotic (a few fps on my old hardware: Geforce GTX 750, Pentium Dual E2140), but on newer hardware I think it would be less noticeable, as Seth said earlier. I don't play much, the games serve as benchmarks, so let it be.
What I noticed is nowhere is written (journalctl logs, Xorg logs) that zink is used; mesa don't write what use. How/where look to see that zink is used?
I also noticed that when vulkan is used, mesa write more caching files to drive (not many, but always a few KB). And this is not only when playing games, but also with some apps using vulkan, like playing videos in mpv.
Last edited by xerxes_ (2025-06-11 19:38:08)
Offline
glxinfo -B
?
Offline
glxinfo don't show zink usage, it only displays:
...
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa (0x10de)
Device: NV117 (0x1381)
Version: 25.1.3
...
OpenGL vendor string: Mesa
...
but running command 'MESA_LOADER_DRIVER_OVERRIDE=zink glxgears' produces variable number of FPS above display refresh rate, running only 'glxgears' produces steady number of FPS limited by display refresh rate, just like before recent and many previous updates.
So it looks like zink is not used by default on my system, but old nouveau opengl implementation.
Last edited by xerxes_ (2025-06-13 09:08:55)
Offline