Closed TheComputerGuy96 closed 4 months ago
Thanks for the report. I suspect this has the same root-cause as the issue you reported earlier https://github.com/NVIDIA/egl-wayland/issues/69, namely that we're passing a buffer to the AMD GPU which isn't aligned to 256 bytes.
The relevant code-path in the driver is used by both EGL and Vulkan applications on Wayland, so the same bug would be present in both cases.
@erik-kz The issue in this case is that NVIDIA specific format modifiers are being used on PRIME setups (the same issue as #41) so it's different from #69
And that causes the Mesa driver to fail because it doesn't understand those NVIDIA specific ones (so linear modifier is the only reliable option)
You've already fixed the OpenGL path with https://github.com/NVIDIA/egl-wayland/commit/866a801264cab29b8554830d844c5fd03227e34c#diff-8965d13061a6bcaea4358bcc9c757a91fbd9b3cc16fcb3bf1dd579c667fc5528R1269 but Vulkan is somehow different :thinking:
Compare these two WAYLAND_DEBUG lines (one is OpenGL on my PRIME setup and the other is Vulkan on the same setup):
[1084918.093] -> zwp_linux_buffer_params_v1@56.add(fd 52, 0, 0, 3840, 0, 0)
[1084918.102] -> zwp_linux_buffer_params_v1@56.create_immed(new id wl_buffer@57, 960, 544, 875713112, 0)
[1005520.777] -> zwp_linux_buffer_params_v1@49.add(fd 73, 0, 0, 3840, 50331648, 6316052)
[1005520.793] -> zwp_linux_buffer_params_v1@49.create_immed(new id wl_buffer@58, 960, 544, 875713089, 0)
Notice the non-zero values for layout modifiers in the Vulkan section?
Ah I see, thanks for the clarification. Yes, this does indeed appear to be a different issue. We use a kind of back-door interface into egl-wayland for Vulkan which has the effect of bypassing the linear buffer allocation. Like the other bug, though, the fix will need to be on the driver side.
Still present in 525.60.11 :(
I have the same issue with an Intel + Nvidia setup. Vulkan apps with native wayland support crash at startup when using the dGPU. Running vkcube-wayland with my dGPU gives me:
prime-run vkcube-wayland
Selected GPU 0: NVIDIA GeForce RTX 3050 Laptop GPU, type: DiscreteGpu
[destroyed object]: error 7: importing the supplied dmabufs failed
Retroarch and Ryujinx also gave me similar results, crashing at startup if I try to run them with prime-run. Running both apps through Xwayland works like a charm, though, as did using the opengl API instead of Vulkan.
My system info:
Distro: Arch Linux egl-wayland version: 1.1.11 Mesa version: 22.2.3-1 Driver version: 525.60.11 Kernel version: 6.0.10 Compositor: kwin 5.26.4 CPU: Intel Core i5-12500H GPU: Mesa Intel(R) Graphics (ADL GT2) iGPU + RTX 3050 Mobile
You've already fixed the OpenGL path with 866a801#diff-8965d13061a6bcaea4358bcc9c757a91fbd9b3cc16fcb3bf1dd579c667fc5528R1269 but Vulkan is somehow different thinking
Wait, are OpenGL applications on Wayland with PRIME offload supposed to work? The windows for the applications never appear on my end, even if they are seemingly running. I'm on 2060 Mobile with nvidia 525.60.11, egl-wayland 1.1.11 and mesa 22.2.4 right now. Running them without PRIME offload works obviously, but it runs on the integrated Intel GPU.
OpenGL applications should work with PRIME offload, yes. Are you using an Intel or AMD integrated GPU? Note that the 525 driver has a bug which prevents it working with AMD (see https://github.com/NVIDIA/egl-wayland/issues/69). This will be fixed in 530.
OpenGL applications should work with PRIME offload, yes. Are you using an Intel or AMD integrated GPU? Note that the 525 driver has a bug which prevents it working with AMD (see #69). This will be fixed in 530.
Thanks for the fast reply! I'm using an Intel integrated GPU.
Running __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/10_nvidia.json prime-run eglgears_wayland
results in the application running without any window appearing (it does seem to 'exist' to Gnome, though. Appears in the list of applications when Alt+Tab'ing), and by looking at nvidia-smi's output, it indeed uses an nvidia GPU:
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.60.11 Driver Version: 525.60.11 CUDA Version: 12.0 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA GeForce ... On | 00000000:01:00.0 Off | N/A |
| N/A 43C P0 15W / N/A | 5MiB / 6144MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| 0 N/A N/A 14975 G eglgears_wayland 3MiB |
+-----------------------------------------------------------------------------+
Here's the console output with WAYLAND_DEBUG=1
, if that can help: https://gist.github.com/Fothsid/c58260a7172c9418c3443e216162bc6b
Are you setting __NV_PRIME_RENDER_OFFLOAD=1? It shouldn't be necessary to set __EGL_VENDOR_LIBRARY_FILENAMES.
prime-run
in my case sets __NV_PRIME_RENDER_OFFLOAD=1
.
Running specifically __NV_PRIME_RENDER_OFFLOAD=1 eglgears_wayland
results in the same thing.
This appears to be a bug in eglgears_wayland. It calls poll() on the Wayland display fd without first calling wl_display_prepare_read https://gitlab.freedesktop.org/mesa/demos/-/blob/main/src/egl/eglut/eglut_wayland.c#L279
Have you tried any other OpenGL applications?
I tried PCSX2. It just hangs on OpenGL with __NV_PRIME_RENDER_OFFLOAD=1
, with the main rendering area not even clearing.
UPDATE: just tried PPSSPP and it seems to work. Not sure what was the problem with PCSX2
UPDATE2: nevermind, PPSSPP was running under xwayland there.
UPDATE3: running PPSSPP with SDL_VIDEODRIVER=wayland __NV_PRIME_RENDER_OFFLOAD=1
results in the same issue that eglgears_wayland had.
Sorry. Turns out I had GRUB configured incorrectly, so DRM mode setting wasn't enabled. Once I got proper nvidia_drm.modeset=1
in GRUB, it started to work.
Oh, cool. We do plan to make modeset=1 the default in the near future. It's just that right now it can cause problems for some workstation SLI configurations.
Possibly related issue described in https://github.com/NVIDIA/open-gpu-kernel-modules/issues/317#issuecomment-1235513079
I wonder why is it the case that offload env variable changes the behaviour, so instead of a crash the program hangs? My assumption would be that the only thing that nv vulkan layer does is changing gpu priority, by reordering or filtering devices, but it seems env variable somehow modifies the behaviour of a swapchain or something, i assume it is not related to the layer? Does it modify some EGL related code that is outside of vulkan, and somehow changes the behaviour that way? What does that offload env variable do exactly?
Our GPUs render using a hardware-specific pixel layout which Intel and AMD GPUs don't understand. When __NV_PRIME_RENDER_OFFLOAD=1 is set, after rendering each frame we will convert it to a linear layout so that the integrated GPU can display it. The code to do that is wired up for OpenGL and Vulkan X11 applications, and OpenGL Wayland applications, but not for Vulkan Wayland applications.
For Vulkan applications, __NV_PRIME_RENDER_OFFLOAD=1 will also enable the NV_optimus layer as you mentioned, which changes the order that GPUs are enumerated so that the NVIDIA GPU will appear first.
Is this related to: vkvia, vulkaninfo from LunarG's SDK are unable to detect the discrete NVIDIA GPU on Ubuntu 22.04/Wayland? Only Intel GPU0, and llvmpipe GPU1 are detected. I'd expect that the application is able to select the desired GPU like on Windows.
Our GPUs render using a hardware-specific pixel layout which Intel and AMD GPUs don't understand. When __NV_PRIME_RENDER_OFFLOAD=1 is set, after rendering each frame we will convert it to a linear layout so that the integrated GPU can display it. The code to do that is wired up for OpenGL and Vulkan X11 applications, and OpenGL Wayland applications, but not for Vulkan Wayland applications.
Thank you for this ELI5-level answer. Are you permitted to let us know if this is in the works? Or if it is tagged as WONTFIX internally? @erik-kz
Still present in 530.30.02 :(
This is not a WONTFIX, we do intend to get it working. And while I can't provide an ETA right now, it will definitely be before we drop Pascal (10-series) support. That won't happen for quite a while, I mean we haven't even dropped Maxwell (9-series) support yet.
I have the exact same issue on Void Linux with driver 525.105.17
. I've encountered this issue on mpv
and the native Linux build of BeamNG.drive. Running them via XWayland fixes it, but still, it would be nice to be able to run them on native Wayland...
This is becoming quite a serious issue for many people. Can this please be made a priority?
@TheComputerGuy96 Does this work in the latest beta driver?
This feature has been implemented by @dkorkmazturk. It will be available in the next major driver version, 545 (not the recently released 535 beta).
After 1.1.12 release it's happening again for some OpenGL apps as well (e.g. mpv: https://github.com/mpv-player/mpv/issues/11774)
This feature has been implemented by @dkorkmazturk. It will be available in the next major driver version, 545 (not the recently released 535 beta).
Is there a known timeline for this version?
For anyone waiting for this update, and wondering when it may come, here's some recent release data (only xx5 releases):
495.29.05 2021-10-14
515.43.04 BETA 2022-05-11
525.53 2022-11-10
535.43.02 2023-05-30
Δ = ~6 months
If one can extrapolate, then I'd expect a release in November '23.
Okay so as of 545.23.06, atleast on KDE wayland, now vkcube-wayland doesn't crash but freezes immediately on startup. The cube is visible but spins very slow, like 1 frame every 5 seconds.
Also, When I tried to run yuzu emulator on wayland with vulkan backend selected, I get the following error:
error marshalling arguments for get_surface_feedback (signature 4no): null value passed for arg 1
Error marshalling request: Invalid argument
The Wayland connection experienced a fatal error: Invalid argument
KDE Plasma 5.27.8 Distro: Arch Linux Kernel: 6.5.7-zen
That's pretty strange. May I ask what version of libwayland-client.so you have installed? On arch that would be from the "wayland" package, I believe.
https://github.com/NVIDIA/egl-wayland/assets/62414119/e978cb4f-b25b-4309-8574-e08184fd3c17
Same issue Here's a recording of what is happening with vkcube-wayland for me.
Thanks for your report! Do you see the same issue if you run vkcube-wayland with the mailbox presentation mode? You could use --present_mode parameter to switch presentation modes.
That's pretty strange. May I ask what version of libwayland-client.so you have installed? On arch that would be from the "wayland" package, I believe.
wayland package is at version 1.22.0-1
Thanks for your report! Do you see the same issue if you run vkcube-wayland with the mailbox presentation mode? You could use --present_mode parameter to switch presentation modes.
vkcube-wayland --present_mode 1 has the same result. 1 is for VK_PRESENT_MODE_MAILBOX_KHR.
Edit: It's the same for OpenGL apps on wayland as well. 0ad is also hanging in the same way when started with these flags:
SDL_VIDEODRIVER=wayland prime-run 0ad
I have nvidia_drm.modeset=1 in my bootargs. Is there any change needed here @erik-kz ?
I have nvidia_drm.modeset=1 in my bootargs. Is there any change needed here @erik-kz ?
To be completely sure modesetting is enabled, could you run "cat /sys/module/nvidia_drm/parameters/modeset" and confirm that it prints "Y"?
Yes. Modesetting is enabled.
Edit: I also enabled fbdev seeing a post on the nvidia linux forum, and now the vkcube animation is working, but the window is still unresonsive.
On Wed, 18 Oct, 2023, 21:45 Erik Kurzinger, @.***> wrote:
I have nvidia_drm.modeset=1 in my bootargs. Is there any change needed here @erik-kz https://github.com/erik-kz ?
To be completely sure modesetting is enabled, could you run "cat /sys/module/nvidia_drm/parameters/modeset" and confirm that it prints "Y"?
— Reply to this email directly, view it on GitHub https://github.com/NVIDIA/egl-wayland/issues/72#issuecomment-1768878547, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOOCZZHLMWDOCYJNIXSOOTX776CXAVCNFSM6AAAAAARWIM3T6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRYHA3TQNJUG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Tried beta 545.23.06 with Sway on NixOS 23.11.20231016.ca012a0 (latest nixos-unstable), Intel + Nvidia laptop, now regular vkcube is also broken :moyai: Also tried mutter, same problem there. Tried enabling fbdev, changing wlroots env flags, etc.
Driver doesn't even start by default for some reason unless I run nvidia-smi as root.
› lsmod | rg nvidia
nvidia_drm 118784 0
nvidia_uvm 1748992 0
nvidia_modeset 1581056 1 nvidia_drm
drm_kms_helper 253952 3 drm_display_helper,nvidia_drm,i915
video 73728 2 i915,nvidia_modeset
nvidia 62369792 2 nvidia_uvm,nvidia_modeset
drm 741376 16 drm_kms_helper,drm_display_helper,nvidia,drm_buddy,nvidia_drm,i915,ttm
backlight 28672 5 video,drm_display_helper,i915,drm,nvidia_modeset
firmware_class 53248 16 r8169,btrtl,snd_hda_intel,xhci_pci_renesas,btmtk,snd_sof,drm_display_helper,nvidia,btintel,rtw88_core,btbcm,btusb,snd_soc_skl,i915,cfg80211,drm
› nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
› sudo nvidia-smi
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Kanashimia (kanashimia)
Password:
==== AUTHENTICATION COMPLETE ====
Thu Oct 19 12:17:12 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.06 Driver Version: 545.23.06 CUDA Version: 12.3 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA GeForce GTX 1050 Ti Off | 00000000:01:00.0 Off | N/A |
| N/A 49C P8 N/A / ERR! | 2MiB / 4096MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
› vkcube
Selected GPU 1: NVIDIA GeForce GTX 1050 Ti, type: DiscreteGpu
Can't find our preferred formats... Falling back to first exposed format. Rendering may be incorrect.
zsh: segmentation fault (core dumped) vkcube
› vkcube-wayland
Selected GPU 1: NVIDIA GeForce GTX 1050 Ti, type: DiscreteGpu
Can't find our preferred formats... Falling back to first exposed format. Rendering may be incorrect.
zsh: segmentation fault (core dumped) vkcube-wayland
› dmesg
[ 404.718431] vkcube[9717]: segfault at 148 ip 00007fec40321eb3 sp 00007ffd468fd268 error 4 in libnvidia-glcore.so.545.23.06[7fec3f600000+1c93000] likely on CPU 7 (core 3, socket 0)
[ 404.718440] Code: 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 4c 8d 56 b0 48 85 f6 b8 00 00 00 00 49 89 d3 4c 0f 44 d0 <45> 8b 8a 48 01 00 00 48 85 c9 74 61 44 39 0a 44 0f 46 0a 45 85 c9
[ 408.975712] vkcube-wayland[9754]: segfault at 178 ip 00007f3c30506300 sp 00007ffecaf35240 error 4 in libnvidia-glcore.so.545.23.06[7f3c2f800000+1c93000] likely on CPU 2 (core 2, socket 0)
[ 408.975723] Code: 00 00 c7 47 14 00 00 00 00 c7 43 10 ff ff ff ff 5b 5d 41 5c c3 0f 1f 44 00 00 55 48 89 fd 53 48 83 ec 08 48 8b 87 e0 03 00 00 <48> 39 b8 78 01 00 00 0f 84 cb 00 00 00 48 8b bd e8 03 00 00 48 85
Problem found:
It seems that udev rules fail to create devices in /dev because grep nvidia-frontend /proc/devices
doesn't find anything.
After replacing $$(grep nvidia-frontend /proc/devices | cut -d \ -f 1
with 195 those problems were solved, driver launches like before.
vkcube-wayland has funny freezing problems, launching 1 cube shows nothing initially because it is a cube with like 0.01 fps, after waiting couple minutes unfocused it continues with ok fps, after waiting some more again similar slideshow occurs. If you launch a second cube at the same time then there are no freezes, both work ok. If you fullscreen - a freeze occurs, which is interesting because I have -Dnoscanout
for sway. If you close the second cube then one that's left freezes immediately.
Even if you launch vkcube-wayland + vkcube regular, they have ok fps, maybe this is something to do with the power management?
Also cubes have extreme frame pacing issues.
Also moving vkgears window in Sway freezes whole compositor for about 300ms, vkgears is from mesa-demos, had to use VK_LOADER_DRIVERS_SELECT='nvidia*'
otherwise it selects intel gpu, this is especially visible while you resize the floating window.
@erik-kz Is there any update about the bug in the beta release?
Neither myself nor Dogukan have been able to reproduce the issue, unfortunately.
Neither myself nor Dogukan have been able to reproduce the issue, unfortunately.
When there is another GPU-intensive thing running in Vulkan via whatever wayland, xwayland, then vkcube-wayland, or whatever native wayland Vulkan app you have running will start to work properly until you exit whatever vulkan app is using the GPU alongside it, then the application becomes unresponsive. Hopefully, something can be found out. It's like the native Wayland Vulkan apps are unable to properly utilize the GPU's power by themselves. They all just show 0% usage unless you, of course, run another Vulkan app alongside the unresponsive one. This is a very strange issue.
Can also verify that same bug occurs on Mutter in addition to Sway and KDE, tested with kernels 6.1 and 6.5. With the following laptop configuration when Intel is the display GPU: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] NVIDIA Corporation GP107M [GeForce GTX 1050 Ti Mobile] (rev a1)
Also suggest trying to fullscreen the app while testing, as at least on sway that will make it freeze even if you have another vkcube-wayland open.
@erik-kz not the right place to ask, but do you know if grep nvidia-frontend /proc/devices
not returning anything is the intended behaviour after 545? That will break current installation method on Arch, Fedora, and some other distros.
@erik-kz I'm unsure if this is related but it seems like it may be. If not I'll create a new issue instead of adding to this one.
The problem I encounter is with wgpu v0.18.0.
For every example if I run __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia WINIT_UNIX_BACKEND=wayland cargo run
the app freezes.
But if I change WINIT_UNIX_BACKEND=x11
it is fine.
This doesn't seem related to winit as all the winit examples run great in wayland.
I will retry with previous nvidia driver. Edit: 535.113.01 works fine.
For everyone having issues with PRIME on R545, we would be glad if you could try disabling RTD3 (as described here https://download.nvidia.com/XFree86/Linux-x86_64/545.23.06/README/dynamicpowermanagement.html), give it another try and share your experience with us.
we would be glad if you could try disabling RTD3
I have this bug on GTX 1050 Ti, there is no RTD3 at all here, it is not supported, so enabling/disabling it does nothing. I still tried disabling it explicitly, results as you would expect in nothing interesting.
Also eglgears_wayland
has a similar bug, it stops animating when you unfocus.
But there launching multiple apps does nothing, and animation works when you are focused by default, so may not be directly related.
Disabling RTD3 had no effect on the wgpu issue I described.
For anyone who can reliably reproduce this issue, would you mind attaching GDB to the application while it's frozen and capturing a backtrace? If you could share that along with the contents of /proc/\<pid>/maps to determine the base address of any nvidia libraries we should be able to decode it internally. That may provide a clue as to what is going wrong.
@erik-kz this is maybe the best I can do:
(gdb) r
Starting program: /home/luke/Projects/wgpu/target/debug/water
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after vfork from child process 16639]
[Detaching after vfork from child process 16643]
[Detaching after vfork from child process 16647]
Missing separate debuginfo for /lib64/libGLX_nvidia.so.0.
The debuginfo package for this file is probably broken.
Missing separate debuginfo for /lib64/libnvidia-glsi.so.545.23.06.
The debuginfo package for this file is probably broken.
Missing separate debuginfo for /lib64/libnvidia-tls.so.545.23.06.
The debuginfo package for this file is probably broken.
Missing separate debuginfo for /lib64/libnvidia-glcore.so.545.23.06.
The debuginfo package for this file is probably broken.
Missing separate debuginfo for /lib64/libnvidia-gpucomp.so.545.23.06.
The debuginfo package for this file is probably broken.
Missing separate debuginfo for /lib64/libnvidia-glvkspirv.so.545.23.06.
The debuginfo package for this file is probably broken.
[New Thread 0x7fffe47ff6c0 (LWP 16648)]
Missing separate debuginfo for /lib64/libEGL_nvidia.so.0.
The debuginfo package for this file is probably broken.
Missing separate debuginfo for /lib64/libnvidia-eglcore.so.545.23.06.
The debuginfo package for this file is probably broken.
Using NVIDIA GeForce RTX 4090 Laptop GPU (Vulkan)
[New Thread 0x7fffe15ff6c0 (LWP 16651)]
[New Thread 0x7fffe0dfe6c0 (LWP 16652)]
[New Thread 0x7fffdbfff6c0 (LWP 16653)]
[New Thread 0x7fffdb7fe6c0 (LWP 16655)]
[New Thread 0x7fffdaffd6c0 (LWP 16657)]
[New Thread 0x7fffd910f6c0 (LWP 16659)]
s
^C
Thread 1 "water" received signal SIGINT, Interrupt.
0x00007ffff7b25b8d in poll () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install dbus-libs-1.14.10-1.fc39.x86_64 egl-gbm-1.1.0-5.fc39.x86_64 egl-wayland-1.1.13-3.fc39.x86_64 elfutils-libelf-0.189-4.fc39.x86_64 expat-2.5.0-3.fc39.x86_64 glibc-2.38-7.fc39.x86_64 libX11-1.8.7-1.fc39.x86_64 libX11-xcb-1.8.7-1.fc39.x86_64 libXau-1.0.11-3.fc39.x86_64 libXext-1.3.5-3.fc39.x86_64 libcap-2.48-7.fc39.x86_64 libdrm-2.4.114-3.fc39.x86_64 libedit-3.1-48.20230828cvs.fc39.x86_64 libffi-3.4.4-4.fc39.x86_64 libgcc-13.2.1-3.fc39.x86_64 libglvnd-1.7.0-1.fc39.x86_64 libglvnd-egl-1.7.0-1.fc39.x86_64 libstdc++-13.2.1-3.fc39.x86_64 libwayland-egl-1.22.0-2.fc39.x86_64 libxcb-1.13.1-12.fc39.x86_64 libxkbcommon-1.5.0-3.fc39.x86_64 libxshmfence-1.3-13.fc39.x86_64 llvm16-libs-16.0.6-5.fc39.x86_64 lz4-libs-1.9.4-4.fc39.x86_64 mesa-libEGL-23.2.1-2.fc39.x86_64 mesa-libgbm-23.2.1-2.fc39.x86_64 mesa-libglapi-23.2.1-2.fc39.x86_64 mesa-vulkan-drivers-23.2.1-2.fc39.x86_64 ncurses-libs-6.4-7.20230520.fc39.x86_64 spirv-tools-libs-2023.2-5.fc39.x86_64 systemd-libs-254.5-2.fc39.x86_64 vulkan-loader-1.3.250.0-2.fc39.x86_64 vulkan-validation-layers-1.3.250.1-2.fc39.x86_64 wayland-devel-1.22.0-2.fc39.x86_64 xz-libs-5.4.4-1.fc39.x86_64 zlib-1.2.13-4.fc39.x86_64
(gdb) bt
#0 0x00007ffff7b25b8d in poll () from /lib64/libc.so.6
#1 0x00007ffff6204ad3 in ?? () from /lib64/libnvidia-glcore.so.545.23.06
#2 0x00007ffff65e6ed9 in ?? () from /lib64/libnvidia-glcore.so.545.23.06
#3 0x00007ffff66006a0 in ?? () from /lib64/libnvidia-glcore.so.545.23.06
#4 0x00007ffff651938e in ?? () from /lib64/libnvidia-glcore.so.545.23.06
#5 0x00007fffe5f43f59 in vulkan_layer_chassis::WaitForFences(VkDevice_T*, unsigned int, VkFence_T* const*, unsigned int, unsigned long) () from /lib64/libVkLayer_khronos_validation.so
#6 0x0000555556480224 in ash::device::Device::wait_for_fences (self=0x5555580afa20, fences=..., wait_all=true, timeout=18446744073709551615)
at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ash-0.37.3+1.3.251/src/device.rs:2399
#7 0x0000555556441f86 in wgpu_hal::vulkan::instance::{impl#5}::acquire_texture (self=0x555557ea0b60, timeout=...) at wgpu-hal/src/vulkan/instance.rs:911
#8 0x00005555562455c8 in wgpu_core::global::Global<wgpu_core::identity::IdentityManagerFactory>::surface_get_current_texture<wgpu_core::identity::IdentityManagerFactory, wgpu_hal::vulkan::Api> (self=0x555557e0ff40,
surface_id=..., texture_id_in=()) at wgpu-core/src/present.rs:162
#9 0x000055555607119b in wgpu::backend::direct::{impl#7}::surface_get_current_texture (self=0x555557e0ff40, surface=0x7fffffff9498, surface_data=0x555557e630c0) at wgpu/src/backend/direct.rs:799
#10 0x0000555556138e28 in wgpu::context::{impl#5}::surface_get_current_texture<wgpu::backend::direct::Context> (self=0x555557e0ff40, surface=0x7fffffffc798, surface_data=...) at wgpu/src/context.rs:2212
#11 0x0000555555efa661 in wgpu::Surface::get_current_texture (self=0x7fffffffc738) at wgpu/src/lib.rs:4948
#12 0x000055555572856a in wgpu_example::framework::start::{closure#0}<water::Example> (event=..., control_flow=0x7fffffffa628) at examples/common/src/framework.rs:367
#13 0x0000555555716cf1 in winit::platform_impl::platform::sticky_exit_callback<(), wgpu_example::framework::start::{closure_env#0}<water::Example>> (evt=..., target=0x7fffffffb700, control_flow=0x7fffffffa628,
callback=0x7fffffffc680) at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.28.7/src/platform_impl/linux/mod.rs:884
#14 0x00005555556eae4b in winit::platform_impl::platform::wayland::event_loop::EventLoop<()>::run_return<(), wgpu_example::framework::start::{closure_env#0}<water::Example>> (self=0x7fffffffb700, callback=...)
at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.28.7/src/platform_impl/linux/wayland/event_loop/mod.rs:549
#15 0x00005555556ebf6d in winit::platform_impl::platform::wayland::event_loop::EventLoop<()>::run<(), wgpu_example::framework::start::{closure_env#0}<water::Example>> (self=...,
callback=<error reading variable: Cannot access memory at address 0x61>) at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.28.7/src/platform_impl/linux/wayland/event_loop/mod.rs:223
#16 0x0000555555716b78 in winit::platform_impl::platform::EventLoop<()>::run<(), wgpu_example::framework::start::{closure_env#0}<water::Example>> (self=..., callback=...)
at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.28.7/src/platform_impl/linux/mod.rs:792
#17 0x0000555555708997 in winit::event_loop::EventLoop<()>::run<(), wgpu_example::framework::start::{closure_env#0}<water::Example>> (self=..., event_handler=...)
at /home/luke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.28.7/src/event_loop.rs:305
#18 0x00005555557280a2 in wgpu_example::framework::start<water::Example> () at examples/common/src/framework.rs:293
#19 0x0000555555725fe0 in wgpu_example::framework::run<water::Example> (title=...) at examples/common/src/framework.rs:446
#20 0x000055555571cef2 in water::main () at examples/water/src/main.rs:824
(gdb)
I had to ctrl-c to get any kind of backtrace, the app just doesn't progress past the initial draw
And a trace.txt from wgpu.
The map maps.txt
@erik-kz following is my vkcube-wayland stacktrace:
0x00007fdc0d3a4f6f in poll () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007fdc0d3a4f6f in poll () from /usr/lib/libc.so.6
#1 0x00007fdc0d48db5e in wl_display_dispatch_queue () from /usr/lib/libwayland-client.so.0
#2 0x00007fdc09b0aa37 in ?? () from /usr/lib/libnvidia-glcore.so.545.23.06
#3 0x00007fdc09c44473 in ?? () from /usr/lib/libnvidia-glcore.so.545.23.06
#4 0x00007fdc0af73c60 in ?? () from /usr/lib/libGLX_nvidia.so.0
#5 0x000055ad23baf666 in ?? ()
#6 0x00007fdc0d2c9cd0 in ?? () from /usr/lib/libc.so.6
#7 0x00007fdc0d2c9d8a in __libc_start_main () from /usr/lib/libc.so.6
#8 0x000055ad23bb07d5 in ?? ()
and following is the output of maps:
Newly released stable driver doesn't solve above mentioned beta driver issues, as you would expect.
Hello,
This is sort of a continuation of #41 but for Vulkan apps/games
So Vulkan apps (like PPSSPP or vkcube) fail to work with Wayland on my PRIME setup:
As you can see it's identical to the OpenGL error (but the OpenGL one has already been fixed) but I also checked the Wayland logs and the (probably) NVIDIA modifier is present (so the linear modifier needs to be used somehow)
Running both PPSSPP and vkcube with XWayland removes the problem (by using
SDL_VIDEODRIVER=x11
variable or the X11 vkcube executable)And now time for the all important system info 🐸 (although it's kinda redundant here): Distro: Arch Linux egl-wayland version: 1.1.11 (Git version also fails) Mesa version: 22.2.1 Driver version: 515.76 Kernel version: 6.0.6 Compositor: mutter 43.0 (through an unofficial repo) CPU: Ryzen 5 4600H GPU: Renoir iGPU + GTX 1650 Ti Mobile (as I said a PRIME setup)