> Non-WSL Linux systems are the majority. They are in your pocket, in your car, your TV, in space, on Mars. Microsoft will never be a player here but is still invited to the bazaar if they wish to participate.
I agree this isn't what they are targeting, at the moment based on the design this doesn't appear to be a play for the embedded Linux market, it's a play for controlling the server/desktop markets(at least the segments of those markets that would potentially use the WSL only Linux userspace API).
> And yes, I agree with Microsoft on this: all apps that people care about their 3D performance should move to DX12 or Vulkan. Microsoft in-house works on supporting DX9/10/11 and OpenGL purely as a legacy API, and eventually, Windows won't allow drivers to implement them anymore, and it will be some shim. I'm not going to shame Microsoft for promoting DX12 over Vulkan; they're both largely the same API, driven entirely by AMD and Nvidia development teams to reflect the current state of hardware, not the whims of some bald CEO that threw chairs at people.
The issue is that they are effectively bringing a WSL only userspace to Linux(https://devblogs.microsoft.com/directx/directx-heart-linux/) and are pushing for developers to target that WSL only userspace. Specifically they provide Linux native libraries like libd3d12.so and libdirectml.so which have a hard requirement on WSL.
> Could the shim be just DXVK-based? Sure. Could the shim be DX9/10/11 state trackers being added to Mesa, and then the Mesa-on-DX12-on-Windows method used? Also sure. Intel is already using DXVK as a legacy shim in their new Arc drivers, and its performing quite well. DXVK also outperforms Nvidia's DX9/10/11 emulation in some games. I could easily see a DXVK-based solution just ship with a future Windows.
The Mesa work seems to be effectively used for the "Embrace" part of the EEE strategy, it ensures that any existing Linux only software runs well under WSL, it's not really the main worry IMO.
The WSL only userspace(ie Linux applications targeting libd3d12.so and libdirectml.so) is the "Extend" part(extends the Linux userspace with WSL only userspace functionality).
Encouraging developers to drop support for non-WSL only API's/libraries on Linux is the "Extinguish" part.
So the main issue is that critical libraries like libd3d12.so and libdirectml.so have been designed to be WSL only. If this wasn't an EEE strategy I would expect that there would be some path to eventually use libd3d12.so and libdirectml.so without WSL, but that isn't possible and there appears to not be any plans to make it possible.
> 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.
> libd3d12.so and libdxcore.so are closed source, pre-compiled user mode binaries that ship as part of Windows.
> D3D12 wouldn’t be able to operate without a GPU specific user mode driver (UMD) provided by our GPU manufacturer partners. The UMD is responsible for things like compiling shaders to hardware specific byte code and translating API rendering requests into actual GPU instructions in command buffers to be executed by the GPU. Working closely with our partners, they have recompiled their D3D12 UMD to a Linux target, enabling execution of these drivers in a WSL environment. This support is being integrated in upcoming WDDMv2.9 drivers such that GPU support in WSL is seamless to the end user. WDDMv2.9 drivers will carry a version of the DX12 UMD compiled for Linux.