Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DirectX is coming to the Windows Subsystem for Linux

devblogs.microsoft.com

Post reply on HN
Print view View original

161–170 of 548 posts

Re: DirectX is coming to the Windows Subsystem for Linux

#161

Post by kristopolous »

wmf wrote: post #6

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

That's not the point. They are trying to not IBM themselves.

They and the clones won the war with IBM in the 80s and 90s because IBM was worried about things that didn't matter: they wasted time with things like an operating system CP/X86 that ran DOS and 3270 emulators to their mainframes on top of a GUI system called mermaid (3270 PC) while Microsoft was writing Windows 3. Oh yeah did I mention some configurations cost $20,000 each? some configurations cost $20,000 each.

Because IBM wanted to secure its AS/400 minicomputers, mainframe, and microcomputer line and make them interoperable, as if a PC user sitting in their den would be connecting with $500,000 or so of other IBM machines, everyone else ran circles around IBM. They kept up the "whole kitchen sink" system way way past its due date.

This also happened to DEC, which responded way too late in the game to be relevant, SUN, SGI, and Wang. And it may eventually take down Oracle.

So they're intentionally taking an uncommitted, decoupled approach. I'm paying Microsoft as a result. I pay GitHub and Azure bills every month and run exclusively Linux.

They can't sway around as a monopoly like they could in 2000, once Ballmer left things changed rapidly. It's not going back. They have effectively zero cloud software (database/operating system etc), effectively zero mobile presence, and most people don't really like Windows.

In a tightly coupled stack you're only as strong as your weakest link, and MS has a bunch. Their biggest risk now is to HP or GM themselves; basically gobble up a bunch of things, blend it into indifferentiable blandness and collapse while waving a giant sceptre labelled "greatest company of 30 years ago" (HP bought DEC, Cray, Tandem, Apollo, Convex, 3Com, Phoenix, Palm and SGI and did effectively nothing with them beyond slapping an HP logo on their final pre acquisition product line and then just rode it out without any followup. HP knowing only how to fumble the ball every time for 20 years is why big business switched to Linux. HP took all the alternatives behind the barn one by one, cut them a fat check and then shot them. Simply crazy)

So yeah, it's a different game now.

Re: DirectX is coming to the Windows Subsystem for Linux

#163

Post by navanchauhan »

discordance wrote: post #136
_vbdg wrote: post #2

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

Ah that sucks, for a moment I thought I would be able to run Wine from within WSL2 and get my game on.

if you are already running Windows and using Linux through WSL, why would you want to use WINE to run games?

Re: DirectX is coming to the Windows Subsystem for Linux

#164

Post by ldng »

kelnos wrote: post #96
Wowfunhappy wrote: post #85

Earlier quoted context omitted.

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

If you read the replies by Dave Airlie and Daniel Vetter, it seems somewhat likely that upstream won't accept it. Perhaps that's just initial skepticism that will evaporate after more discussion, but perhaps not. Frankly this does just seem like MS wanting to reduce their maintenance burden on what they expect will be a very important part of their WSL offering on Windows. There's nothing inherently wrong with that d…

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

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

Re: DirectX is coming to the Windows Subsystem for Linux

#165

Post by teleforce »

lostmsu wrote: post #146
deadbunny wrote: post #70

Earlier quoted context omitted.

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

To be honest I don't quite understand what stopped those developers from running machine learning on their GPUs under Windows itself. Most frameworks work just fine. I've been doing quite a lot of TensorFlow with both Python and .NET. The only time I faced the need for Linux box is trying a demo project from OpenAI, which did not use the features it required Linux for on a single machine anyway.

This mainly to woo developers who are now working on Mac OS or thinking to use Mac OS to use Windows and WSL combination instead for ML & AI application development.

Re: DirectX is coming to the Windows Subsystem for Linux

#166

Post by lostmsu »

rezonant wrote: post #158
lostmsu wrote: post #146

Earlier quoted context omitted.

To be honest I don't quite understand what stopped those developers from running machine learning on their GPUs under Windows itself. Most frameworks work just fine. I've been doing quite a lot of TensorFlow with both Python and .NET. The only time I faced the need for Linux box is trying a demo project from OpenAI, which did not use the features it required Linux for on a single machine anyway.

