Live data from Hacker News

DirectX is coming to the Windows Subsystem for Linux

devblogs.microsoft.com

91–100 of 548 posts

Re: DirectX is coming to the Windows Subsystem for Linux

#91
post #17

Earlier quoted context omitted.

This patch adds WDDM (Windows Display Driver Model) as a Linux kernel API. The implementation just forwards to the Windows kernel, but it seems to me like someone could implement it natively in Linux. Then Windows user mode graphics drivers would work natively in Linux without WSL, and DX12 too.

someone could implement it natively in Linux This is exactly what we don't want. There's already plenty of effort wasted on GBM vs. EGLStream so introducing a third API would just lower quality even more.

Presumably the NVIDIA Linux driver can be replaced with a shim over this, and we can all forget about EGLStreams.

Re: DirectX is coming to the Windows Subsystem for Linux

#92

Earlier quoted context omitted.

Yup, from one of the MS staff replies further in the thread[1] > There is a single usecase for this: WSL2 developer who wants to run machine learning on his GPU. The developer is working on his laptop, which is running Windows and that laptop has a single GPU that Windows is using. Can't say I can get behind MS trying to shift maintenance for a Windows only "feature" onto the Linux devs here. 1. https://lkml.org/lkml…

Is there a possibility Linux upstream won't accept it?

That's pretty much always a possibility. On the other hand, they're also generally fairly open to add things as long as the developers react to concerns. I'd guess if this can be neatly stuffed in a corner and treated like any of the other Hyper-V specific drivers, and quality is okay, it has a reasonable chance to be accepted.

And if it is rejected, Microsoft can still ship it in the kernels for the distros they offer on WSL.

Re: DirectX is coming to the Windows Subsystem for Linux

#93
post #6

...and extend. I'm sure this architecture was easier for MS but it opens the door to code that runs on WSL2 that doesn't run on regular Linux.

> that doesn't run on regular Linux.

DirectX does run on regular Linux, courtesy of Wine/Proton. It's just a matter of reimplementing the userspace .so interface that MS will provide for access to this facility, so that it hooks into that support instead.

Re: DirectX is coming to the Windows Subsystem for Linux

#94
post #17

Earlier quoted context omitted.

someone could implement it natively in Linux This is exactly what we don't want. There's already plenty of effort wasted on GBM vs. EGLStream so introducing a third API would just lower quality even more.

This "third API" is already well supported by every relevant graphics vendor. Adopting it would actually reduce the number of APIs vendors need to deal with. And the quality of WDDM drivers has always been higher than anything Linux has.

Really? The experience of AMD users has historically tended to be at odds with that statement.

Re: DirectX is coming to the Windows Subsystem for Linux

#95
post #75

Earlier quoted context omitted.

Yes, machine learning is the first priority as they say in the thread. However, the blog post goes on to say that window system integration is coming. This will eventually be a full graphics stack. > Anyway, this isn't really a Linux port of DirectX The entire user mode side of Direct3D is ported, in addition to the user mode parts of the Nvidia, AMD, and Intel graphics drivers.

> This will eventually be a full graphics stack Are we seeing the start of the migration of Windows to linux?

My guess is that MS and Apple are both slowly trying to steer their ship in the same general direction as ChromeOS: a stable, locked down OS that runs applications in dedicated sandboxes/containers/VMs. No longer does the OS need to provide the same "shell" to those applications. You don't need a library-based wrapper to the syscall layer. The paravirtualized hardware is the new syscall layer. You can wrap whatever OS interface you want around that in order to support different kinds of workloads. Games can run as close to the system as possible. Workloads destined for the cloud can run in a Linux environment. Instead of being intermediated by clunky VM kit from third-party vendors, they'll provide a lot of it themselves to optimize performance and ensure adequate security between environments in a user-friendly manner.

By making the virtualized hardware the "glue", they can avoid the GPL/copyleft infection of their commercial OS, while supporting different kinds of developer experiences.

Re: DirectX is coming to the Windows Subsystem for Linux

#96

Earlier quoted context omitted.

