4 ms·

The title is misleading. This isn't DirectX on Linux. This is DirectX API access for WSL exclusively. It will lock ML projects into Windows/WSL for the price o

by badRNG 6y ago

The title is misleading. This isn't DirectX on Linux. This is DirectX API access for WSL exclusively. It will lock ML projects into Windows/WSL for the price of access to the DirectX API and at the expense of development of other projects like Vulkan for native Linux.

monocasa 6y ago
Not anymore so than they're already locked into CUDA. It's more a WDDM bridge than a strict DirectX bridge.
- badRNG 6y ago
  I don't see how being "locked into CUDA" should make one less skeptical of a change that will functionally lock projects into Windows. I can't help but think this is going to siphon resources from Linux native graphics development.
  - monocasa 6y ago
    I don't see how it'll be locking projects into windows. There's no user space DirectX library here. The whole point looks to take your CUDA code that would run just fine on Linux without a hypervisor, and run it just as well in WSL2. ie. this is at worst still the embrace stage, IMO.
    - jfkebwjsbx 6y ago
      They are providing libd3d12.so, that is a user space library that apps can link to. At the moment, that library only works under WSL, but I guess the DXVK folks can connect their implementation too.
      - monocasa 6y ago
        > The plan is for Microsoft to provide shims to allow the existing Linux userspace interact with DX12; I'll explain below why we had to pipe DX12 all the way into the Linux guest, but this is not to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API. https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 And backing that up, they ported Mesa to get OpenGL and OpenCL in the Linux guest and are working on a Vulkan port as well.
dang 6y ago
We've changed from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742 to the blog post it links to, which hopefully makes things clearer.

by badRNG 6y ago

monocasa 6y ago

Not anymore so than they're already locked into CUDA. It's more a WDDM bridge than a strict DirectX bridge.

badRNG 6y ago
I don't see how being "locked into CUDA" should make one less skeptical of a change that will functionally lock projects into Windows. I can't help but think this is going to siphon resources from Linux native graphics development.
- monocasa 6y ago
  I don't see how it'll be locking projects into windows. There's no user space DirectX library here. The whole point looks to take your CUDA code that would run just fine on Linux without a hypervisor, and run it just as well in WSL2. ie. this is at worst still the embrace stage, IMO.
  - jfkebwjsbx 6y ago
    They are providing libd3d12.so, that is a user space library that apps can link to. At the moment, that library only works under WSL, but I guess the DXVK folks can connect their implementation too.
    - monocasa 6y ago
      > The plan is for Microsoft to provide shims to allow the existing Linux userspace interact with DX12; I'll explain below why we had to pipe DX12 all the way into the Linux guest, but this is not to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API. https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 And backing that up, they ported Mesa to get OpenGL and OpenCL in the Linux guest and are working on a Vulkan port as well.

dang 6y ago

We've changed from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742 to the blog post it links to, which hopefully makes things clearer.