Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support DX12 in WSL #1443

Open
slymon99 opened this issue Apr 22, 2021 · 11 comments
Open

Support DX12 in WSL #1443

slymon99 opened this issue Apr 22, 2021 · 11 comments
Labels
help required We need community help to make this happen. type: enhancement New feature or request

Comments

@slymon99
Copy link

Microsoft recently released WSLG support for GUI linux applications on windows subsystem for linux. I've enabled all the steps for WSLG and am able to successfully run applications using it (VLC for example) but run into errors when trying to run wgpu examples.

$ cargo run --example cube
[2021-04-22T18:52:22Z ERROR smithay_client_toolkit::window::concept_frame] No font could be found
[2021-04-22T18:52:22Z ERROR gfx_backend_vulkan]
    GENERAL [Loader Message (0x0)] : setupLoaderTermPhysDevs:  Failed to detect any valid GPUs in the current config
    object info: (type: INSTANCE, hndl: 0x563df2c1bfd0)

[2021-04-22T18:52:22Z ERROR gfx_backend_vulkan]
    GENERAL [Loader Message (0x0)] : setupLoaderTrampPhysDevs:  Failed during dispatch call of 'vkEnumeratePhysicalDevices' to lower layers or loader to get count.
    object info: (type: INSTANCE, hndl: 0x563df2c1bfd0)

[2021-04-22T18:52:22Z ERROR gfx_backend_vulkan] Could not enumerate physical devices! Initialization of a object has failed
thread 'main' panicked at 'No suitable GPU adapters found on the system!', examples/cube/../framework.rs:143:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Segmentation fault

I'm currently trying to figure out how to make this work myself and would love any pointers as I'm new to this area. WSLG works through a fairly complex set of abstractions, so I'm not exactly sure where to start. However, it seems like this might not require a huge amount of effort if we can use those abstractions, as WSLG is intended to support linux applications out of the box.

@kvark
Copy link
Member

kvark commented Apr 22, 2021

I don't think you can get any Vulkan under WSLG. It only supports OpenGL.

@slymon99
Copy link
Author

Ah, if I export WGPU_BACKEND=gl I get

[2021-04-22T19:12:58Z ERROR smithay_client_toolkit::window::concept_frame] No font could be found
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DlSym { desc: "/lib/x86_64-linux-gnu/libX11.so: undefined symbol: wl_egl_window_create" }', /home/sclark/.cargo/git/checkouts/gfx-e86e7f3ebdbc4218/6999171/src/backend/gl/src/window/egl.rs:403:22

which seems more fixable?

looking into the line that errors

let wl_egl_window_create: libloading::Symbol<WlEglWindowCreateFun> = self
    .wsi_library
    .as_ref()
    .expect("unsupported window")
    .get(b"wl_egl_window_create")
    .unwrap();

It looks like libloading can't find the wayland egl? I tried installing libwayland-egl-backend-dev but this did not fix it. Again, just looking for pointers for areas to keep looking as this is a new area for me, let me know if you need more information

@kvark
Copy link
Member

kvark commented Apr 22, 2021

Would be good to first see if other EGL-based apps work. Could be that WSLG is only for desktop GL?

@slymon99
Copy link
Author

Also looking into the top level origination of this error comes from smithay_client_toolkit::window::concept_frame, which was replaced recently and "Dependency on andrew and fontconfig is dropped in the process." I'm going to try to see if upgrading smithay client toolkit might fix this error

@slymon99
Copy link
Author

Would be good to first see if other EGL-based apps work. Could be that WSLG is only for desktop GL?

The WSLG docs say "enable support for running Linux GUI applications (X11 and Wayland)", and the list of applications has some fairly sophisticated examples (browsers) that I believe use EGL? Chrome uses angle for example

  • xcalc, xclock, xeyes
  • gimp
  • gedit ~/.bashrc
  • nautilus
  • vlc
  • google-chrome
  • teams
  • microsoft-edge

@kvark
Copy link
Member

kvark commented Apr 22, 2021

Ok, in this case we need to find out why they are able to locate libEGL but we aren't.

