3 ms·

I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The blog post and the thread on the kernel mailing list seem quite cl

I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. From the email introducing the set of patches: > The projection is accomplished by exposing the WDDM (Windows Display Driver Model) interface as a set of IOCTL. This allows APIs and user mode driver written against the WDDM GPU abstraction on Windows to be ported to run within a Linux environment. This enables the port of the D3D12 and DirectML APIs as well as their associated user mode driver to Linux.

monocasa 6y ago
> I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The fact that they went through the effort of porting Mesa to get OpenGL and Open CL support, and are working on Vulkan support.
- codys 6y ago
  The standard for Linux gpu access is the dri/drm kernel interface, not the new wsl specific api they've added. Their porting Mesa to use a proprietary library that interacts with the wsl only kernel interface isn't that same as behaving like a standard Linux gpu
  - monocasa 6y ago
    It's not really a standard though, each GPU has a totally different set of ioctls and device files to the point that you can't write against a generic kernel interface either way. AFAIK, the only DRI/DRM interface with two used clients is amdgpu (of which one of the clients is proprietary). And part of the discussion on the mailing list is how to integrate this with DRI/DRM and dma-buf so it can be used by more Linux clients with less work (although still non zero like you'd have on a DRI scheme as well).
zamalek 6y ago
> The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. Are we reading the same blog post?[1] [1]: https://devblogs.microsoft.com/directx/wp-content/uploads/sites/42/2020/05/word-image-10.png https://devblogs.microsoft.com/directx/wp-content/uploads/si...

monocasa 6y ago

> I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The fact that they went through the effort of porting Mesa to get OpenGL and Open CL support, and are working on Vulkan support.

codys 6y ago
The standard for Linux gpu access is the dri/drm kernel interface, not the new wsl specific api they've added. Their porting Mesa to use a proprietary library that interacts with the wsl only kernel interface isn't that same as behaving like a standard Linux gpu
- monocasa 6y ago
  It's not really a standard though, each GPU has a totally different set of ioctls and device files to the point that you can't write against a generic kernel interface either way. AFAIK, the only DRI/DRM interface with two used clients is amdgpu (of which one of the clients is proprietary). And part of the discussion on the mailing list is how to integrate this with DRI/DRM and dma-buf so it can be used by more Linux clients with less work (although still non zero like you'd have on a DRI scheme as well).

zamalek 6y ago

> The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. Are we reading the same blog post?[1] [1]: https://devblogs.microsoft.com/directx/wp-content/uploads/sites/42/2020/05/word-image-10.png https://devblogs.microsoft.com/directx/wp-content/uploads/si...