vkPhysicalDeviceSurfaceFormatsKHR reports VK_ERROR_SURFACE_LOST_KHR (dual gpu setup) #96
Comments
|
Thanks for the report. Could you please run vkcube-wayland on the NVIDIA GPU with Another thing that might help is enabling the "kms-modifiers" experimental feature for mutter with a command like |
|
With Enabling "kms-modifiers" does not appear to have any effect. |
|
Whoops, sorry, it looks like it might now also be necessary to set |
|
No change. gnome-terminal shows those environment variables as set Output remains the same from vulkaninfo with Pasting the output here again in case I missed something obvious |
|
Hmm, are you using an older AMD GPU by any chance? I wonder if their driver doesn't support DRM format modifiers for your chip. You could use Simon Ser's drm_info utility to check this. It generates a lot of output, but the relevant pieces for this issue would be Planes -> Plane X -> Properties -> "IN_FORMATS". This should be followed by a list of formats and format modifiers. If there is no such section then that's the problem. The drm_info source code is here https://gitlab.freedesktop.org/emersion/drm_info and there's also an AUR package https://aur.archlinux.org/packages/drm_info |
|
Oh wait, I see that the eglinfo / vulkaninfo output you provided shows you're using an RX 580. Looking online, it sounds like it does not support DRM format modifiers. So for the moment unfortunately render-offload from an NVIDIA GPU to this GPU will not work. We're planning on adding support for implicit modifiers which should eventually offer a solution. This shortcoming has turned out to be the case of a few other issues recently, e.g. obsproject/obs-studio#9895 |
|
Nice spot, thanks @Eric-KZ. Good to understand the issue at play here, very much appreciated. Im also about to take a holiday, so wouldn't have been in a good position to diagnose further for a little while 😀 |
|
Just cross-referencing this as I think it's also related NVIDIA/open-gpu-kernel-modules#440. |
|
@erik-kz is it possible that recent drivers have introduced a regression here? I'm certain I've been succesfully using DRI_PRIME with this configuration as recently as v535.129.03 (see issue #95) and I'm now having issues with DRI_PRIME for OpenGL applications (which also worked previously) silently falling back to mesa swrast/zink.. (see here |
|
PRIME render-offload for Vulkan Wayland applications was not working at all before 545, so I do not think it's possible that this bug is a regression. |
|
Okay, thanks. Please disregard (not sure how I managed to produce #95 ahead of 545) |
It would still have been possible to create a Wayland swapchain on a PRIME system prior to 545, assuming you set __NV_PRIME_RENDER_OFFLOAD=1. Presentation would fail, though, which I believe matches your observations from the other bug. |
|
Ahh, thank you for the clarification. I'm not going crazy :) |
|
@erik-kz I believe this issue is still apparent on the currently available drivers (v550.67) |
|
Ah, sorry. you're right. We still don't support implicit modifiers which is the root cause of this. |
|
Want to add that I am seeing the same issue on my machine. While trying to fix it, I made some small improvements to vulkaninfo output, which should make future debugging of this type of issue easier (the way queues showed present support was dubious to say the least.) So my banging my head against the wall until I found this issue wasn't totally in vain. System info if curious: OS: Ubuntu 24.04.1 LTS |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running an arch linux setup with dual GPU's
Arch Linux
Kernel 6.6.2-arch1-1
GNOME Version 45.1
nVidia Driver version 545.29.6
personal project
When targeting the GTX 970..
vkCreateWaylandSurfaceKHRsuccedsUsing that surface, I can succesfully query the surface capabilities
vkGetPhysicalDeviceSurfaceCapabilitiesKHR(device, surface, &details.capabilities);Though the returned capabilities show slightly excessive values for the currentExtent, all other values appear sane.
I then query for surface formats
vkGetPhysicalDeviceSurfaceFormatsKHR(device, surface, &formatCount, nullptr);which fails with
VK_ERROR_SURFACE_LOST_KHRvkcube-wayland
This behaviour seems to be mirrored by vkcube-wayland, glxgears, vkmark
Curiously, vulkaninfo only reports the following presentable surfaces:
Seems odd that VK_KHR_wayland_surface does not make an appearance (though I don't see it for the amd card either).
Running
vkcube-waylandfor the GTX 970 seg faultsRunning with --validate-checks-disabled
vkgears
vkgears also seg faults, with no way to specifiy GPU.
vkmark
vkmark seg faults when specifying the GTX 970.. Runs fine with the RX 580
vulkaninfo
vulkaninfo --summary
eglinfo -B
inxi
The text was updated successfully, but these errors were encountered: