wslg
wslg copied to clipboard
microsoft
Add support for Vulkan
Is your feature request related to a problem? Please describe. Currently, trying to run any app leveraging Vulkan seems to end up with a Segfault
Unity with an HDRP (Vulkan dependant) project:
vulkaninfo:
Describe the solution you'd like Having Vulkan work out of the box just like OpenGL
I hope it will be Vulkan pass-through driver which won't be obstructed by BIOS limitations or at least Molten VK but hopefully it won't be an emulation.
Vulkan, Wayland and Pipewire for a modern desktop experience!
I get the segfault even when (I think?) I've requested the lavapipe software renderer, so I suspect this is at least partly a regular bug rather than an unimplemented feature:
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json vulkaninfo
The actual fault is in libVkLayer_MESA_device_select.so:
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: invalid address (fault address: 0x18)
* frame #0: 0x00007ffff7e49d75 libwayland-client.so.0`wl_proxy_destroy + 21
frame #1: 0x00007ffff16a6b37 libVkLayer_MESA_device_select.so`___lldb_unnamed_symbol23$$libVkLayer_MESA_device_select.so + 247
frame #2: 0x00007ffff16a5ff4 libVkLayer_MESA_device_select.so`___lldb_unnamed_symbol11$$libVkLayer_MESA_device_select.so + 1252
frame #3: 0x00007ffff7e18bdb libvulkan.so.1`___lldb_unnamed_symbol296$$libvulkan.so.1 + 107
frame #4: 0x00007ffff7e1b849 libvulkan.so.1`vkEnumeratePhysicalDevices + 73
frame #5: 0x00005555555a7c45 vulkaninfo`___lldb_unnamed_symbol447$$vulkaninfo + 85
frame #6: 0x0000555555562a6a vulkaninfo`___lldb_unnamed_symbol175$$vulkaninfo + 330
frame #7: 0x00007ffff7a240b3 libc.so.6`__libc_start_main + 243
frame #8: 0x00005555555641ee vulkaninfo`___lldb_unnamed_symbol177$$vulkaninfo + 46
It looks like I can disable this with NODEVICE_SELECT=1, but that leads to a different error:
NODEVICE_SELECT=1 VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json vulkani
nfo
/build/vulkan-tools-KEbD_A/vulkan-tools-1.2.131.1+dfsg1/vulkaninfo/vulkaninfo.h:939: failed with ERROR_SURFACE_LOST_KHR
Zink may be able to provide a partial solution as it's written to take advantage of D3D12 being available in Mesa but is applied to Vulkan. Not sure how to better explain than that. But if you look at the code you'll see it's for Vulkan but it also pulls in and uses code from the D3D12 implementation of Mesa. It also appears that MS is involved in developing that Gallium driver too so perhaps the maintainers here can speak better on it. My impression from reviewing it on Mesa's gitlab page is basically to make Vulkan available through the D3D12 driver (the kernel driver, not the mesa gallium to be clear) but I could be mistaken.
@WSLUser Maybe https://github.com/KhronosGroup/Vulkan-Loader/commit/26921924d63bda937feb0d7caf9258dfb2d1d894
Well that's a fairly new development considering Zink is over a year old now. But then it wasn't originally using any functions from D3D12 either. That is definitely a nice and necessary bit to get Vulkan working for us. But that also means we'll need to wait until the next release of Vulkan before that change and other related ones are available. What that might mean for WSLg at that point, who knows. Would be nice if the MS folks would chip in here and explain the situation. They promised us Vulkan support and we're seeing efforts that appear on surface to be doing that but no official communication confirming that.
Vulkan on WSLg is working if the app is using X11. However, vulkan + wayland + WSLg = segfault.
System details:
- Host OS: Windows 11 Build 22621
- WSL Distro: Arch Linux
- CPU: AMD Ryzen 7 3700U
- GPU: AMD Vega 10 picasso (Adrenaline Driver)
- Mesa version: 22.3.6
- Linux version: 5.15.79.1-microsoft-standard-WSL2
When I run this: strace -o vulkan-dozen-wayland.log vkcube-wayland
It produces vulkan-dozen-wayland.log.
I was seeing a similar problem. I had a RTX 3070 and it was not detected by Vulkan. It showed only one GPU which was llvmpipe (LLVM 15.0.7, 256 bits) when running vulkaninfo.
I am able to fix it based on this post https://forums.developer.nvidia.com/t/enabling-nvidia-support-for-vulkan-on-ubuntu-22-04-through-wsl2/244176/3
I add kisak-mesa ppa and upgrade the mesa drivers to the latest version.
sudo add-apt-repository ppa:kisak/kisak-mesa
sudo apt update
sudo apt upgrade
Then, the Nvidia GPU is detected by vulkan.
You can also try it with vkcube. It will show which GPU it is using
Selected GPU 0: Microsoft Direct3D12 (NVIDIA GeForce RTX 3070), type: 2
With that, I guess Vulkan is sort of supported in WSLg.
With that, I guess Vulkan is sort of supported in WSLg.
Any idea if it is possible to get Vulkan working in a docker image running on WSL?
See https://github.com/microsoft/WSL/issues/11303
I'm not able to get Vulkan working in a docker container on WSL2. On WSL2 it recognizes my GPU (and CPU) but within the docker container it only recognizes the CPU. Anyone else stumbling upon this problem?
@selmiskr If it works in WSL2 but not in the docker container take a look at the required environment variables for "Containerized applications access to the vGPU".
@daweifeng
What version WSL is needed for Vulkan to work.
Is there a latest update article on this?
Why is my Vulkan Instance Version on WSL2 different than on Windows
vs
I installed the newest mesa drivers for vulkan on WSL2 and my device is recognized correctly, but it seems to use an old version of Vulkan on WSL2
This is using Ubuntu 20.04. Using Ubuntu 22.04 the version comes closer to the instance version of Windows:
sudo add-apt-repository ppa:kisak/kisak-mesa
sudo apt update
sudo apt upgrade
Ubuntu 22.04
vkcube
Godot4.3 dev5
demo Spectrum with sound working properly