I just hope David Airlie not going to merge it.
DirectX is coming to the Windows Subsystem for Linux
261–270 of 548 posts
Re: DirectX is coming to the Windows Subsystem for Linux
#262Earlier quoted context omitted.
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…
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…
>Now you can run the tools you want and need in whichever environment you like
Isn't the linked post saying you have to be running on Windows though? It seems like it would make way more sense to either port directX to Linux, or ditch directX and put those resources into supporting Vulcan.
Re: DirectX is coming to the Windows Subsystem for Linux
#263Earlier quoted context omitted.
It's exactly what Wine wants to be. Sadly that's not quite the same thing.
What do you mean? Wine has a different architecture because distributing microsoft binaries is not legal, so technically it's not the same thing, but it still does an amazing job and a lot of apps/games works flawlessly.
It does an amazing job, but a lot of apps and games do not work flawlessly. Or didn't, last time I tried Wine. Maybe this situation has changed a lot since then, which would be awesome.
Re: DirectX is coming to the Windows Subsystem for Linux
#264It 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…
Look, I'm not saying saying we should "trust" Microsoft not to Embrace, Extend, Extinguish if they could - but they can't and they know it, so that's not their strategy. EEE was hinged entirely on the dominance of Windows and IE for the Extinguish phase. They won on desktop, but today most of the action has moved to mobile (where Windows lost completely to iOS and Android) and webservers (where Linux is massively dominant). In those domains, they are no longer the 500 pound gorilla in the room, they're the "hey, fellow kids" oldtimer trying to fit in and get in on a piece of the action. Look at a comp sci class in the last decade, and you'll see 1/2-2/3rds of them with MacBook Pros in their laps, because it compiles iOS apps and it's a *nix so it easily runs most of the same tools as a linux webserver. That's what WSL is about, trying to win back developers. That's why they bought Xamarin and Github. That's why they released VS Code. They're trying to win back developers by meeting them whereever they are, even if they know they are targeting platforms where Microsoft is not dominant and has no hope of becoming so. They're trying to make it feasible to target a linux webserver while developing on Windows. They're trying to make Azure a serious contender for cloud computing outside of the corporate C# world. There's not a realistic scenario where they become dominant enough on those platforms to execute any kind of Extinguish move. And they don't need to - there's still tons of money to be made with just a slice of the cloud pie. I think EEE went out the window along with Balmer and the 'Windows First' doctrine. I'm not saying they wouldn't, but I'm saying they can't and they know it, and they're ok with that.
All this is not to say that there's any reason for upstream to accept any bad patches that rely too much on proprietary code. But in this case, I think the analysis of the underlying motivations for that patch was outdated.
Re: DirectX is coming to the Windows Subsystem for Linux
#265Earlier 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 ;).
This. Some games would have a handful of different renderers for different setups, while other games would only support one specific card type (and if you were lucky, a software renderer).
Those days sucked. Bigtime. If we can avoid doing the same mistakes for machine learning then we should.
Re: DirectX is coming to the Windows Subsystem for Linux
#266Earlier quoted context omitted.
What do you mean? Wine has a different architecture because distributing microsoft binaries is not legal, so technically it's not the same thing, but it still does an amazing job and a lot of apps/games works flawlessly.
It does an amazing job, but a lot of apps and games do not work flawlessly. Or didn't, last time I tried Wine. Maybe this situation has changed a lot since then, which would be awesome.
Every single versions has a lot of improvements, esp regarding compatibility. I suggest giving it a try once again.
Re: DirectX is coming to the Windows Subsystem for Linux
#267Earlier 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.
But Windows is a painful OS to use for anything other than gaming. Ideally, I'd like to see the exact opposite of this: run Linux with a Windows subsystem just for gaming.
You can do that today with Qemu and PCI-passthrough. You just boot a VM, and pass it a physical grapics card.
Check out https://old.reddit.com/r/VFIO/
I guess this will be the standard until we can have nicer graphics drivers for Linux.
Re: DirectX is coming to the Windows Subsystem for Linux
#268Earlier 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.
But Windows is a painful OS to use for anything other than gaming. Ideally, I'd like to see the exact opposite of this: run Linux with a Windows subsystem just for gaming.
Wine / Steam's Proton does a decent job, and some older games even work better with Wine than with Windows 10.
If you have a spare GPU, a VM with PCI passthrough does an even better job, except for some anti-cheat software that artificially discriminates against this setup.
In theory it ought to be possible to switch a single GPU to/from a VM without a reboot. In practice I have no idea how huge a refactoring to the Linux graphics stack that'd require.
Re: DirectX is coming to the Windows Subsystem for Linux
#269I remember when DirectX was a huge obstacle to porting games to Linux. This feels like a great, great victory for Linux to me!
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 usin…
I use a Linux desktop because it's reliable, fast and don't call home to M$ with "telemetry" data about my every key stroke.
Running Windows has never been an option for me, since Microsoft went down the "activating Windows" path many, many years ago.
Re: DirectX is coming to the Windows Subsystem for Linux
#270It 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…
I find this a cynical take as far as EEE goes. But even with Microsofts mostly solid efforts into open source I find myself a bit skeptical as well. Most recently with the Live Share extension for VS Code. From skimming the licensing it is only to be used with the Visual Studio family of products. Which is an incredibly disappointing approach. I think this is simply about ML and GPU compute for WSL. And I think Micro…
The license of Live Share as appears among VScode plugins indeed says "You may use the software only with Microsoft Visual Studio or Visual Studio Code", but the license of the source code of the extension on Github is an MIT license:
https://github.com/MicrosoftDocs/live-share/blob/master/LICE...