30 ms·

DirectX is coming to the Windows Subsystem for Linux

706 points by modeless 6y ago

_vbdg 6y ago
> This also enables third party APIs, such as the popular NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment. Dollars to donuts this is why Microsoft is implementing this. GPU acceleration is becoming a critical feature for many users (but especially developers) and this will continue. If WSL is to be a serious competitor, this is necessary and I'm glad to see it showing up. This is true of cloud compute, too, and Microsoft is betting big on cloud as its future growth area. > Only the rendering/compute aspect of the GPU are projected to the virtual machine, no display functionality is exposed. The Linux gaming folks will be pretty sad about this one. Anyway, this isn't really a Linux port of DirectX. This is GPU compute via DirectX APIs. So now, I'm just waiting on monitor mode/AF_PACKET for WSL...
- Mic92 6y ago
  Do ML people actually care about DirectX? I thought everyone is using CUDA? Anyway in my university building I have not seen anyone that does machine learning on Windows.
  - modeless 6y ago
    CUDA is supported as well.
  - raphlinus 6y ago
    Yes, (almost) everybody doing machine learning is on CUDA. There are multiple pieces of this work, and the DirectX API's are only part of it. Other pieces get CUDA running as well. And yet another piece is a layer to get OpenGL and OpenCL workloads running on DX12 as well, rather similar in scope to how MoltenVK and the gfx-hal Vulkan Portability work are a layer to get Vulkan workloads running on Metal. This is a big effort, and it seems to me their goal is to get things to the point where stuff Just Works and you don't have to think too hard about the various bits of (technically difficult!) infrastructure to get you there.
  - cududa 6y ago
    A bit of a tip, your university development experience is not going to be like anything you see in production
  - anaisbetts 6y ago
    They typically don't - the team published both a special build of Tensorflow that uses DirectX, as well as working with nVidia to get CUDA running against their DX Linux kernel implementation
    - lostmsu 6y ago
      > special build of Tensorflow that uses DirectX Huh? Are you sure about that? Regular TensorFlow on Windows uses CUDA, not DirectX-flavored compute.
      - raphlinus 6y ago
        I was also surprised, but found this RFC for TensorFlow on top of DirectML: https://github.com/tensorflow/community/pull/243 https://github.com/tensorflow/community/pull/243
        lostmsu 6y ago
        Oh well, I think that will take several years to land.
  - deleted 6y ago
    [deleted]
  - numpad0 6y ago
    In ML if you decide not to kiss NVIDIA's ass you're screwed. Figuratively they have 100% market share. Having major alternative backend, even if it's proprietary, will force diversity and that has some upsides I think.
- raphlinus 6y ago
  The associated blog post (https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/) does have more details on exposing display functionality. There is no swapchain functionality yet, but it's clear they're working on it, and part of the work is "DxCore", which seems to be a cleaned up and simplified version of DXGI. So not now, but soon.
  - chenzhekl 6y ago
    Yeah, this should be the right link. TL;DR Microsoft brings DirectX 12, OpenGL, OpenCL, and CUDA to WSL. Vulkan is under investigation. That's really a piece of exciting news!
  - dang 6y ago
    We've changed to that from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!
- modeless 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - pier25 6y ago
    > This will eventually be a full graphics stack Are we seeing the start of the migration of Windows to linux?
    - sandworm101 6y ago
      >> the migration of Windows to linux Please no. Please keep your peanut butter out of my chocolate. Call me a purist, but linux should take nothing from windows, give no ground, make no compromise. One must die for the other to live. https://bugs.launchpad.net/ubuntu/+bug/1 https://bugs.launchpad.net/ubuntu/+bug/1
      - agildehaus 6y ago
        Chocolate and peanut butter are pretty good together. Just sayin'.
        dgellow 6y ago
        Wait, is chocolate and peanut butter really a thing?! That sounds quite horrible to my non-US ears. Edit: yep, an online search seems to say that's an actual thing. I guess I'm part of the ten thousand today https://xkcd.com/1053/ https://xkcd.com/1053/. I will never understand the US fascination for peanut butter.
        6y ago
- miffe 6y ago
  They are also adding an wayland server. https://devblogs.microsoft.com/commandline/the-windows-subsystem-for-linux-build-2020-summary/#wsl-gui https://devblogs.microsoft.com/commandline/the-windows-subsy...
  - ghostpepper 6y ago
    Aren't large parts of the wayland stack incompatible with NVIDIA drivers? It would be ironic if Microsoft was the one to bridge that gap.
    - microcolonel 6y ago
      That's more a matter of buffer management. Though it may turn out , if their work is too tied to NVIDIA, to only support NVIDIA's de facto proprietary selection: EGLStreams. Though in principle, there's nothing preventing them from using GBM instead of EGLStreams, and there are some good practical reasons such as having compatibility with the broad base of existing accelerated Wayland windowing libraries and applications.
    - josefx 6y ago
      You can use Wayland with NVIDIA drivers. The problem is that NVIDIA and the open source drivers expose different buffer management APIs and Wayland does not abstract over that, so it has to be explicitly handled by every client application. Some Wayland clients refuse to support both, others had NVIDIA support patched in by NVIDIA itself.
      - dcgudeman 6y ago
        Sorry if this question misses the point but how did AMD avoid this issue? Are their drivers open source?
        josefx 6y ago
        AMD started to support the development of the open source driver several years ago by publishing hardware specs. . I am not sure if they switched completely or are still maintaining a closed source driver on the side - I haven't bought AMD cards in years, my last one only "works" with the binary blob. The people working on the NVIDIA open source driver have no official support and were fighting with signed firmware blobs last I heard. I wish them luck, but even on older cards it is more likely to crash your system than render anything.
- deadbunny 6y ago
  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/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139
  - Wowfunhappy 6y ago
    Is there a possibility Linux upstream won't accept it?
    - cdash 6y ago
      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.
    - detaro 6y ago
      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.
      - rezonant 6y ago
        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
    - kelnos 6y ago
      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.
- improv32 6y ago
  > AF_PACKET Just run a Linux hyper-v vm. That's what WSL2 is doing under the hood anyway. I run it this way and it's great. I have windows terminal auto ssh into it. Performance is great. And using the X server x410 on the windows side gui performance is fantastic (though no hardware acceleration) because instead of ssh tunneling x410 suports AF_VSOCK for the x socket, which hyper-v supports for performance as good as a domain socket on the same machine.
  - mauflows 6y ago
    I've had trouble researching if WSL2 is in fact a hyper-v managed VM. I've seen some documentation referring to WSL2 as a tightly integrated Krypton (scaled down hyper-V) VM. It seems to imply the host overhead isn't as high as a guest on hyper-V
    - monocasa 6y ago
      AFAICT Krypton is stripped down in the sense that a lot of the management framework is gone, but as far as the guest is concerned, it's running on hyper-v.
    - bitcrazed 6y ago
      WSL uses a Hyper-V derived virtual machine that is * Sparse & light - they only allocate resources from the host when needed, and release them back to the host when freed * Fast - it can boot a WSL distro from cold in < 2s * Transitional - these lightweight VMs are designed to run for up to days-weeks at a time Full Hyper-V VMs aim to (generally) grab all the resources they can and keep hold of those resources as long as possible in case they're needed. Full VMs are designed to run for months-years at a time. WSL's VMs are MUCH less impactful on the host - FWIW, I run 2-3 WSL distros at a time on my 4 year old 16GB Surface Pro 4 and don't even notice that they're running.
      - mauflows 6y ago
        But then you have this thread with people running Cron jobs to free cached memory: https://github.com/microsoft/WSL/issues/4166 https://github.com/microsoft/WSL/issues/4166 I imagine this will be addressed, but claims of lightweight seem exaggerated? But even more on my mind is the impact on the windows host. Is it running as a guest under hyper v? What's the overhead?
- Phylter 6y ago
  "There is currently no presentation integration with WSL as WSL is a console only experience today. The D3D12 API can be used for offscreen rendering and compute, but there is no swapchain support to copy pixels directly to the screen (yet )." This leads me to believe that display support is intended in the future. It's a work in progress. They've gone this far why would they stop at compute? Still, it's pretty awesome if you ask me.
  - dragonwriter 6y ago
    They've announced that Linux GUI apps are coming later this year to WSL2; while that is possible without GPU, I imagine MS wants a decent UX for the feature, though, which suggests...
- castis 6y ago
  > The Linux gaming folks will be pretty sad about this one. I was a tad bummed when realizing what this actually was, but still very much impressed.
- discordance 6y ago
  Ah that sucks, for a moment I thought I would be able to run Wine from within WSL2 and get my game on.
  - navanchauhan 6y ago
    if you are already running Windows and using Linux through WSL, why would you want to use WINE to run games?
    - dboreham 6y ago
      Possibly parent comment was a joke?
    - efreak 6y ago
      Because older games run better on wine than they do on windows. Though there's more recent software available to mitigate some of that (wined3d, winevdm, etc).
- Zardoz84 6y ago
  And wouldn't be faster simple use native Linux installed on the computer ? Instead of running on a VM, and a glue/translation layer from OpenGL/OpenCL/Vulkan/CUDA to DirectX. And don't forgot all the blotware and slowness that have Windows 10.
  - dividedbyzero 6y ago
    But then you lose all the benefits of an established desktop OS, like all hardware pretty much working, the OS pretty much working out of the box, plus software like Microsoft Office just runs without any additional effort, plus you get to profit from years or decades of muscle memory and OS-specific knowlegde, and maybe it's even about being allowed to connect your laptop to the company networks at all.
  - jamesgeck0 6y ago
    Speaking as someone who spent like a dozen hours trying to get his duel monitor setup working in Ubuntu and Fedora: no. It's not. My experience is that Linux has significantly worse hardware support than Windows, particularly where newer hardware is concerned.
