DirectX is coming to the Windows Subsystem for Linux

Post by rymate1234 » Wed, May 20, 2020, 5:53 AM UTC

wvenable wrote: post #141

Avamander wrote: post #27

Earlier quoted context omitted.

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.

The thing with WSL is that it doesn't win back the ML segment from Linux to Windows for production workloads. This is just a developer workstation friendly move that explicitly doesn't tie you to Windows itself. It seems like Microsoft is continuing to see Linux as a production server target while positioning Windows to remain relevant as a workstation OS. Ostensibly, this is a move to compete with Mac OS and not Lin…

Post by cma » Wed, May 20, 2020, 6:00 AM UTC

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.

Post by visarga » Wed, May 20, 2020, 6:05 AM UTC

NOGDP wrote: post #179

bitcrazed wrote: post #172

Earlier quoted context omitted.

Hi. PM on Windows & WSL here. Imagine if you could run AI/ML apps and tools that are coded to take advantage of DirectML on Windows and/or atop DirectML via WSL. Now you can run the tools you want and need in whichever environment you like ... on any (capable) GPU you like: You don't have to buy a particular vendor's GPU to run your code. If you're old like me and remember the dark ol' days when games shipped with sp…

> If you're old like me and remember the dark ol' days when games shipped with specific drivers for (early) GPU cards/chips, but failed to run at all if you didn't have one of the supported cards, you'll understand why this is a big deal. Maybe I'm not that old, but I'm old enough to remember the days when microsoft was intentionally degrading opengl performance on windows ;).

Post by 0xcoffee » Wed, May 20, 2020, 6:06 AM UTC

stefan_ wrote: post #15

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 .

Post by atq2119 » Wed, May 20, 2020, 6:21 AM UTC

int_19h wrote: post #25

wmf wrote: post #17

Earlier quoted context omitted.

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

This isn't merely another API, though. It's the one against which most graphics drivers are written.