Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

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.

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

I think if that really matters you should be against anything in the kernel to make it work well as a VM under Windows or MacOS or BSD, and in VMware or VirtualBox too.

From that point of view, Linux in a VM on another host is taking away from Linux running as a desktop on that host. Linux running as a VM on a VMware cluster is taking away from Linux running on those bare metal servers instead of VMware ESXi.

I think the more sane way to look at it is that Linux is an application (and its subcategory is that it is an OS) which is meant to run on various hardware and software platforms, the more the better. This strategy has worked very well over that last couple decades.

Does allowing WSL mean that some people that would install Linux on their hardware just run Windows instead and use Linux on top? Probably. Does it mean that people that already ran Windows and have never used Linux get exposed to it for the first time and get familiar with it through a few click on their existing Windows computer? That's also probable. Does it really matter in the end? Probably not.

> I think if that really matters you should be against anything in the kernel to make it work well as a VM under Windows or MacOS or BSD, and in VMware or VirtualBox too.

Why? I would guess that a very large share of linux kernels run under a hypervisor in some data center, in a public cloud or some OpenStack cluster. Won't those mostly be the same features?

Because WSL doesn't compete with people who would otherwise run a Linux box, it competes with people who would otherwise shove Ubuntu into a VirtualBox and run it on their Windows box in seamless mode. So the idea that it drives people away from Linux proper is nonsense (BTW., WSL is Linux proper), unless you also believe that installing a Linux in a VM on a proprietary system is also driving people away.

I agree with you completely. I think that the comment I was replying to thinks otherwise.

No, I was just a little more abiguous due to a left out word or two than I intended.

>>> I think if that really matters you should be against

Should be interpreted as (and I meant to write as)

>>> I think if that really matters to you you should be against

The rest of the comment should have made that obvious though, especially the last two paragraphs.

Now I get your intention, the original phrasing made me it parse it incorrectly.

Happy to know that we also agree then.

> ... shove Ubuntu into a VirtualBox and run it on their Windows box in seamless mode

Given that the WSL2 rewrite is essentially this, without even the niceties of a VirtualBox GUI wrapper to control the settings, I keep wondering what all the fuss is about.

>>>There's also the question of whether or not you believe WSL as a whole is good or bad for Linux.

IMO it's a good thing. Given that windows accounts for 90%+ of the desktop OS share, Windows might very well become the world's most used Linux distro.

It is, of course, decidedly not a Linux distro though. If it was, it wouldn't be an issue. I think there are positives, but it looks a lot like "Extend" to me.

I can't even say I wouldn't use it - it might be nice! But I will not use any WSL-only capability, that's for sure.

My understanding is that this is meant to become transparent to the user, that really this is about enablement of hardware acceleration within WSL, and that the typical Linux userland graphics APIs like OpenGL would layer on top. So the goal isn't to get you to link to libdx12 or whatever it is they have here, it's actually a piece that will be used by Mesa to provide accelerated GL for plain old Linux apps to use when running in WSL. It seems like the easiest bite off the apple was offscreen rendering and GPGPU functionality, but the MS devs seem willing to work with the kernel devs to rearch it so it fits into the typical Linux graphics stack ie DRI and other lower level systems. As far as I understand, this would be required for, say, Wayland to be able to have hardware acceleration when running in WSL.

I'm still piecing it all together, and I definitely feel that "Extend" feeling, but I'm not sure that's what's happening here. Looks more like a few devs at MS are trying to solve the GPU Accel use case for WSL...

The DirectML API is not otherwise available on Linux. If it promises cross vendor support (which is a good thing) tools and libraries will use it.

Those tools and libraries will then not work on native Linux.

Hi. Microsoft PM working on WSL, Terminal and Windows.

WSL2 literally runs user-mode distros (and their binaries) in containers atop a shared Linux kernel image (https://github.com/microsoft/WSL2-Linux-Kernel) inside a lightweight VM that can boot an image from cold in < 2s and which aggressively releases resources back to the host when freed.

So when you run a binary/distro on WSL2, you are LITERALLY running on Linux in a VM alongside all your favorite Windows apps and tools.

If some of the tools you run within WSL can take advantage of the machine's available GPUs etc. and integrate well with the Windows desktop & tools, then you benefit. As do the many Windows users who want/need to run Linux apps & tools but cannot dual-boot and/or who can't switch to Linux full-time.

This will (and already has) resulted in MANY Windows users getting access to Linux for the first time, or first time in a while, and are now enjoying the best of both worlds.

The question isn't asking whether you, a Windows user who runs Windows, benefit. The question is asking what it does to Linux users who don't run Windows even a little. (And I think you know that.)

That's like asking whether Linux users who don't run ESXi benefit from their paravirtualized drivers being upstreamed. No, they don't, but they were accepted with way less bruhaha. And that's despite VMWare blatantly violating the GPL for more than a decade.

With DirectX on WSL, you can do new things when Linux is running on Windows (via WSL). But these new things aren't possible when Linux is running another way (e.g. on the bare metal).

So people who use it are married to Windows.

I think folks would be absolutely excited if this was an initiative to allow writing DirectX applications on Linux, and available for Linux on bare metal. But as people realize this marries them to Windows, they go meh.

They're not intending d3d to be the client library, they ported Mesa for OpenGL and OpenCl, and are working on a Vulkan port for all of that.

I think the concern with this DirectX implementation is that it only works for WSL users, not standard Linux users. So, it's a software API that will only work in your ecosystem, not the overall Linux ecosystem.

If DirectX on Linux could also work on bare metal, the conversation here would likely be different.

IMO it's exactly embrace extend extinguish that parent noted that can be spun to kick CUDA out of the game for Linux which is good in short term.

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

And that is, IMHO, a very real concern and it really should not be merged.

Yeah, I think MS should address this point. Airlie also asked if everything here is covered by Open Invention Network (OIN) of which Microsoft is a participant, and indeed I'm pretty sure it all has to be since that is the point of OIN. But the MS devs will now need to have legal sign off that it's all covered by OIN before they can respond in the affirmative. I assume that will take some time as these things usually do. Especially since this seems more like a bottom-up effort than something top-down managed

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.

Yeah not the end of the world if it doesn't land immediately, based on the original devs responding that they'd rather find the right place for it than the expedient place for it

Sure, but that doesn't really stop Microsoft from achieving their goal with WSL2. They would be happy to upstream it if possible if not then oh well.

Why would it? That's a functionality that can't be used without Microsoft proprietary parts. Unless I missed something, I don't think there is an open source implementation of DirectX somewhere?

I doubt the linux devs ever see WLS as a target they have to maintain themselves.

Wine has an open source implementation of DirectX, FWIW.

Ok, not my field, but isn't it based on OpenGL? Does it count as an implementation or an emulation layer? My understanding is that Microsoft is trying to give WSL a transparent access to the GPU using the regular linux interface and transmitting it to DirectX.

Using that with wine would mean adding two emulation layers before reaching the actual driver. I fail to see any use case for that.

It's based on vulkan, which means that it has low enough level access to the GPU that I think it's fair to call libraries implemented on top of it "native". Most GPU drivers have some kind of translation for directx already, and there's no inherent reason why the open source directx implementation has to perform worse than the GPU implementation of directx. I hear that the open source dx11 implementation actually beats AMD's DX11 implementation in some cases.

So yeah, vulkan is neat and opens up a whole lot for the linux world. In the future you'll probably see userspace implementations of opengl on top of vulkan, maybe even CUDA implemented on AMD gpus, although I'm not sure how practical that is. Also a whole lot of exciting GPU sharing tech, accessing GPUs inside of VMs for example.

DirectX will come to linux, but it won't be thanks to microsoft. You can thank valve hedging their bets on the microsoft store for that.

What would be the big loss other than MS bundling a ppa ? Nvidia drivers and cuda anyway need a ppa. So wsl + nvidia + cuda being a single ppa is anyway not that far off.

Reply on news.ycombinator.com