- srg0 6y ago
  Gaming folks won't be running games in WSL when they can just run them in W.
- deleted 6y ago
  [deleted]
christoph-heiss 6y ago
FYI: This is the first draft of the Microsoft Virtual GPU (vGPU) driver. The driver exposes a paravirtualized GPU to user mode applications running in a virtual machine on a Windows host. This enables hardware acceleration in environment such as WSL (Windows Subsystem for Linux) where the Linux virtual machine is able to share the GPU with the Windows host. So this isn't actual "DirectX on Linux", just a driver for a virtual GPU exposed to WSL-guests to enable guests to directly use DirectX, more or less. Probably most useful for Azure-based projects.
- Avamander 6y ago
  This sounds like an attempt to win back ML segment from Linux to Windows. There are three letters back in my mind that sound like screaming, but too early to tell unfortunately.
  - rvz 6y ago
    In this case, this is the extend phase. So this is what they really mean about 'using Linux' and 'Microsoft <3 Linux'.
  - badRNG 6y ago
    How is it too early to tell? It is an extension of the capability of WSL, giving you that sweet convenience of the DirectX API with your existing ML project. Of course, this extension makes your project incompatible with desktop Linux once adopted.
    - dade_ 6y ago
      Not necessarily. It is not possible to access the GPU in WSL at all right now, so I need to dual boot which also means dealing with Linux desktop compatibility issues with my laptop. As long as I can use the same ML framework (without DirectX API), then this poses no compatibility issues at all. It just means I can develop & run my ML code in WSL.
      - 6y ago
jagger27 6y ago
The linked blog post in TFA has a clearer title: "DirectX is coming to the Windows Subsystem for Linux"
- guuguuguu 6y ago
  true
- dang 6y ago
  We've switched to that post now from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!
kalium-xyz 6y ago
The Year of the linux desktop has come
- smitty1e 6y ago
  The sheer hilarity of Microsoft doing this work cannot be over-chuckled.
- badRNG 6y ago
  This is not a port of DirectX for Linux. This extends the functionality of WSL at the expense of desktop Linux.
- squarefoot 6y ago
  Actually, the year of Linux on the desktop will never come also thanks to this. Developers will find more comfortable writing Linux software on Windows (some already do); desktop users will have both worlds at hand without being forced to dual boot; Linux gamers won't have any reasons to keep using native Linux. Etc. I foresee in a not so distant future Microsoft integrating Windows UI elements and events hooks right into WSL, so that Linux developers too will be able to take advantage of the well standardized Windows UI; no more GTK or Qt frankenapps on Windows: just pure Linux code written on well known Windows RADs that access all windows internals while opening standard Windows dialogs and widgets. That would likely take away a huge part of Linux users.
  - kalium-xyz 6y ago
    I disagree, i do not think that anyone would want to start running windows just to run the same software they already run while losing a chunk of control and support. However for the real argument, ask yourself: am I switching to using windows because of this?
    - dividedbyzero 6y ago
      I think it's the other way round: Do I still need to dual-boot or switch to Linux if this works? Or can I stick with Windows and have the best of both worlds?
wmf 6y ago
...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.
- deleted 6y ago
  [deleted]
- modeless 6y ago
  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.
  - wmf 6y ago
    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.
    - int_19h 6y ago
      This isn't merely another API, though. It's the one against which most graphics drivers are written.
      - atq2119 6y ago
        This is actually debatable. How many different GPUs are supported on Windows vs ob Linux? There are really only three vendors left on PC, while Linux supports these as well as a bunch of mobile GPUs...
    - modeless 6y ago
      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.
woadwarrior01 6y ago
Hopefully, this will enable Windows users will be able to run docker containers that use GPUs the way Linux users have been able to for years now with nvidia’s container toolkit[1]. [1]: https://github.com/NVIDIA/nvidia-docker https://github.com/NVIDIA/nvidia-docker
- mkl 6y ago
  From the linked blog post [1], it sounds like it: "In addition to CUDA support, we are also bringing support for NVIDIA-docker tools within WSL. The same containerized GPU workload that executes in the cloud can run as-is inside of WSL." [1] https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/
stefan_ 6y ago
This is the kind of driver that you get when you ignore all existing Linux code, then try to throw 15k LOC over the wall when its all done. Microsoft should really know better: this is not how you get your code upstreamed.
- cududa 6y ago
  Did you even read the article or comprehend it? This isn’t DirectX for Linux. It’s DirectX access for WSL compute
- rrss 6y ago
  I doubt Microsoft really cares. Microsoft will ship it in the linux kernel in WSL2, and people will use it, and if the upstream community doesn't want it I don't see why Microsoft would have a problem with that.
  - kelnos 6y ago
    They'd certainly prefer that upstream Linux maintains it for them. The more code they have to maintain out of tree, the harder it is for them to upgrade their WSL kernel.
- jfkebwjsbx 6y ago
  At least it is just 15K LOC!
- 0xcoffee 6y ago
  They mention its a 'first draft' and they want to work together to try and get a final draft in ~6 months.
zakk 6y ago
I remember when DirectX was a huge obstacle to porting games to Linux. This feels like a great, great victory for Linux to me!
- ThrowawayR2 6y ago
  You're not seeing the big picture. If Windows can do Windows apps and also 90% of what Linux developers use Linux for, what need is there ever for Linux on the desktop? MS marketing may be trumpeting their love for open source but WSL2 is a actually a brilliant bit of jujutsu[0] on Microsoft's part. [0] I use this word specifically because it's a martial art about using an opponent's strength against themselves. MS's use of Chrome as the basis for their new browser is another example of this.
  - mmcconnell1618 6y ago
    Microsoft saw developers flock to Mac OS/X where they had a true terminal and could also run line of business apps like Office. I was at several Microsoft developer conferences where 90% of the machines were MacBook Pros and I know that didn't make Microsoft leadership happy. I believe the Surface line was a direct response to that along with WSL. Someone in Redmond realized they couldn't beat Linux so now comes the embrace.
- deleted 6y ago
  [deleted]
- INTPenis 6y ago
  Someone please correct me if I'm wrong but I interpret this as being only a bridge to DirectX from the Linux kernel. Not a DX implementation on Linux. You won't be able to take this dxgkrnl driver and load it into a Linux workstation and get DirectX. And also, someone else responded to you what's the point of running Linux if Windows can do everything Linux can. I would assume that most full time Linux users are using it out of at least a tiny bit of ideological motivation. And if not ideological then habitual, having had the power and granular transparency of Linux for so many years that Windows would never be an alternative.
swiley 6y ago
Maybe I'm missing something but how is this an improvement over virgl? Something that's platform agnostic and works with applications right now being replaced with something that's very tied to windows. Not a fan but also not a graphics programmer.
4cao 6y ago
Is it really "DirectX on Linux," or more like "DirectX on Windows Subsystem for Linux?" Is it going to be useful for Linux in general, outside WSL?
- badRNG 6y ago
  No, this is only an extension of WSL, it will not impact desktop Linux.
  - 4cao 6y ago
    Thank you. In the meantime I also noticed the following comment from Dave Airlie on LKML [1]: > This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest. It's a binary transport between two binary pieces. [...] I can see why it might be nice to have this upstream, but I don't forsee any other Linux distributor ever enabling it or having to ship it, it's purely a WSL2 pipe. 1. https://lkml.org/lkml/2020/5/19/1288 https://lkml.org/lkml/2020/5/19/1288
    - monocasa 6y ago
      He's pretty against it on a number of fronts. That being said I don't see why distros like Ubuntu that allow non free code wouldn't ship with it out of the box. They already support Nvidia binary drivers anyway, so why wouldn't they support a transport bridge that'd let people use them on WSL too? Also, he notices that it's intended to be more than a bridge in the future, as they're already working on integrating it with the presentation layer on Linux.
      - kelnos 6y ago
        Why would they? In its current state, this driver is only useful when Linux is running on Windows. A regular Linux desktop/server user would not find this useful.
        monocasa 6y ago
techntoke 6y ago
Did anyone see the comments? https://lkml.org/lkml/2020/5/19/960 https://lkml.org/lkml/2020/5/19/960 https://lkml.org/lkml/2020/5/19/1288 https://lkml.org/lkml/2020/5/19/1288
- jschwartzi 6y ago
  Per the second one it sounds "relatively straightforward" but also "not really worth maintaining upstream."
29athrowaway 6y ago
DirectX on WSL and DirectX on Linux are not the same thing.
starpilot 6y ago
Great, now we might get RAPIDS on Windows! https://stackoverflow.com/questions/58623169/is-there-a-way-to-run-rapids-on-windows-pc https://stackoverflow.com/questions/58623169/is-there-a-way-...
- rrss 6y ago
  Looks like yes: https://news.ycombinator.com/item?id=23240076 https://news.ycombinator.com/item?id=23240076
satvikpendem 6y ago
This is probably a better article directly from Microsoft: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/ OpenCL, DirectX and CUDA all seem to be available for GPU acceleration on WSL. One other exciting thing is GPU accelerated GUI Linux apps on Windows. You may not need an X server anymore. I'm looking forward to using i3 on Windows.
- dang 6y ago
  Changed to that from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!