@niklaskorz
Copy link
Contributor

niklaskorz commented May 2, 2021

So this is the edgiest of edge cases, but WSL also supports DX12 (Direct3D 12) through libd3d12.so.

https://devblogs.microsoft.com/directx/directx-heart-linux/

This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target. It offers the same level of functionality and performance (minus virtualization overhead). The only exception is Present(). There is currently no presentation integration with WSL as WSL is a console only experience today. The D3D12 API can be used for offscreen rendering and compute, but there is no swapchain support to copy pixels directly to the screen (yet 😊).

If use of compute shaders through wgpu-rs for acceleration of Rust programs and libraries becomes more widespread (e.g., for machine learning?), I could imagine this to be pretty useful.

@kvark
Copy link
Member

kvark commented May 4, 2021

ah, so you are asking about D3D12 support on Linux, I see.

@cwfitzgerald cwfitzgerald changed the title Add support for WSLG DX12 for WSL Jun 3, 2021
@cwfitzgerald cwfitzgerald changed the title DX12 for WSL Support DX12 in WSL Jun 3, 2021
@cwfitzgerald cwfitzgerald transferred this issue from gfx-rs/wgpu-rs Jun 3, 2021
@cwfitzgerald cwfitzgerald added type: enhancement New feature or request help required We need community help to make this happen. labels Jun 3, 2021
@Dispersia
Copy link
Contributor

Dispersia commented Nov 15, 2021

works

got the d3d12/gl extensions to work (mostly).

Things that I had to change to get it to work:

  1. Update winit to master, smithay toolkit updated that's required to fix the wayland client
  2. under wgpu-hal/src/gles/egl.rs, the test_wayland_display looks for "libwayland-client.so", and "libwayland-egl.so", however I only have these: "libwayland-client.so.0", and "libwayland-egl.so.1" and just changing it to that worked. (whatever installed libwayland didn't create symlinks, i guess?)
  3. Apparently the mesa drivers that ship with any OS is super old, so you need to install kisak-mesa (or any other bleeding edge version of mesa) to get working extensions.

Otherwise, most things seem to run fine besides winit/wayland-client issues, and storage buffers for some reason aren't allowed (not currently implemented in the opengl implementation?), I get limit 'max_storage_buffer_binding_size' value 134217728 is better than allowed 0 but haven't looked more into that one yet, might be a me issue, but this seems to get it all working

@Dispersia
Copy link
Contributor

Dispersia commented Nov 20, 2021

a little more digging:

  1. apparently linux at some point auto creates a symlink of versioned shared objects, or that's what it looks like because the original libwayland-client.so now exists for me, but I didn't create it.
  2. kisak-mesa doesn't support opengl es 3.1, only 3.0, so things like storage/compute shaders don't work, unfortunately. HOWEVER, kisak-mesa 21.1 introduced lavapipe, which is a vulkan 1.1 software implementation. It says it's not conformant, and it's definitely a bit slower... but it all works, and it's pretty amazing. Just pass LIBGL_ALWAYS_SOFTWARE with WSLg and everything seems to run fine, and the development experience is bareable, at least to me.

So ya, either use directx -> opengl es 3.0, or vulkan 1.1 software. That seems to be the two current options.

boids

@parasyte
Copy link
Contributor

2. under wgpu-hal/src/gles/egl.rs, the test_wayland_display looks for "libwayland-client.so", and "libwayland-egl.so", however I only have these: "libwayland-client.so.0", and "libwayland-egl.so.1" and just changing it to that worked. (whatever installed libwayland didn't create symlinks, i guess?)

That was fixed in #2336 👍

Patryk27 pushed a commit to Patryk27/wgpu that referenced this issue Nov 23, 2022
WGSL says:

> - The last member of the structure type defining the store type for a variable
>   ... may be a runtime-sized array.
>
> - A runtime-sized array must not be used as the store type or contained within
>   a store type in any other cases.

Thus, a struct whose final member is a struct whose final member is a
runtime-sized array is verboten.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help required We need community help to make this happen. type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants