Free user space for non-graphics drivers [LWN.net]

Free user space for non-graphics drivers

Posted Jun 5, 2020 7:28 UTC (Fri) by mfuzzey (subscriber, #57966)
In reply to: Free user space for non-graphics drivers by tzafrir
Parent article: Free user space for non-graphics drivers

Sure but in that case why implement /dev/drx at all?

Microsoft could, if the aim were GPU support in Linux guests running on a Windows host (though apparently it's not about that but just compute for the moment) implement a real Linux DRM kernel driver that talks to the Windows host kernel instead of hardware directly.

That way the linux guest could use existing Mesa userspace drivers

to post comments

Free user space for non-graphics drivers

Posted Jun 5, 2020 13:39 UTC (Fri) by blackwood (guest, #44174) [Link]

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.

Free user space for non-graphics drivers

Posted Jun 5, 2020 14:31 UTC (Fri) by excors (subscriber, #95769) [Link] (2 responses)

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.)

Free user space for non-graphics drivers

Posted Jun 11, 2020 16:58 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

> 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

The initial motivation for WSL appears to be just to turn Windows into a viable development platform (very successfully IMO), but I rather suspect that this specific feature is intended primarily for running real production workloads in Docker Linux containers on the same servers that are running Docker Windows containers, and with minimal (plausibly really could be negligible) performance impact.

I'm not certain what applications people are running in Docker Windows containers, or why you would actually want to do that, but it's definitely a thing so clearly there are some use cases out there.

Free user space for non-graphics drivers

Posted Jun 11, 2020 18:15 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> I'm not certain what applications people are running in Docker Windows containers

CI processes :) . It's really nice to have a known-clean state to start from for CI. Without the unbearable slowdown/latency VMs tend to have.

Free user space for non-graphics drivers

Posted Jun 5, 2020 19:43 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> 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.