nly 6y ago
"There is no intent for anyone in the Linux world to start coding for the DX12 API." https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 "This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest." https://lkml.org/lkml/2020/5/19/1288 https://lkml.org/lkml/2020/5/19/1288
badRNG 6y ago
The title is misleading. This isn't DirectX on Linux. This is DirectX API access for WSL exclusively. It will lock ML projects into Windows/WSL for the price of access to the DirectX API and at the expense of development of other projects like Vulkan for native Linux.
- monocasa 6y ago
  Not anymore so than they're already locked into CUDA. It's more a WDDM bridge than a strict DirectX bridge.
  - badRNG 6y ago
    I don't see how being "locked into CUDA" should make one less skeptical of a change that will functionally lock projects into Windows. I can't help but think this is going to siphon resources from Linux native graphics development.
    - monocasa 6y ago
      I don't see how it'll be locking projects into windows. There's no user space DirectX library here. The whole point looks to take your CUDA code that would run just fine on Linux without a hypervisor, and run it just as well in WSL2. ie. this is at worst still the embrace stage, IMO.
      - jfkebwjsbx 6y ago
        They are providing libd3d12.so, that is a user space library that apps can link to. At the moment, that library only works under WSL, but I guess the DXVK folks can connect their implementation too.
        monocasa 6y ago
        > The plan is for Microsoft to provide shims to allow the existing Linux userspace interact with DX12; I'll explain below why we had to pipe DX12 all the way into the Linux guest, but this is not to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API. https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 And backing that up, they ported Mesa to get OpenGL and OpenCL in the Linux guest and are working on a Vulkan port as well.
arminiusreturns 6y ago
Why can't we all just agree and use Vulkan!?
- kbumsik 6y ago
  Yes Vulkan is supported as well. They are implementing Mesa driver on top of it: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/
- MaxBarraclough 6y ago
  I suppose the obvious answer is the Xbox One. Microsoft's consoles will presumably continue to support Direct3D and no other graphics APIs.
CobrastanJorji 6y ago
Am I mistaken, or is this not so much "DirectX on Linux," but only "DirectX on Linux VMs on Windows?"
wmichelin 6y ago
This title is misleading, I saw it and got really excited that someday we may be able to game on Linux.
- dang 6y ago
  Title fixed now. Was "DirectX on Linux".
- account42 6y ago
  > got really excited that someday we may be able to game on Linux. Someday? You can already game on Linux.
nihil75 6y ago
So they WILL port DirectX to Linux, but only when it's running as a VM atop Windows. Typical..
greatgib 6y ago
I did post my comment in another thread, but this is seriously very very bad: "Windows could be required to use some Linux apps (Embrace, extend, extinguish)" -> https://news.ycombinator.com/item?id=23238790 https://news.ycombinator.com/item?id=23238790 The most important is to look at the following page to better understand the implications: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/ Here is how I would sum it up: * They create a new kernel file descriptor: /dev/dxg * With this, on the Linux of WSL, it is like a direct "pipe" to a Windows host graphical stack. * So it means that they can put code in Linux application code that will use Windows proprietary graphical stacks, like DirectX through /dev/dxg. * And so, clearly, this Linux app will not work inside a normal Linux computer that is not a "guest" of Windows. Now, you can see the "Embrace" and the "Extend"? And to well understand the article, the following things have to be stressed: This is not just something to render a Window or something like that, it is a special "passthrough" api to all the things that are provided by Windows GPU stack/drivers. For example, they give the example of Cuda compute API, but also, they kind of "built" DirectX sdk itself for Linux (debian, ubuntu, ...), but still the proprietary closed blob that "apps" are expected to use, but that will rely on /dev/dxg. Also, if you want to use anything OpenGL on the Linux WSL, they will ensure that it is translated to DX on Linux side, before going through the same special DirectX api. The good thing would probably have been to do the opposite side, ensure that Windows has the proper OpenGL support to be able to pass gpu acceleration to the Windows host.
m0zg 6y ago
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.
mappu 6y ago
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.
floatingatoll 6y ago
Blog post from Microsoft linked at the top of the LKML email: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/
- dang 6y ago
  Changed to that from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!
wtallis 6y ago
I really wish Microsoft would just tell NVidia (and AMD) to support SR-IOV on all their GPUs. Then we wouldn't need any major software changes to enable CUDA acceleration within VMs, just a configuration change to pass through a virtual function of the GPU to make it available to existing drivers.
- justaguy88 6y ago
  I agree, this would dramatically simplify the situation
- rossmohax 6y ago
  AFAIK that's up to motherboard manufacturers. SR-IOV often doesn't work on desktops, I doubt there mass produced notbooks support it at all. MS can work with manufacturers, but they have their own incentives and it is unlikely to expect that all of them suddenly start doing a good job on this front. Meanwhile MS wants to cast widest possible net, so it needs to enable more and more workflows on WSL2 today, not tomorrow.
  - wtallis 6y ago
    Other than enabling the IOMMU (which any system with Thunderbolt should have on by default), what does the motherboard firmware actually need to do for SR-IOV? I can't see any reason why it would need to be concerned with enumerating Virtual Functions or anything like that, but I don't actually have the SR-IOV spec on hand to dig through. EDIT: Looking through an old Intel whitepaper, it looks like the system firmware at most has to reserve some extra config space for SR-IOV devices when enumerating the PFs, so that the OS can enumerate VFs after creating them. But Linux includes an option to re-allocate this stuff if the BIOS doesn't reserve space, so this apparently isn't a hard requirement.
- monocasa 6y ago
  SR-IOV doesn't make sense on most GPUs, because they have their own MMUs already with different semantics. SR-IOV is terrible for dealing with a large bank of RAM on the target device, because the MMU is in the wrong part of the architecture. It's all the way on the root complex, so all GPU VRAM reads and writes would need to take the slow path through PCI-E and back. This is basically a nonstarter for GPUs that have their own VRAM. They also don't cover the GPU specific caching information that's normally stored in the GPU page tables either. Intel is able to get away with it for integrated GPUs because they can codesign their system level IO-MMU with the GPU MMU and it doesn't have it's own VRAM bank. I'd bet dollars to donuts that Intel's new Xe discrete GPU doesn't support SR-IOV even though the integrated versions of the same core will.
shmerl 6y ago
Not impressed, especially since it's still a blob. MS should stop fooling around and should start supporting Vulkan instead of pushing their DX lock-in and making hypocritical statements how they aren't on the wrong side of history anymore because they "support open source". The above feels like typical MS EEE.
Koshkin 6y ago
Twenty years ago Microsoft wanted to make Java “the best language for Windows programming.” Today, apparently, they want to make Windows “the best environment for running Linux.” (This time around they might even succeed.)
gmanley 6y ago
I found this reply to be especially interesting: https://lkml.org/lkml/2020/5/19/1309 https://lkml.org/lkml/2020/5/19/1309 > I also have another concern from a legal standpoint I'd rather not review the ioctl part of this. I'd probably request other DRI developers abstain as well. > This is a Windows kernel API being smashed into a Linux driver. I don't want to be tainted by knowledge of an API that I've no idea of the legal status of derived works. (it this all covered patent wise under OIN?) > I don't want to ever be accused of designing a Linux kernel API with illgotten D3DKMT knowledge, I feel tainting myself with knowledge of a proprietary API might cause derived work issues. This is the real scary part about software patents, and more specifically, patenting APIs. I'm not saying Microsoft is doing this in this case, but it could be a very real strategy by a bad actor. Attempt to taint open source software with your patented software and then litigate. In a dystopian future where patented software API lawsuits have become a common occurrence, I could imagine "clean room people". Individuals who can be guaranteed to not have been exposed to certain software designs.
- dang 6y ago
  (The originally submitted URL was https://lkml.org/lkml/2020/5/19/742. https://lkml.org/lkml/2020/5/19/742.)
- _ph_ 6y ago
  With looking at source, you have to distinguish between copyright (the license) and possible patent status. You should indeed be careful when looking at code with an unclear license, as this opens you up to claims of copyright violations. However with patents, the situation is different (which makes them so problematic). Patent violation is solely based on whether your code violates a patent or not. Having looked at other sources or not doesn't change anything about the possible violation. This is, what makes patents so nasty.
- jfkebwjsbx 6y ago
  On the other hand, if Microsoft themselves are publishing this code as open source, on the open, on one of the most important projects out there, and are actively asking other experts from other companies to review it, I would imagine they are weakening their arguments on the potential litigation.
dang 6y ago
We changed the url from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742, which points to this.
ngcc_hk 6y ago
Embrace - wsl 1/2 Extend - features you really open source to have and they fix it (running on laptop, apple do not do Nvidia) but try their best only run in their linux versus Extinguished - may the last one turn the light off, and thanks you for all the fishes
unnouinceput 6y ago
Ohhh, such a smart move. If there was any momentum of gaining developers on Linux for gaming this will crush it. Microsoft is eating Linux with a "loving" embrace.
- wvenable 6y ago
  I'm curious why you think this would make any difference to Linux gaming? If you want games to only run on Windows, they can just develop them for Windows. There's no need to put Linux in the middle.
  - unnouinceput 6y ago
    Vulkan means cross-platform independent of OS. This is a move by Microsoft to lure any undecided/new game developers back to their walled garden. If you don't see this, let's talk in 10 years again - assuming Microsoft doesn't crap on it along the way.
    - hgoel 6y ago
      Being able to run dx12 in a virtualized environment that's still under Windows (and thus not actually changing anything vs just developing only for windows) is going to lure undecided game developers how?
      - unnouinceput 6y ago
        Say you're a game developer under Linux, OK? Then this comes along and you give it a try. This combined with all the great game engines that are pure Windows these days (see Unreal Engine 5 demo that was launched these days) and you now can target Linux using that. What do you do - continue with Vulkan or offer your game using this?
        wvenable 6y ago
        You can't target Linux using that. I think you misunderstand what this is. It doesn't help nor hurt Vulkan or Linux development -- this only exists to "optimize" the Linux VM in Windows.
Sugaralmond 6y ago
i love jeff bezbos
dzonga 6y ago
EEE, slowly the Linux desktop | os environment will be a thing of the past. something you won't run directly but interact via the windows api. and your only other choice will be mac os on arm. the biggest mistake the linux ecosystem did, was being so fragmented. if they had rallied around one desktop env, then lots of people would've migrated. I personally use a t490 on ubuntu and a 2013 macbook. but even I I'm attempted to try out WSL even though, I haven't used windows in over a decade
- rvz 6y ago
  > the biggest mistake the linux ecosystem did, was being so fragmented. I'm not sure how many times I have pointed this out here, but given the lack of a standardized desktop environment, that is the reason why most software companies are reluctant to support Linux users. But in contrast with 'Android' in the mobile industry has succeeded in doing this with Linux as its kernel. For a typical or even a complex desktop app, I can support 100% of all Windows users, 100% of the time. macOS is more or less the same here. Linux distros however has this fragmentation running so deep that to target the majority of users there, you must supporting 5+ distros they could be running. That's 5+ CIs to maintain and 5+ troubleshooting guides to update here. As even Linus Torvalds would say: > 'I still wish we were better at having a standardize desktop that goes across all the distributions… It’s not a kernel issue. It’s more of a personal annoyance how the fragmentation of the different vendors have, I think, held the desktop back a bit. ' This is a distro ecosystem problem, not a 'kernel' issue.
  - _ph_ 6y ago
    While he is right that it is not a "kernel" issue in the strict sense, I have to say it would have been beneficial, if Linus had used his influence to push more for a better desktop environment.
momokoko 6y ago
I see all the Microsoft team members are here in votes and comments as always. dang, this is not a fallacy with Microsoft. There are huge numbers of marketing employees in these threads
- dang 6y ago
  You're breaking the site guidelines with this comment. They ask you not to post allegations of astroturfing, etc., without evidence. Things appearing that you happen to dislike (from Microsoft or any other source) are not evidence of astroturfing, they're just evidence of a large community. If you think you're seeing abuse you should be contacting us at hn@ycombinator.com with links, so we can investigate. No more posting like this, please. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
hiram112 6y ago
I was a beta user of WSL1. It was interesting, but the very slow file system performance from Windows to Linux and vice versa was a deal breaker for development use. I haven't even bothered to use WSL2 because I hardly use Windows anymore, and I was forced to use VMWare with Linux on Windows for a few years of development work. It was always a pain, too, and once I switched to MacBook, I never looked back. Since then, I assumed WSL2 wasn't going to be used much by 'real developers' as it also had many of the same problems that plague VMWare and VirtualBox, which haven't been adopted by enough developers to pose a threat Linux native and Mac users. But I really feel MS is throwing a lot of resources into this. It's not just a quick fix for those users who need a command line but wouldn't ever consider Linux or Mac anyway, as I initially thought. And if this gets 'good enough' then imagine even more trouble for Linux and especially Mac's grip on engineers and scientists. Ubuntu, Redhat, and the rest have utterly failed to work with Dell or Lenovo or HP to concentrate on just one or two very well supported laptops - everything including suspend, battery life, ACPI, fonts, etc. It's a chicken and egg problem - workstations aren't profitable because most users won't put up with the hardware and driver problems. And without paying users, the distros ignore potential pro users to concentrate on enterprise. As for Mac, while I'm happy they've finally fixed the keyboard and allowed 32GB+ ram, that configuration looks absurdly expensive at $3500 compared to a similarly configured $1700 Dell Precision or Thinkpad. And MacOs has gotten worse over the years, not better. There is nothing really compelling me to stay except for it's Unix compatibility. WSL2 may eventually be the final nail in the coffin for a viable Linux Desktop, and Apple should be worried too, though they appear to have forgotten about pro users years ago anyway.
- m01 6y ago
  Dell have developer edition laptops that come with Ubuntu preinstalled and I saw a link on HN not long ago about Fedora coming to Lenovo laptops (I think it was https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/ https://fedoramagazine.org/coming-soon-fedora-on-lenovo-lapt...). I've not used them myself but I'd hope the situation isn't as dire as you describe, at least for those selected models.
  - hiram112 6y ago
jaimex2 6y ago
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
kristopolous 6y ago
I also found the phrasing of this to be ambiguous. Windows (subsystem for Linux) has a Windows host running Linux Or (Windows subsystem) for Linux has Windows running on a Linux host They've been using this phrasing since the OS/2 and POSIX subsystem days and it was also confusing then Quarterdeck did it right with Desqview/X by just renaming their WIN16 subsystem as winx. Then you would see "desqview winx" and know that it's windows running on desqview and not the other way around. IBM also got it right: OS/2 Windows VDM. I know it's running on OS/2. But Microsoft has been running with this phrasing since literally Windows NT and it's always been confusing.
- kgwxd 6y ago
  Wasn't it originally something like "Linux Subsystem for Windows" and there was some legal problem with the word "Linux" being first?
  - kristopolous 6y ago
    Apparently people have used the words swapped to mean the same thing. It's bad. Microsoft releasing something to run windows software on Linux, maybe for some exorbitant fee and only on say, the commercial versions of RHEL to undercut Wine progress, not only doesn't seem out of the question but also a reasonable defensive strategy and something I totally missed the announcement of. It's not like I'm a tech reporter, I go into my work for a couple weeks missing everything pretty often
adammunich 6y ago
How about sockets...
ComodoHacker 6y ago
>This is the real and full D3D12 API, no imitations, pretender or reimplementation But isn't Direct3D a COM API?
visarga 6y ago
The big news is Docker support for GPUs on Windows. You could train on GPU on Windows but you couldn't serve the model without Docker, as a business.
owaislone 6y ago
As far I understood the article, this does bring the DirectX API to Linux but in it's current shape it's only usable in WSL as the API implementation uses the virtual devices under the hood provided by WSL. Legal/licensing issue aside, how hard would it be to re-purpose this to make it available under something like Wine or even natively on Linux with real graphics devices? How much of this is till locked in on the Windows host side?
owaislone 6y ago
It seems Microsoft is getting closer to making Windows a fully Linux compatible OS. I wouldn't be surprised to see them get rid of virtualized distros running in WSL at some point and Windows natively becoming POSIX complaint.
lalaland1125 6y ago
It appears that Microsoft has now initiated the "Extend" phase of their classic Embrace, Extend, Extinguish playbook. The key is that the proprietary Microsoft specific API added by this patch is only usable in a WSL environment as it relies on many pieces of proprietary closed source software that Microsoft is unwilling to open source. This patch does nothing but fragment the Linux ecosystem and encourage people to develop software that only works in WSL environments. With the "benefit" of forcing the Linux kernel developers to pay the maintenance costs of course.
- quietbritishjim 6y ago
  According to the comment by christoph-heiss, this is just a paravirtualisation technique and will appear like a normal Limux GPU driver to applications running on WSL, rather than a special DirectX for Linux API that won't work on Linux itself.
  - lalaland1125 6y ago
    I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. From the email introducing the set of patches: > The projection is accomplished by exposing the WDDM (Windows Display Driver Model) interface as a set of IOCTL. This allows APIs and user mode driver written against the WDDM GPU abstraction on Windows to be ported to run within a Linux environment. This enables the port of the D3D12 and DirectML APIs as well as their associated user mode driver to Linux.
    - monocasa 6y ago
      > I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The fact that they went through the effort of porting Mesa to get OpenGL and Open CL support, and are working on Vulkan support.
      - 6y ago
mikorym 6y ago
Maybe this question has an obvious answer, but will I still need to start my X Window System for graphics to display from my WSL terminal? My guess is that the answer is yes, but the type of applications that can be run is now extended? Conversely, I would expect this doesn't change anything with regards to SSHuttle, which would still not work on WSL.
mpfundstein 6y ago
even though I am quite successfully using pytorch under win (with conda), ... THIS IS EPIC. because now o can finally go full wsl and a pretty good excuse to switch to fast lane. i love wsl(2) and this is the icing on the cake.
dvfjsdhgfv 6y ago
I wish they did away with these heart symbols, professing their love for open source. Yes, we got that, Linux brings MS tons of money via Azure, but all this monkey show about love is plain disgusting, I can't imagine someone falling for that.
pojntfx 6y ago
WTF. Just use Vulkan like a normal person.
pojntfx 6y ago
EXTEND. M$ have not changed.
SXX 6y ago
I just hope David Airlie not going to merge it.
acd 6y ago
Windows will become an emulation layer in Linux when Microsoft is tired of maintaining Windows kernel/sees profit in running Windows apps native on Linux. SQL server is already ported.
rietta 6y ago
I remember starting to use and learn Visual J++ just to find out that if one wasn't really careful the code you wrote didn't run on other systems. If I was going to keep making a Windows only program, I preferred to stick with Visual Basic at the time. The real Java SDK was harder to learn for teenager me so I dropped it for a couple years until I started at Georgia Tech, which used Java extensively.
Grimm1 6y ago
Yeah, I don't buy the arguments here that Microsoft can extinguish Linux. Or would want to. Who's going to run Window's servers just to enable wsl? This is clearly targeted at developers coming back to windows on the PC, the aim is even stated as such to "enable IDEs" on wsl. I've ran arch, ubuntu and debian on my various systems, not because I want to but because they have the superior development environment in the terminal, outside of that Linux still feels janky and doesn't have any market share because of that. Microsoft is making something I've wanted for a while, I can get Linux off my desktop and laptop do my development and my game playing on Windows and ssh into my servers for any heavy lifting. This sounds like it will be a great win for devs.
prometheus76 6y ago
Nobody: Microsoft: Now you can use DirectX in the Windows Subsystem for Linux!
modmans2nd 6y ago
Step 1) Put a Linux Kernel on Windows as a separate subsystem Step 2) Port all APIs to this Kernel Step 3) Switch over to Linux as the main kernel and make the windows kernel a a Linux sub system to support legacy win32 apps. Step 4) Make all win32 support into a containerized system Microsoft moves to a Linux based system it offers for free and is only used for integration and support of it’s services.
prirun 6y ago
Here's the "new" Microsoft: https://news.ycombinator.com/item?id=23255591 https://news.ycombinator.com/item?id=23255591

706 points by modeless 6y ago

> This also enables third party APIs, such as the popular NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment. Dollars to donuts this is why Microsoft is implementing this. GPU acceleration is becoming a critical feature for many users (but especially developers) and this will continue. If WSL is to be a serious competitor, this is necessary and I'm glad to see it showing up. This is true of cloud compute, too, and Microsoft is betting big on cloud as its future growth area. > Only the rendering/compute aspect of the GPU are projected to the virtual machine, no display functionality is exposed. The Linux gaming folks will be pretty sad about this one. Anyway, this isn't really a Linux port of DirectX. This is GPU compute via DirectX APIs. So now, I'm just waiting on monitor mode/AF_PACKET for WSL...

Mic92 6y ago
Do ML people actually care about DirectX? I thought everyone is using CUDA? Anyway in my university building I have not seen anyone that does machine learning on Windows.
- modeless 6y ago
  CUDA is supported as well.
- raphlinus 6y ago
  Yes, (almost) everybody doing machine learning is on CUDA. There are multiple pieces of this work, and the DirectX API's are only part of it. Other pieces get CUDA running as well. And yet another piece is a layer to get OpenGL and OpenCL workloads running on DX12 as well, rather similar in scope to how MoltenVK and the gfx-hal Vulkan Portability work are a layer to get Vulkan workloads running on Metal. This is a big effort, and it seems to me their goal is to get things to the point where stuff Just Works and you don't have to think too hard about the various bits of (technically difficult!) infrastructure to get you there.
- cududa 6y ago
  A bit of a tip, your university development experience is not going to be like anything you see in production
- anaisbetts 6y ago
  They typically don't - the team published both a special build of Tensorflow that uses DirectX, as well as working with nVidia to get CUDA running against their DX Linux kernel implementation
  - lostmsu 6y ago
    > special build of Tensorflow that uses DirectX Huh? Are you sure about that? Regular TensorFlow on Windows uses CUDA, not DirectX-flavored compute.
    - raphlinus 6y ago
      I was also surprised, but found this RFC for TensorFlow on top of DirectML: https://github.com/tensorflow/community/pull/243 https://github.com/tensorflow/community/pull/243
      - lostmsu 6y ago
        Oh well, I think that will take several years to land.
- deleted 6y ago
  [deleted]
- numpad0 6y ago
  In ML if you decide not to kiss NVIDIA's ass you're screwed. Figuratively they have 100% market share. Having major alternative backend, even if it's proprietary, will force diversity and that has some upsides I think.
raphlinus 6y ago
The associated blog post (https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/) does have more details on exposing display functionality. There is no swapchain functionality yet, but it's clear they're working on it, and part of the work is "DxCore", which seems to be a cleaned up and simplified version of DXGI. So not now, but soon.
- chenzhekl 6y ago
  Yeah, this should be the right link. TL;DR Microsoft brings DirectX 12, OpenGL, OpenCL, and CUDA to WSL. Vulkan is under investigation. That's really a piece of exciting news!
- dang 6y ago
  We've changed to that from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!
modeless 6y ago
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.
- deleted 6y ago
  [deleted]
- pier25 6y ago
  > This will eventually be a full graphics stack Are we seeing the start of the migration of Windows to linux?
  - sandworm101 6y ago
    >> the migration of Windows to linux Please no. Please keep your peanut butter out of my chocolate. Call me a purist, but linux should take nothing from windows, give no ground, make no compromise. One must die for the other to live. https://bugs.launchpad.net/ubuntu/+bug/1 https://bugs.launchpad.net/ubuntu/+bug/1
    - agildehaus 6y ago
      Chocolate and peanut butter are pretty good together. Just sayin'.
      - dgellow 6y ago
        Wait, is chocolate and peanut butter really a thing?! That sounds quite horrible to my non-US ears. Edit: yep, an online search seems to say that's an actual thing. I guess I'm part of the ten thousand today https://xkcd.com/1053/ https://xkcd.com/1053/. I will never understand the US fascination for peanut butter.
        6y ago
miffe 6y ago
They are also adding an wayland server. https://devblogs.microsoft.com/commandline/the-windows-subsystem-for-linux-build-2020-summary/#wsl-gui https://devblogs.microsoft.com/commandline/the-windows-subsy...
- ghostpepper 6y ago
  Aren't large parts of the wayland stack incompatible with NVIDIA drivers? It would be ironic if Microsoft was the one to bridge that gap.
  - microcolonel 6y ago
    That's more a matter of buffer management. Though it may turn out , if their work is too tied to NVIDIA, to only support NVIDIA's de facto proprietary selection: EGLStreams. Though in principle, there's nothing preventing them from using GBM instead of EGLStreams, and there are some good practical reasons such as having compatibility with the broad base of existing accelerated Wayland windowing libraries and applications.
  - josefx 6y ago
    You can use Wayland with NVIDIA drivers. The problem is that NVIDIA and the open source drivers expose different buffer management APIs and Wayland does not abstract over that, so it has to be explicitly handled by every client application. Some Wayland clients refuse to support both, others had NVIDIA support patched in by NVIDIA itself.
    - dcgudeman 6y ago
      Sorry if this question misses the point but how did AMD avoid this issue? Are their drivers open source?
      - josefx 6y ago
        AMD started to support the development of the open source driver several years ago by publishing hardware specs. . I am not sure if they switched completely or are still maintaining a closed source driver on the side - I haven't bought AMD cards in years, my last one only "works" with the binary blob. The people working on the NVIDIA open source driver have no official support and were fighting with signed firmware blobs last I heard. I wish them luck, but even on older cards it is more likely to crash your system than render anything.
deadbunny 6y ago
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/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139
- Wowfunhappy 6y ago
  Is there a possibility Linux upstream won't accept it?
  - cdash 6y ago
    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.
  - detaro 6y ago
    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.
    - rezonant 6y ago
      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
  - kelnos 6y ago
    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.
improv32 6y ago
> AF_PACKET Just run a Linux hyper-v vm. That's what WSL2 is doing under the hood anyway. I run it this way and it's great. I have windows terminal auto ssh into it. Performance is great. And using the X server x410 on the windows side gui performance is fantastic (though no hardware acceleration) because instead of ssh tunneling x410 suports AF_VSOCK for the x socket, which hyper-v supports for performance as good as a domain socket on the same machine.
- mauflows 6y ago
  I've had trouble researching if WSL2 is in fact a hyper-v managed VM. I've seen some documentation referring to WSL2 as a tightly integrated Krypton (scaled down hyper-V) VM. It seems to imply the host overhead isn't as high as a guest on hyper-V
  - monocasa 6y ago
    AFAICT Krypton is stripped down in the sense that a lot of the management framework is gone, but as far as the guest is concerned, it's running on hyper-v.
  - bitcrazed 6y ago
    WSL uses a Hyper-V derived virtual machine that is * Sparse & light - they only allocate resources from the host when needed, and release them back to the host when freed * Fast - it can boot a WSL distro from cold in < 2s * Transitional - these lightweight VMs are designed to run for up to days-weeks at a time Full Hyper-V VMs aim to (generally) grab all the resources they can and keep hold of those resources as long as possible in case they're needed. Full VMs are designed to run for months-years at a time. WSL's VMs are MUCH less impactful on the host - FWIW, I run 2-3 WSL distros at a time on my 4 year old 16GB Surface Pro 4 and don't even notice that they're running.
    - mauflows 6y ago
      But then you have this thread with people running Cron jobs to free cached memory: https://github.com/microsoft/WSL/issues/4166 https://github.com/microsoft/WSL/issues/4166 I imagine this will be addressed, but claims of lightweight seem exaggerated? But even more on my mind is the impact on the windows host. Is it running as a guest under hyper v? What's the overhead?
Phylter 6y ago
"There is currently no presentation integration with WSL as WSL is a console only experience today. The D3D12 API can be used for offscreen rendering and compute, but there is no swapchain support to copy pixels directly to the screen (yet )." This leads me to believe that display support is intended in the future. It's a work in progress. They've gone this far why would they stop at compute? Still, it's pretty awesome if you ask me.
- dragonwriter 6y ago
  They've announced that Linux GUI apps are coming later this year to WSL2; while that is possible without GPU, I imagine MS wants a decent UX for the feature, though, which suggests...
castis 6y ago
> The Linux gaming folks will be pretty sad about this one. I was a tad bummed when realizing what this actually was, but still very much impressed.
discordance 6y ago
Ah that sucks, for a moment I thought I would be able to run Wine from within WSL2 and get my game on.
- navanchauhan 6y ago
  if you are already running Windows and using Linux through WSL, why would you want to use WINE to run games?
  - dboreham 6y ago
    Possibly parent comment was a joke?
  - efreak 6y ago
    Because older games run better on wine than they do on windows. Though there's more recent software available to mitigate some of that (wined3d, winevdm, etc).
Zardoz84 6y ago
And wouldn't be faster simple use native Linux installed on the computer ? Instead of running on a VM, and a glue/translation layer from OpenGL/OpenCL/Vulkan/CUDA to DirectX. And don't forgot all the blotware and slowness that have Windows 10.
- dividedbyzero 6y ago
  But then you lose all the benefits of an established desktop OS, like all hardware pretty much working, the OS pretty much working out of the box, plus software like Microsoft Office just runs without any additional effort, plus you get to profit from years or decades of muscle memory and OS-specific knowlegde, and maybe it's even about being allowed to connect your laptop to the company networks at all.
- jamesgeck0 6y ago
  Speaking as someone who spent like a dozen hours trying to get his duel monitor setup working in Ubuntu and Fedora: no. It's not. My experience is that Linux has significantly worse hardware support than Windows, particularly where newer hardware is concerned.
srg0 6y ago
Gaming folks won't be running games in WSL when they can just run them in W.
deleted 6y ago
[deleted]

christoph-heiss 6y ago

FYI: This is the first draft of the Microsoft Virtual GPU (vGPU) driver. The driver exposes a paravirtualized GPU to user mode applications running in a virtual machine on a Windows host. This enables hardware acceleration in environment such as WSL (Windows Subsystem for Linux) where the Linux virtual machine is able to share the GPU with the Windows host. So this isn't actual "DirectX on Linux", just a driver for a virtual GPU exposed to WSL-guests to enable guests to directly use DirectX, more or less. Probably most useful for Azure-based projects.

Avamander 6y ago
This sounds like an attempt to win back ML segment from Linux to Windows. There are three letters back in my mind that sound like screaming, but too early to tell unfortunately.
- rvz 6y ago
  In this case, this is the extend phase. So this is what they really mean about 'using Linux' and 'Microsoft <3 Linux'.
- badRNG 6y ago
  How is it too early to tell? It is an extension of the capability of WSL, giving you that sweet convenience of the DirectX API with your existing ML project. Of course, this extension makes your project incompatible with desktop Linux once adopted.
  - dade_ 6y ago
    Not necessarily. It is not possible to access the GPU in WSL at all right now, so I need to dual boot which also means dealing with Linux desktop compatibility issues with my laptop. As long as I can use the same ML framework (without DirectX API), then this poses no compatibility issues at all. It just means I can develop & run my ML code in WSL.
    - 6y ago

jagger27 6y ago

The linked blog post in TFA has a clearer title: "DirectX is coming to the Windows Subsystem for Linux"

guuguuguu 6y ago
true
dang 6y ago
We've switched to that post now from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!

kalium-xyz 6y ago

The Year of the linux desktop has come

smitty1e 6y ago
The sheer hilarity of Microsoft doing this work cannot be over-chuckled.
badRNG 6y ago
This is not a port of DirectX for Linux. This extends the functionality of WSL at the expense of desktop Linux.
squarefoot 6y ago
Actually, the year of Linux on the desktop will never come also thanks to this. Developers will find more comfortable writing Linux software on Windows (some already do); desktop users will have both worlds at hand without being forced to dual boot; Linux gamers won't have any reasons to keep using native Linux. Etc. I foresee in a not so distant future Microsoft integrating Windows UI elements and events hooks right into WSL, so that Linux developers too will be able to take advantage of the well standardized Windows UI; no more GTK or Qt frankenapps on Windows: just pure Linux code written on well known Windows RADs that access all windows internals while opening standard Windows dialogs and widgets. That would likely take away a huge part of Linux users.
- kalium-xyz 6y ago
  I disagree, i do not think that anyone would want to start running windows just to run the same software they already run while losing a chunk of control and support. However for the real argument, ask yourself: am I switching to using windows because of this?
  - dividedbyzero 6y ago
    I think it's the other way round: Do I still need to dual-boot or switch to Linux if this works? Or can I stick with Windows and have the best of both worlds?

wmf 6y ago

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

deleted 6y ago
[deleted]
modeless 6y ago
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.
- wmf 6y ago
  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.
  - int_19h 6y ago
    This isn't merely another API, though. It's the one against which most graphics drivers are written.
    - atq2119 6y ago
      This is actually debatable. How many different GPUs are supported on Windows vs ob Linux? There are really only three vendors left on PC, while Linux supports these as well as a bunch of mobile GPUs...
  - modeless 6y ago
    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.

woadwarrior01 6y ago

Hopefully, this will enable Windows users will be able to run docker containers that use GPUs the way Linux users have been able to for years now with nvidia’s container toolkit[1]. [1]: https://github.com/NVIDIA/nvidia-docker https://github.com/NVIDIA/nvidia-docker

mkl 6y ago
From the linked blog post [1], it sounds like it: "In addition to CUDA support, we are also bringing support for NVIDIA-docker tools within WSL. The same containerized GPU workload that executes in the cloud can run as-is inside of WSL." [1] https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/

stefan_ 6y ago

This is the kind of driver that you get when you ignore all existing Linux code, then try to throw 15k LOC over the wall when its all done. Microsoft should really know better: this is not how you get your code upstreamed.

cududa 6y ago
Did you even read the article or comprehend it? This isn’t DirectX for Linux. It’s DirectX access for WSL compute
rrss 6y ago
I doubt Microsoft really cares. Microsoft will ship it in the linux kernel in WSL2, and people will use it, and if the upstream community doesn't want it I don't see why Microsoft would have a problem with that.
- kelnos 6y ago
  They'd certainly prefer that upstream Linux maintains it for them. The more code they have to maintain out of tree, the harder it is for them to upgrade their WSL kernel.
jfkebwjsbx 6y ago
At least it is just 15K LOC!
0xcoffee 6y ago
They mention its a 'first draft' and they want to work together to try and get a final draft in ~6 months.

zakk 6y ago

I remember when DirectX was a huge obstacle to porting games to Linux. This feels like a great, great victory for Linux to me!

ThrowawayR2 6y ago
You're not seeing the big picture. If Windows can do Windows apps and also 90% of what Linux developers use Linux for, what need is there ever for Linux on the desktop? MS marketing may be trumpeting their love for open source but WSL2 is a actually a brilliant bit of jujutsu[0] on Microsoft's part. [0] I use this word specifically because it's a martial art about using an opponent's strength against themselves. MS's use of Chrome as the basis for their new browser is another example of this.
- mmcconnell1618 6y ago
  Microsoft saw developers flock to Mac OS/X where they had a true terminal and could also run line of business apps like Office. I was at several Microsoft developer conferences where 90% of the machines were MacBook Pros and I know that didn't make Microsoft leadership happy. I believe the Surface line was a direct response to that along with WSL. Someone in Redmond realized they couldn't beat Linux so now comes the embrace.
deleted 6y ago
[deleted]
INTPenis 6y ago
Someone please correct me if I'm wrong but I interpret this as being only a bridge to DirectX from the Linux kernel. Not a DX implementation on Linux. You won't be able to take this dxgkrnl driver and load it into a Linux workstation and get DirectX. And also, someone else responded to you what's the point of running Linux if Windows can do everything Linux can. I would assume that most full time Linux users are using it out of at least a tiny bit of ideological motivation. And if not ideological then habitual, having had the power and granular transparency of Linux for so many years that Windows would never be an alternative.

swiley 6y ago

Maybe I'm missing something but how is this an improvement over virgl? Something that's platform agnostic and works with applications right now being replaced with something that's very tied to windows. Not a fan but also not a graphics programmer.

4cao 6y ago

Is it really "DirectX on Linux," or more like "DirectX on Windows Subsystem for Linux?" Is it going to be useful for Linux in general, outside WSL?

badRNG 6y ago
No, this is only an extension of WSL, it will not impact desktop Linux.
- 4cao 6y ago
  Thank you. In the meantime I also noticed the following comment from Dave Airlie on LKML [1]: > This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest. It's a binary transport between two binary pieces. [...] I can see why it might be nice to have this upstream, but I don't forsee any other Linux distributor ever enabling it or having to ship it, it's purely a WSL2 pipe. 1. https://lkml.org/lkml/2020/5/19/1288 https://lkml.org/lkml/2020/5/19/1288
  - monocasa 6y ago
    He's pretty against it on a number of fronts. That being said I don't see why distros like Ubuntu that allow non free code wouldn't ship with it out of the box. They already support Nvidia binary drivers anyway, so why wouldn't they support a transport bridge that'd let people use them on WSL too? Also, he notices that it's intended to be more than a bridge in the future, as they're already working on integrating it with the presentation layer on Linux.
    - kelnos 6y ago
      Why would they? In its current state, this driver is only useful when Linux is running on Windows. A regular Linux desktop/server user would not find this useful.
      - monocasa 6y ago

techntoke 6y ago

Did anyone see the comments? https://lkml.org/lkml/2020/5/19/960 https://lkml.org/lkml/2020/5/19/960 https://lkml.org/lkml/2020/5/19/1288 https://lkml.org/lkml/2020/5/19/1288

jschwartzi 6y ago
Per the second one it sounds "relatively straightforward" but also "not really worth maintaining upstream."

29athrowaway 6y ago

DirectX on WSL and DirectX on Linux are not the same thing.

starpilot 6y ago

Great, now we might get RAPIDS on Windows! https://stackoverflow.com/questions/58623169/is-there-a-way-to-run-rapids-on-windows-pc https://stackoverflow.com/questions/58623169/is-there-a-way-...

rrss 6y ago
Looks like yes: https://news.ycombinator.com/item?id=23240076 https://news.ycombinator.com/item?id=23240076

satvikpendem 6y ago

This is probably a better article directly from Microsoft: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/ OpenCL, DirectX and CUDA all seem to be available for GPU acceleration on WSL. One other exciting thing is GPU accelerated GUI Linux apps on Windows. You may not need an X server anymore. I'm looking forward to using i3 on Windows.

dang 6y ago
Changed to that from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!

nly 6y ago

"There is no intent for anyone in the Linux world to start coding for the DX12 API." https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 "This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest." https://lkml.org/lkml/2020/5/19/1288 https://lkml.org/lkml/2020/5/19/1288

badRNG 6y ago

The title is misleading. This isn't DirectX on Linux. This is DirectX API access for WSL exclusively. It will lock ML projects into Windows/WSL for the price of access to the DirectX API and at the expense of development of other projects like Vulkan for native Linux.

