Hi! Is anyone succesfully using wgpu natively on WSL? I'm running in all kinds of different errors when trying to run some of the examples. For example, for the msaa_line example I get the following:

[2024-07-21T11:45:21Z INFO  wgpu_examples::framework] Initializing wgpu...
[2024-07-21T11:45:23Z ERROR wgpu_hal::gles] GLES: [API/Error] ID 1 : GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_VERTEX_IMAGE_UNIFORMS)
[2024-07-21T11:45:23Z ERROR wgpu_hal::gles] GLES: [API/Error] ID 1 : GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_FRAGMENT_IMAGE_UNIFORMS)
[2024-07-21T11:45:23Z INFO  wgpu_core::instance] Adapter Gl AdapterInfo { name: "D3D12 (Intel(R) UHD Graphics 630)", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "4.1 (Core Profile) Mesa 22.2.5-0ubuntu0.1~22.04.3", backend: Gl }
[2024-07-21T11:45:23Z INFO  wgpu_examples::framework] Using D3D12 (Intel(R) UHD Graphics 630) (Gl)
[2024-07-21T11:45:23Z INFO  wgpu_examples::framework] Entering event loop...
[2024-07-21T11:45:23Z INFO  wgpu_examples::framework] Surface resume PhysicalSize { width: 800, height: 600 }
[2024-07-21T11:45:23Z INFO  wgpu_core::device::resource] Device::maintain: waiting for submission index 0
[2024-07-21T11:45:23Z ERROR wgpu_hal::gles::egl] EGL 'eglMakeCurrent' code 0x3008: eglMakeCurrent
thread 'main' panicked at wgpu-hal/src/gles/egl.rs:296:14:
called `Result::unwrap()` on an `Err` value: BadDisplay

In reply to @jumerckx:matrix.org

Hi! Is anyone succesfully using wgpu natively on WSL? I'm running in all kinds of different errors when trying to run some of the examples. For example, for the msaa_line example I get the following:

[2024-07-21T11:45:21Z INFO  wgpu_examples::framework] Initializing wgpu...
[2024-07-21T11:45:23Z ERROR wgpu_hal::gles] GLES: [API/Error] ID 1 : GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_VERTEX_IMAGE_UNIFORMS)
[2024-07-21T11:45:23Z ERROR wgpu_hal::gles] GLES: [API/Error] ID 1 : GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_FRAGMENT_IMAGE_UNIFORMS)
[2024-07-21T11:45:23Z INFO  wgpu_core::instance] Adapter Gl AdapterInfo { name: "D3D12 (Intel(R) UHD Graphics 630)", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "4.1 (Core Profile) Mesa 22.2.5-0ubuntu0.1~22.04.3", backend: Gl }
[2024-07-21T11:45:23Z INFO  wgpu_examples::framework] Using D3D12 (Intel(R) UHD Graphics 630) (Gl)
[2024-07-21T11:45:23Z INFO  wgpu_examples::framework] Entering event loop...
[2024-07-21T11:45:23Z INFO  wgpu_examples::framework] Surface resume PhysicalSize { width: 800, height: 600 }
[2024-07-21T11:45:23Z INFO  wgpu_core::device::resource] Device::maintain: waiting for submission index 0
[2024-07-21T11:45:23Z ERROR wgpu_hal::gles::egl] EGL 'eglMakeCurrent' code 0x3008: eglMakeCurrent
thread 'main' panicked at wgpu-hal/src/gles/egl.rs:296:14:
called `Result::unwrap()` on an `Err` value: BadDisplay

If I remember correctly, wgpu functionality is limited on GLES backend. By default, WSL2 only supports OpenGL, GLES and software Vulkan (on CPU). You can force wgpu to use Vulkan backend instead of GLES, and it works for me. But in WSL, Vulkan will be slow due to software implementation.

If you want to use hardware Vulkan on WSL, you can try to set up proper support over DX12. It's somewhat complicated and requires building MESA drivers from source, because it's an experimental feature provided by Microsoft. I spent some time doing it months ago, and eventually got it working. If you are interested, here is the link https://gitlab.freedesktop.org/mesa/mesa/-/issues/6318#note_1459269