Yup, from one of the MS staff replies further in the thread[1] > There is a single usecase for this: WSL2 developer who wants to run machine learning on his GPU. The developer is working on his laptop, which is running Windows and that laptop has a single GPU that Windows is using. Can't say I can get behind MS trying to shift maintenance for a Windows only "feature" onto the Linux devs here. 1. https://lkml.org/lkml…

Is there a possibility Linux upstream won't accept it?

If you read the replies by Dave Airlie and Daniel Vetter, it seems somewhat likely that upstream won't accept it. Perhaps that's just initial skepticism that will evaporate after more discussion, but perhaps not.

Frankly this does just seem like MS wanting to reduce their maintenance burden on what they expect will be a very important part of their WSL offering on Windows. There's nothing inherently wrong with that desire, but the people on the other side need to weigh their maintenance burden[0] with what benefit this will have to the Linux community as a whole, which at first blush seems minimal. Especially considering that the userland pieces that talk to this driver aren't open-source.

There's also the question of whether or not you believe WSL as a whole is good or bad for Linux. If there are people who would run a Linux desktop for development who then decide not to because WSL exists, perhaps that's a bad outcome. If you have people writing more DirectX GPGPU code who would otherwise write to a standard interface like OpenCL, perhaps that's a bad outcome (to be fair, there's also a lot of CUDA out there, which is similarly problematic). Is this the start of MS going back to their "Embrace, Extend, Extinguish" playbook, or is that just a paranoid fear? They've definitely been embracing Linux, and enabling people to write DX12 GPGPU code that targets a Linux environment but will only run under WSL on a Windows install does feel like "extend".

I'm not sure where I personally stand on this issue as I haven't done my research, but I think they're interesting questions to ask.

If this gets rejected, of course it doesn't stop MS from doing any of these things, but it does make it harder for them to maintain their extensions to Linux.

[0] Airlie is even concerned that just by looking at the code, he or other DRI developers could run into future IP derived-works trouble when designing future Linux graphics interfaces.

Re: DirectX is coming to the Windows Subsystem for Linux

#97
If this works, Microsoft will overnight become viable for scientific dev work. Kudos to MS for taking on what is perceived by many as a "fringe" feature, but would allow me to use Windows on a laptop, while having a sane (and compute-rich) Linux dev environment. In all these years, NVIDIA still didn't make it easy to use laptop GPUs from Linux directly. At least not if you want good battery life.

Re: DirectX is coming to the Windows Subsystem for Linux

#98
There is a new, closed-source Microsoft DirectX 12 library for Linux apps that speaks WDDM to /dev/dxg.

There is a pre-existing closed-source NVIDIA Vulkan+OpenGL+CUDA library for Linux apps that speaks EGLStreams to /dev/nvidia0.

There is an announcement that the closed-source NVIDIA library might start speaking WDDM to /dev/dxg.

There is a pre-existing open-source Mesa DirectX 12 (+Vulkan +OpenGL + ...) library for Linux apps that speak GBM to /dev/dri (and some support for speaking EGLStreams to /dev/nvidia0 too).

There is a pull request to implement /dev/dxg in the kernel as a Hyper-V pipe for WSL2's use.

There are lots of interaction points for alternate implementations of various pieces of the stack. For example, in the future it might ultimately be possible for an alternate /dev/dxg implementation to wrap the normal DRM API, or for NVIDIA's binary driver to reimplement /dev/dxg on real hardware.

Re: DirectX is coming to the Windows Subsystem for Linux

#99
post #61
post #6

...and extend. I'm sure this architecture was easier for MS but it opens the door to code that runs on WSL2 that doesn't run on regular Linux.

In the linked thread the Microsoft developers explicitly deny that this is the intent, if that's worth anything to you. The goal, rather, is to take all the usual (for the Linux side) GPU stuff and give it access to the Windows host's GPU, when running on WSL. That is, they are already working on getting OpenGL/Vulkan/etc. to run on top of this: https://www.collabora.com/news-and-blog/news-and-events/intr... Rather t…

The developers' word is irrelevant. Microsoft is a business. Microsoft will pursue its long term business interests. Developers are hired to do what the business directs. So the question is really, "what would best serve Microsoft's business interests?" and not "what do the developers intend?" because in time only one question matters and unfortunately it's not the one with the best interests of non-windows-users in mind.
Post reply on HN