monocasa 6y ago
Not anymore so than they're already locked into CUDA. It's more a WDDM bridge than a strict DirectX bridge.
- badRNG 6y ago
  I don't see how being "locked into CUDA" should make one less skeptical of a change that will functionally lock projects into Windows. I can't help but think this is going to siphon resources from Linux native graphics development.
  - monocasa 6y ago
    I don't see how it'll be locking projects into windows. There's no user space DirectX library here. The whole point looks to take your CUDA code that would run just fine on Linux without a hypervisor, and run it just as well in WSL2. ie. this is at worst still the embrace stage, IMO.
    - jfkebwjsbx 6y ago
      They are providing libd3d12.so, that is a user space library that apps can link to. At the moment, that library only works under WSL, but I guess the DXVK folks can connect their implementation too.
      - monocasa 6y ago
        > The plan is for Microsoft to provide shims to allow the existing Linux userspace interact with DX12; I'll explain below why we had to pipe DX12 all the way into the Linux guest, but this is not to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API. https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139 And backing that up, they ported Mesa to get OpenGL and OpenCL in the Linux guest and are working on a Vulkan port as well.

arminiusreturns 6y ago

Why can't we all just agree and use Vulkan!?

kbumsik 6y ago
Yes Vulkan is supported as well. They are implementing Mesa driver on top of it: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/
MaxBarraclough 6y ago
I suppose the obvious answer is the Xbox One. Microsoft's consoles will presumably continue to support Direct3D and no other graphics APIs.

CobrastanJorji 6y ago

Am I mistaken, or is this not so much "DirectX on Linux," but only "DirectX on Linux VMs on Windows?"

wmichelin 6y ago

This title is misleading, I saw it and got really excited that someday we may be able to game on Linux.

dang 6y ago
Title fixed now. Was "DirectX on Linux".
account42 6y ago
> got really excited that someday we may be able to game on Linux. Someday? You can already game on Linux.

nihil75 6y ago

So they WILL port DirectX to Linux, but only when it's running as a VM atop Windows. Typical..

greatgib 6y ago

I did post my comment in another thread, but this is seriously very very bad: "Windows could be required to use some Linux apps (Embrace, extend, extinguish)" -> https://news.ycombinator.com/item?id=23238790 https://news.ycombinator.com/item?id=23238790 The most important is to look at the following page to better understand the implications: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/ Here is how I would sum it up: * They create a new kernel file descriptor: /dev/dxg * With this, on the Linux of WSL, it is like a direct "pipe" to a Windows host graphical stack. * So it means that they can put code in Linux application code that will use Windows proprietary graphical stacks, like DirectX through /dev/dxg. * And so, clearly, this Linux app will not work inside a normal Linux computer that is not a "guest" of Windows. Now, you can see the "Embrace" and the "Extend"? And to well understand the article, the following things have to be stressed: This is not just something to render a Window or something like that, it is a special "passthrough" api to all the things that are provided by Windows GPU stack/drivers. For example, they give the example of Cuda compute API, but also, they kind of "built" DirectX sdk itself for Linux (debian, ubuntu, ...), but still the proprietary closed blob that "apps" are expected to use, but that will rely on /dev/dxg. Also, if you want to use anything OpenGL on the Linux WSL, they will ensure that it is translated to DX on Linux side, before going through the same special DirectX api. The good thing would probably have been to do the opposite side, ensure that Windows has the proper OpenGL support to be able to pass gpu acceleration to the Windows host.

m0zg 6y ago

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.

mappu 6y ago

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.

floatingatoll 6y ago

Blog post from Microsoft linked at the top of the LKML email: https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/

dang 6y ago
Changed to that from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!

wtallis 6y ago

I really wish Microsoft would just tell NVidia (and AMD) to support SR-IOV on all their GPUs. Then we wouldn't need any major software changes to enable CUDA acceleration within VMs, just a configuration change to pass through a virtual function of the GPU to make it available to existing drivers.

justaguy88 6y ago
I agree, this would dramatically simplify the situation
rossmohax 6y ago
AFAIK that's up to motherboard manufacturers. SR-IOV often doesn't work on desktops, I doubt there mass produced notbooks support it at all. MS can work with manufacturers, but they have their own incentives and it is unlikely to expect that all of them suddenly start doing a good job on this front. Meanwhile MS wants to cast widest possible net, so it needs to enable more and more workflows on WSL2 today, not tomorrow.
- wtallis 6y ago
  Other than enabling the IOMMU (which any system with Thunderbolt should have on by default), what does the motherboard firmware actually need to do for SR-IOV? I can't see any reason why it would need to be concerned with enumerating Virtual Functions or anything like that, but I don't actually have the SR-IOV spec on hand to dig through. EDIT: Looking through an old Intel whitepaper, it looks like the system firmware at most has to reserve some extra config space for SR-IOV devices when enumerating the PFs, so that the OS can enumerate VFs after creating them. But Linux includes an option to re-allocate this stuff if the BIOS doesn't reserve space, so this apparently isn't a hard requirement.
monocasa 6y ago
SR-IOV doesn't make sense on most GPUs, because they have their own MMUs already with different semantics. SR-IOV is terrible for dealing with a large bank of RAM on the target device, because the MMU is in the wrong part of the architecture. It's all the way on the root complex, so all GPU VRAM reads and writes would need to take the slow path through PCI-E and back. This is basically a nonstarter for GPUs that have their own VRAM. They also don't cover the GPU specific caching information that's normally stored in the GPU page tables either. Intel is able to get away with it for integrated GPUs because they can codesign their system level IO-MMU with the GPU MMU and it doesn't have it's own VRAM bank. I'd bet dollars to donuts that Intel's new Xe discrete GPU doesn't support SR-IOV even though the integrated versions of the same core will.

shmerl 6y ago

Not impressed, especially since it's still a blob. MS should stop fooling around and should start supporting Vulkan instead of pushing their DX lock-in and making hypocritical statements how they aren't on the wrong side of history anymore because they "support open source". The above feels like typical MS EEE.

Koshkin 6y ago

Twenty years ago Microsoft wanted to make Java “the best language for Windows programming.” Today, apparently, they want to make Windows “the best environment for running Linux.” (This time around they might even succeed.)

gmanley 6y ago

I found this reply to be especially interesting: https://lkml.org/lkml/2020/5/19/1309 https://lkml.org/lkml/2020/5/19/1309 > I also have another concern from a legal standpoint I'd rather not review the ioctl part of this. I'd probably request other DRI developers abstain as well. > This is a Windows kernel API being smashed into a Linux driver. I don't want to be tainted by knowledge of an API that I've no idea of the legal status of derived works. (it this all covered patent wise under OIN?) > I don't want to ever be accused of designing a Linux kernel API with illgotten D3DKMT knowledge, I feel tainting myself with knowledge of a proprietary API might cause derived work issues. This is the real scary part about software patents, and more specifically, patenting APIs. I'm not saying Microsoft is doing this in this case, but it could be a very real strategy by a bad actor. Attempt to taint open source software with your patented software and then litigate. In a dystopian future where patented software API lawsuits have become a common occurrence, I could imagine "clean room people". Individuals who can be guaranteed to not have been exposed to certain software designs.