Some interesting note: it seems like wgpu prefers to use llvmpipe (software Vulkan) to create an adapter even when hardware implementation over DX12 is available (maybe because it's experimental)

In reply to @bromles:matrix.org

If I remember correctly, wgpu functionality is limited on GLES backend. By default, WSL2 only supports OpenGL, GLES and software Vulkan (on CPU). You can force wgpu to use Vulkan backend instead of GLES, and it works for me. But in WSL, Vulkan will be slow due to software implementation.

If you want to use hardware Vulkan on WSL, you can try to set up proper support over DX12. It's somewhat complicated and requires building MESA drivers from source, because it's an experimental feature provided by Microsoft. I spent some time doing it months ago, and eventually got it working. If you are interested, here is the link https://gitlab.freedesktop.org/mesa/mesa/-/issues/6318#note_1459269

Some interesting note: it seems like wgpu prefers to use llvmpipe (software Vulkan) to create an adapter even when hardware implementation over DX12 is available (maybe because it's experimental)

In reply to @jumerckx:matrix.org
Thanks a lot for the information! I use WSL for other development but seems like it's easier to stick to windows for graphics programming for now :)

It's important to know that WSL is very specific and incompatible with real Linux in many ways (not just graphics). It's a custom Microsoft kernel with many missing system libraries. I encountered numerous "surprises" like the inability to compile Redis from source using it, which real Linux just doesn't have.

And the whole multimedia support is very unconventional - your VMs in WSL2 don't have any support for video or audio themselves. There is a separate, hidden VM called WSLg where there is support, and all your VMs are supposed to talk to it in order to use multimedia. The issue is - many applications for Linux don't support it since usually the system itself provides support (i.e. PulseAudio sockets), and you don't need to go into a separate VM just to use it. That's the reason why so many apps there days have separate "Linux" and "WSL" versions, because WSL just don't support common Linux practices and breaks unprepared software

Based on experience with such cases, I decided to use WSL only for it's shell and common commands. Because with everything else, if it breaks, you will never know is it a problem with software, your system, or just one of WSL quirks. And the closer you try to be to OS in WSL, the more it breaks

In reply to @jumerckx:matrix.org
Thanks a lot for the information! I use WSL for other development but seems like it's easier to stick to windows for graphics programming for now :)

It's important to know that WSL is very specific and incompatible with real Linux in many ways (not just graphics). It's a custom Microsoft kernel with many missing system libraries. I encountered numerous "surprises" like the inability to compile Redis from source using it, which real Linux just doesn't have.

And the whole multimedia support is very unconventional - your VMs in WSL2 don't have any support for video or audio themselves. There is a separate, hidden VM called WSLg where there is support, and all your VMs are supposed to talk to it in order to use multimedia. The issue is - many applications for Linux don't support it since usually the system itself provides support (i.e. PulseAudio sockets), and you don't need to go into a separate VM just to use it. That's the reason why so many apps there days have separate "Linux" and "WSL" versions, because WSL just don't support common Linux practices and breaks unprepared software

Based on experience with such cases, I decided to use WSL only for it's shell and common commands. Because with everything else, if it breaks, you will never know is it a problem with software, your system, or just one of WSL quirks. And the closer you try to be to OS in WSL, the more it breaks

upd: I personally think that this is just another example of Microsoft's beloved EEE strategy to destroy their competition, which they tried multiple times already (https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish)

It's important to know that WSL is very specific and incompatible with real Linux in many ways (not just graphics). It's a custom Microsoft kernel with many missing system libraries. I encountered numerous "surprises" like the inability to compile Redis from source using it, which real Linux just doesn't have.

And the whole multimedia support is very unconventional - your VMs in WSL2 don't have any support for video or audio themselves. There is a separate, hidden VM called WSLg where there is support, and all your VMs are supposed to talk to it in order to use multimedia. The issue is - many applications for Linux don't support it since usually the system itself provides support (i.e. PulseAudio sockets), and you don't need to go into a separate VM just to use it. That's the reason why so many apps there days have separate "Linux" and "WSL" versions, because WSL just don't support common Linux practices and breaks unprepared software.

Based on experience with such cases, I decided to use WSL only for it's shell and common commands. Because with everything else, if it breaks, you will never know is it a problem with software, your system, or just one of WSL quirks. And the closer you try to be to OS in WSL, the more it breaks.

Upd: I personally think that this is just another example of Microsoft's beloved EEE strategy to destroy their competition, which they tried multiple times already (https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish)

In reply to @bromles:matrix.org

If I remember correctly, wgpu functionality is limited on GLES backend. By default, WSL2 only supports OpenGL, GLES and software Vulkan (on CPU). You can force wgpu to use Vulkan backend instead of GLES, and it works for me. But in WSL, Vulkan will be slow due to software implementation.

If you want to use hardware Vulkan on WSL, you can try to set up proper support over DX12. It's somewhat complicated and requires building MESA drivers from source, because it's an experimental feature provided by Microsoft. I spent some time doing it months ago, and eventually got it working. If you are interested, here is the link https://gitlab.freedesktop.org/mesa/mesa/-/issues/6318#note_1459269

Some interesting note: it seems like wgpu prefers to use llvmpipe (software Vulkan) to create an adapter even when hardware implementation over DX12 is available (maybe because it's experimental)

In reply to @maxammann:matrix.org
I'm out of the loop of what happened around wgpu in the last year. Were any helpers regarding memory management were released? (Either internally or an external crate)

In reply to @cwfitzgerald:matrix.org
Wym? Are you looking for something in particular?

In reply to @maxammann:matrix.org
Mostly related to memory management, e.g. i implemented a circular buffer before. I'm not that familiar but it seems like there is some helpers/u told/allocators around vulkan

In reply to @leonerdo:matrix.org
Hi, how valid of an approach is it to have only indexes in the vertex buffer and then in the vertex shader access the real data with these indexes from different arrays?