I believe the purpose is for devs who are deploying to Linux, their toolchain may not fully work in Windows, but they want to have a similar dev/test env within Windows... pretty much the whole point of Windows Subsystem for Linux (WSL). It's not that the frameworks don't work on Windows, it's the deployment tech, like Docker, Ansible, their build scripts etc etc. Some users may be doing something totally custom on t…

Do people actually use Docker and Ansible a lot for ML???

Doing something custom on top of the GPU is also not much different on Windows, than Linux. CUDA is basically the same. OpenCL and Vulkan are available too.

I'd like to hear perspective of a person, who actually does ML specifically on Linux for some reason.

Re: DirectX is coming to the Windows Subsystem for Linux

#167

Post by raphlinus »

lostmsu wrote: post #147
anaisbetts wrote: post #62

Earlier quoted context omitted.

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

> special build of Tensorflow that uses DirectX Huh? Are you sure about that? Regular TensorFlow on Windows uses CUDA, not DirectX-flavored compute.

I was also surprised, but found this RFC for TensorFlow on top of DirectML: https://github.com/tensorflow/community/pull/243

Re: DirectX is coming to the Windows Subsystem for Linux

#168

Post by hetspookjee »

lostmsu wrote: post #146
deadbunny wrote: post #70

Earlier quoted context omitted.

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

To be honest I don't quite understand what stopped those developers from running machine learning on their GPUs under Windows itself. Most frameworks work just fine. I've been doing quite a lot of TensorFlow with both Python and .NET. The only time I faced the need for Linux box is trying a demo project from OpenAI, which did not use the features it required Linux for on a single machine anyway.

My experience with GPU accelerated development is quite horrible on Windows for anything other than the NVIDIA prepped docker container. There was always something missing or some drover was incompatible. In the long run I have always regretted developping Python on Windows, also often because whatever was developped was to be deployed on a Linux box.

I do not think it's purely windows to blame here though. It's only quite recently that NVIDIA started fixing their documentation and instructions on getting all the right CUDA CuDNN stuff running properly on a system.

Re: DirectX is coming to the Windows Subsystem for Linux

#169

Post by rezonant »

lucasyvas wrote: post #145
me551ah wrote: post #135

Earlier quoted context omitted.

>>>There's also the question of whether or not you believe WSL as a whole is good or bad for Linux. IMO it's a good thing. Given that windows accounts for 90%+ of the desktop OS share, Windows might very well become the world's most used Linux distro.

It is, of course, decidedly not a Linux distro though. If it was, it wouldn't be an issue. I think there are positives, but it looks a lot like "Extend" to me. I can't even say I wouldn't use it - it might be nice! But I will not use any WSL-only capability, that's for sure.

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

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

Re: DirectX is coming to the Windows Subsystem for Linux

#170

Post by hetspookjee »

lostmsu wrote: post #166
rezonant wrote: post #158

Earlier quoted context omitted.

I believe the purpose is for devs who are deploying to Linux, their toolchain may not fully work in Windows, but they want to have a similar dev/test env within Windows... pretty much the whole point of Windows Subsystem for Linux (WSL). It's not that the frameworks don't work on Windows, it's the deployment tech, like Docker, Ansible, their build scripts etc etc. Some users may be doing something totally custom on t…

Do people actually use Docker and Ansible a lot for ML??? Doing something custom on top of the GPU is also not much different on Windows, than Linux. CUDA is basically the same. OpenCL and Vulkan are available too. I'd like to hear perspective of a person, who actually does ML specifically on Linux for some reason.

Well CUDA is only one thing. Especially in the python environment it's only a matter for time before you run in some wierd dependency issue that is Windows only. For example, getting XGBoost completely up and running on Windows requires you to either build it yourself or download a .dll from a university link. Installing it on Linux is just a proper pip install.

Also windows not having a build in C compiler makes you dependent on the horribly convoluted Visual Basic stack that seems to have a lot of dependencies for some python ML libraries. Docker makes it a lot better to run and I almost always deploy in a docker container because the ML modules I deliver are often interacted with as a black box with a REST API on top.

Post reply on HN