Free user space for non-graphics drivers

The main use-case is to run the nvidia blob for CUDA and that stuff. And to run that they dig a direct path from the windows kernel gpu driver to linux, but the code that runs in linux isn't a linux driver at all, it's a windows driver. Simply recompiled so it's an ELF .so instead of PE .dll.

Even the mesa gl driver that could run on top of this is the brand new windows gl mesa driver that runs on top of directx. So really this is all about running the windows graphics stack, in linux, on top of windows. It'll never run on bare metal, and it won't look like a linux graphics stack. Hence why the wayland compositor is completely custom, and will use RDP to shovel the buffers over the wire to windows. Essentially microsoft is working on a wayland compositor for windows, using the windows directX stack and windows paravirt RDP desktop integration stuff, but then accidentally run that on linux. But still a windows graphics stack (just now also with wayland protocol support) end to end.

Whether drivers/hyperv wants that or not in upstream is entirely different question.

Using DRM sounds like a lot of extra work for little benefit. The user-mode components which are being ported from Windows-only to cross-platform would have to support both DRM and D3DKMT kernel APIs, which I guess will have a lot of subtle differences and probably some major differences as they evolve and new GPU features are supported in one but not the other; then the Windows side would need to translate DRM back into D3DKMT. By using D3DKMT throughout, it's a simpler and much less bug-prone task of just proxying commands between the two kernels and recompiling the existing user-mode components for Linux with minimal API changes.

One of the major use cases seems to be CUDA (e.g. for developing and testing CUDA applications on Windows with WSL, before deploying to a Linux cloud), which is only supported on Linux by the proprietary NVIDIA drivers, so Mesa is irrelevant there. For 3D graphics, I assume there's normally some tight integration between user-mode and kernel-mode drivers, and the real kernel-mode driver (in the Windows kernel) is going to be the proprietary NVIDIA/AMD/Intel one, so you'll need the matching proprietary user-mode driver on Linux - you wouldn't be able to use Nouveau with it even if they all supported DRM.

D3D12 support on WSL doesn't sound directly useful for applications, because WSL seems like a development platform rather than a deployment platform, so games on Windows will use the native D3D12 API and games on native Linux can't use D3D12 at all (or at least Microsoft hasn't announced any plans for that yet). But D3D12 support means Microsoft can port their OpenGL-to-D3D12 translation layer (https://devblogs.microsoft.com/directx/in-the-works-openc...) from Windows to Linux with little extra effort, meaning OpenGL-based applications can be developed on WSL then deployed on Linux. (Apparently that translation layer does use the higher-level parts of Mesa, with a driver that talks to libd3d12 instead of libdrm.)

> That way the linux guest could use existing Mesa userspace drivers
That's not how DRM works. DRM basically is a "dumb pipe" for commands from userspace to the end device. So you still need a Mesa driver for that device.