dang 6y ago
(The originally submitted URL was https://lkml.org/lkml/2020/5/19/742. https://lkml.org/lkml/2020/5/19/742.)
_ph_ 6y ago
With looking at source, you have to distinguish between copyright (the license) and possible patent status. You should indeed be careful when looking at code with an unclear license, as this opens you up to claims of copyright violations. However with patents, the situation is different (which makes them so problematic). Patent violation is solely based on whether your code violates a patent or not. Having looked at other sources or not doesn't change anything about the possible violation. This is, what makes patents so nasty.
jfkebwjsbx 6y ago
On the other hand, if Microsoft themselves are publishing this code as open source, on the open, on one of the most important projects out there, and are actively asking other experts from other companies to review it, I would imagine they are weakening their arguments on the potential litigation.

dang 6y ago

We changed the url from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742, which points to this.

ngcc_hk 6y ago

Embrace - wsl 1/2 Extend - features you really open source to have and they fix it (running on laptop, apple do not do Nvidia) but try their best only run in their linux versus Extinguished - may the last one turn the light off, and thanks you for all the fishes

unnouinceput 6y ago

Ohhh, such a smart move. If there was any momentum of gaining developers on Linux for gaming this will crush it. Microsoft is eating Linux with a "loving" embrace.

wvenable 6y ago
I'm curious why you think this would make any difference to Linux gaming? If you want games to only run on Windows, they can just develop them for Windows. There's no need to put Linux in the middle.
- unnouinceput 6y ago
  Vulkan means cross-platform independent of OS. This is a move by Microsoft to lure any undecided/new game developers back to their walled garden. If you don't see this, let's talk in 10 years again - assuming Microsoft doesn't crap on it along the way.
  - hgoel 6y ago
    Being able to run dx12 in a virtualized environment that's still under Windows (and thus not actually changing anything vs just developing only for windows) is going to lure undecided game developers how?
    - unnouinceput 6y ago
      Say you're a game developer under Linux, OK? Then this comes along and you give it a try. This combined with all the great game engines that are pure Windows these days (see Unreal Engine 5 demo that was launched these days) and you now can target Linux using that. What do you do - continue with Vulkan or offer your game using this?
      - wvenable 6y ago
        You can't target Linux using that. I think you misunderstand what this is. It doesn't help nor hurt Vulkan or Linux development -- this only exists to "optimize" the Linux VM in Windows.

Sugaralmond 6y ago

i love jeff bezbos

dzonga 6y ago

EEE, slowly the Linux desktop | os environment will be a thing of the past. something you won't run directly but interact via the windows api. and your only other choice will be mac os on arm. the biggest mistake the linux ecosystem did, was being so fragmented. if they had rallied around one desktop env, then lots of people would've migrated. I personally use a t490 on ubuntu and a 2013 macbook. but even I I'm attempted to try out WSL even though, I haven't used windows in over a decade

rvz 6y ago
> the biggest mistake the linux ecosystem did, was being so fragmented. I'm not sure how many times I have pointed this out here, but given the lack of a standardized desktop environment, that is the reason why most software companies are reluctant to support Linux users. But in contrast with 'Android' in the mobile industry has succeeded in doing this with Linux as its kernel. For a typical or even a complex desktop app, I can support 100% of all Windows users, 100% of the time. macOS is more or less the same here. Linux distros however has this fragmentation running so deep that to target the majority of users there, you must supporting 5+ distros they could be running. That's 5+ CIs to maintain and 5+ troubleshooting guides to update here. As even Linus Torvalds would say: > 'I still wish we were better at having a standardize desktop that goes across all the distributions… It’s not a kernel issue. It’s more of a personal annoyance how the fragmentation of the different vendors have, I think, held the desktop back a bit. ' This is a distro ecosystem problem, not a 'kernel' issue.
- _ph_ 6y ago
  While he is right that it is not a "kernel" issue in the strict sense, I have to say it would have been beneficial, if Linus had used his influence to push more for a better desktop environment.

momokoko 6y ago

I see all the Microsoft team members are here in votes and comments as always. dang, this is not a fallacy with Microsoft. There are huge numbers of marketing employees in these threads

dang 6y ago
You're breaking the site guidelines with this comment. They ask you not to post allegations of astroturfing, etc., without evidence. Things appearing that you happen to dislike (from Microsoft or any other source) are not evidence of astroturfing, they're just evidence of a large community. If you think you're seeing abuse you should be contacting us at hn@ycombinator.com with links, so we can investigate. No more posting like this, please. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

hiram112 6y ago

I was a beta user of WSL1. It was interesting, but the very slow file system performance from Windows to Linux and vice versa was a deal breaker for development use. I haven't even bothered to use WSL2 because I hardly use Windows anymore, and I was forced to use VMWare with Linux on Windows for a few years of development work. It was always a pain, too, and once I switched to MacBook, I never looked back. Since then, I assumed WSL2 wasn't going to be used much by 'real developers' as it also had many of the same problems that plague VMWare and VirtualBox, which haven't been adopted by enough developers to pose a threat Linux native and Mac users. But I really feel MS is throwing a lot of resources into this. It's not just a quick fix for those users who need a command line but wouldn't ever consider Linux or Mac anyway, as I initially thought. And if this gets 'good enough' then imagine even more trouble for Linux and especially Mac's grip on engineers and scientists. Ubuntu, Redhat, and the rest have utterly failed to work with Dell or Lenovo or HP to concentrate on just one or two very well supported laptops - everything including suspend, battery life, ACPI, fonts, etc. It's a chicken and egg problem - workstations aren't profitable because most users won't put up with the hardware and driver problems. And without paying users, the distros ignore potential pro users to concentrate on enterprise. As for Mac, while I'm happy they've finally fixed the keyboard and allowed 32GB+ ram, that configuration looks absurdly expensive at $3500 compared to a similarly configured $1700 Dell Precision or Thinkpad. And MacOs has gotten worse over the years, not better. There is nothing really compelling me to stay except for it's Unix compatibility. WSL2 may eventually be the final nail in the coffin for a viable Linux Desktop, and Apple should be worried too, though they appear to have forgotten about pro users years ago anyway.

m01 6y ago
Dell have developer edition laptops that come with Ubuntu preinstalled and I saw a link on HN not long ago about Fedora coming to Lenovo laptops (I think it was https://fedoramagazine.org/coming-soon-fedora-on-lenovo-laptops/ https://fedoramagazine.org/coming-soon-fedora-on-lenovo-lapt...). I've not used them myself but I'd hope the situation isn't as dire as you describe, at least for those selected models.
- hiram112 6y ago

jaimex2 6y ago

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

kristopolous 6y ago

I also found the phrasing of this to be ambiguous. Windows (subsystem for Linux) has a Windows host running Linux Or (Windows subsystem) for Linux has Windows running on a Linux host They've been using this phrasing since the OS/2 and POSIX subsystem days and it was also confusing then Quarterdeck did it right with Desqview/X by just renaming their WIN16 subsystem as winx. Then you would see "desqview winx" and know that it's windows running on desqview and not the other way around. IBM also got it right: OS/2 Windows VDM. I know it's running on OS/2. But Microsoft has been running with this phrasing since literally Windows NT and it's always been confusing.

kgwxd 6y ago
Wasn't it originally something like "Linux Subsystem for Windows" and there was some legal problem with the word "Linux" being first?
- kristopolous 6y ago
  Apparently people have used the words swapped to mean the same thing. It's bad. Microsoft releasing something to run windows software on Linux, maybe for some exorbitant fee and only on say, the commercial versions of RHEL to undercut Wine progress, not only doesn't seem out of the question but also a reasonable defensive strategy and something I totally missed the announcement of. It's not like I'm a tech reporter, I go into my work for a couple weeks missing everything pretty often

adammunich 6y ago

How about sockets...

ComodoHacker 6y ago

>This is the real and full D3D12 API, no imitations, pretender or reimplementation But isn't Direct3D a COM API?

visarga 6y ago

The big news is Docker support for GPUs on Windows. You could train on GPU on Windows but you couldn't serve the model without Docker, as a business.

owaislone 6y ago

As far I understood the article, this does bring the DirectX API to Linux but in it's current shape it's only usable in WSL as the API implementation uses the virtual devices under the hood provided by WSL. Legal/licensing issue aside, how hard would it be to re-purpose this to make it available under something like Wine or even natively on Linux with real graphics devices? How much of this is till locked in on the Windows host side?

owaislone 6y ago

It seems Microsoft is getting closer to making Windows a fully Linux compatible OS. I wouldn't be surprised to see them get rid of virtualized distros running in WSL at some point and Windows natively becoming POSIX complaint.

lalaland1125 6y ago

It appears that Microsoft has now initiated the "Extend" phase of their classic Embrace, Extend, Extinguish playbook. The key is that the proprietary Microsoft specific API added by this patch is only usable in a WSL environment as it relies on many pieces of proprietary closed source software that Microsoft is unwilling to open source. This patch does nothing but fragment the Linux ecosystem and encourage people to develop software that only works in WSL environments. With the "benefit" of forcing the Linux kernel developers to pay the maintenance costs of course.

quietbritishjim 6y ago
According to the comment by christoph-heiss, this is just a paravirtualisation technique and will appear like a normal Limux GPU driver to applications running on WSL, rather than a special DirectX for Linux API that won't work on Linux itself.
- lalaland1125 6y ago
  I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The blog post and the thread on the kernel mailing list seem quite clear in that this is explicitly designed with the goal of exposing the Windows driver API and associated client APIs like DirectX. From the email introducing the set of patches: > The projection is accomplished by exposing the WDDM (Windows Display Driver Model) interface as a set of IOCTL. This allows APIs and user mode driver written against the WDDM GPU abstraction on Windows to be ported to run within a Linux environment. This enables the port of the D3D12 and DirectML APIs as well as their associated user mode driver to Linux.
  - monocasa 6y ago
    > I'm not sure where you are getting the idea that this would expose a normal Linux GPU API. The fact that they went through the effort of porting Mesa to get OpenGL and Open CL support, and are working on Vulkan support.
    - 6y ago

mikorym 6y ago

Maybe this question has an obvious answer, but will I still need to start my X Window System for graphics to display from my WSL terminal? My guess is that the answer is yes, but the type of applications that can be run is now extended? Conversely, I would expect this doesn't change anything with regards to SSHuttle, which would still not work on WSL.

mpfundstein 6y ago

even though I am quite successfully using pytorch under win (with conda), ... THIS IS EPIC. because now o can finally go full wsl and a pretty good excuse to switch to fast lane. i love wsl(2) and this is the icing on the cake.

dvfjsdhgfv 6y ago

I wish they did away with these heart symbols, professing their love for open source. Yes, we got that, Linux brings MS tons of money via Azure, but all this monkey show about love is plain disgusting, I can't imagine someone falling for that.

pojntfx 6y ago

WTF. Just use Vulkan like a normal person.

pojntfx 6y ago

EXTEND. M$ have not changed.

SXX 6y ago

I just hope David Airlie not going to merge it.

acd 6y ago

Windows will become an emulation layer in Linux when Microsoft is tired of maintaining Windows kernel/sees profit in running Windows apps native on Linux. SQL server is already ported.

rietta 6y ago

I remember starting to use and learn Visual J++ just to find out that if one wasn't really careful the code you wrote didn't run on other systems. If I was going to keep making a Windows only program, I preferred to stick with Visual Basic at the time. The real Java SDK was harder to learn for teenager me so I dropped it for a couple years until I started at Georgia Tech, which used Java extensively.

Grimm1 6y ago

Yeah, I don't buy the arguments here that Microsoft can extinguish Linux. Or would want to. Who's going to run Window's servers just to enable wsl? This is clearly targeted at developers coming back to windows on the PC, the aim is even stated as such to "enable IDEs" on wsl. I've ran arch, ubuntu and debian on my various systems, not because I want to but because they have the superior development environment in the terminal, outside of that Linux still feels janky and doesn't have any market share because of that. Microsoft is making something I've wanted for a while, I can get Linux off my desktop and laptop do my development and my game playing on Windows and ssh into my servers for any heavy lifting. This sounds like it will be a great win for devs.

prometheus76 6y ago

Nobody: Microsoft: Now you can use DirectX in the Windows Subsystem for Linux!

modmans2nd 6y ago

Step 1) Put a Linux Kernel on Windows as a separate subsystem Step 2) Port all APIs to this Kernel Step 3) Switch over to Linux as the main kernel and make the windows kernel a a Linux sub system to support legacy win32 apps. Step 4) Make all win32 support into a containerized system Microsoft moves to a Linux based system it offers for free and is only used for integration and support of it’s services.

prirun 6y ago

Here's the "new" Microsoft: https://news.ycombinator.com/item?id=23255591 https://news.ycombinator.com/item?id=23255591