DirectX is coming to the Windows Subsystem for Linux • Hacker News Board

Re: DirectX is coming to the Windows Subsystem for Linux

#441

Post by munchbunny » Wed, May 20, 2020, 3:47 PM UTC

traverseda wrote: post #414

AnIdiotOnTheNet wrote: post #410

Earlier quoted context omitted.

No, it just isn't getting better. Any time you want to do something even remotely interesting, like install software that is actually up to date and therefore not in the repo, you have to jump through a bunch of hoops. One of my other usecases involved a device with only a 16GB internal disk, so naturally I would like to install applications to an external disk so they actually fit. This is usually trivial on Windows…

Hmm, that's fair. I'd encourage you to try something outside of the standard redhat/ubuntu distros. Manjaro is nice and is pretty much always up to date. Also has access to the AUR, so there are packages for pretty much everything. It's a lot easier to do interesting stuff. LVM can make two disks appear like they're one, but of course if you remove any of them they both fail. Doesn't really solve the underlying "I wa…

I think that sums up my issues with desktop Linux: any user has at least some niche requirements. For mine they are fairly doable on MacOS/Windows, but they require hours of staring at documentation and downloading/compiling source code in Linux.

I still write code in a Linux environment because that's where the ecosystem is, but for my daily driver I've given up on desktop Linux. And I've found that WSL gets me a Linux based development environment side by side with Windows with less pain than dual booting. I've found that when it comes to using Linux smoothly, it's a lot easier to shoehorn myself into the happy paths than to bend my setup into my way of doing things.

Re: DirectX is coming to the Windows Subsystem for Linux

#442

Post by computerex » Wed, May 20, 2020, 3:49 PM UTC

AnIdiotOnTheNet wrote: post #388

computerex wrote: post #350

Earlier quoted context omitted.

> Linux is ok for certain types of developers, it's still awful for normal users, abysmal for office work and obviously not a choice if you develop Windows software. Don't want to get into an OS war here but merely stating your opinion as fact without supportive evidence is not in the spirit of HackerNews. > it's still awful for normal users, abysmal for office work For office work a lot of workload has moved to the…

> Don't want to get into an OS war here but merely stating your opinion as fact without supportive evidence is not in the spirit of HackerNews. These things are pretty much self evident. > Linux is ok for certain types of developers Web developers and HP computing. Game developers? Haha, no. Embedded? Too many proprietary toolchains that don't run on Linux. Productivity and business applications? See below section on…

> Embedded? Too many proprietary toolchains that don't run on Linux.

It's funny/surprising that you'd say that, given that Linux is the single most dominant OS in the embedded device space. What toolchains are you referring to? Here are some well known ones.

https://www.yoctoproject.org/ https://www.ptxdist.org/ https://openwrt.org/

> ML? nVidia [apparently I'm incorrect on this one].

Not only are you wrong about CUDA, but Google's custom built chip designed for ML runs soley on Linux: https://en.wikipedia.org/wiki/Tensor_processing_unit

ML almost exclusively runs on Linux.

> and it is only supported on Windows

Office also runs on macOS. You can also run Office in Linux using WINE.

> Alright, this is a bit subjective, but is supported by the stats that show Linux Desktop still in a distant and well deserved third place. You list a few tasks that you seem to believe are "normal user" tasks, I submit to you that you drastically underestimate the things a normal desktop computer user does with their computer, since most of the tasks you listed are now things that people do on phones and tablets.

It's really easy to say anything without providing any supportive evidence to substantiate your claims. Pray tell what tasks you are referring to that "normal users" partake that supposedly can't be done in desktop linux.

Re: DirectX is coming to the Windows Subsystem for Linux

#443

Post by jamesgeck0 » Wed, May 20, 2020, 3:52 PM UTC

Zardoz84 wrote: post #190

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

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.

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.

Re: DirectX is coming to the Windows Subsystem for Linux

#444

Post by AsyncAwait » Wed, May 20, 2020, 3:56 PM UTC

traverseda wrote: post #417

Valmar wrote: post #404

Earlier quoted context omitted.

It's part of the systemd project umbrella? It's part of the systemd monorepo? It uses libsystemd? Maybe it's simply easier to maintain this way? elogind exists, if you care. It exposes the DBus interfaces that logind supports for applications to call. Thus, environments like Gnome can be supported on non-systemd systems if they emulate and/or expose and implement the required DBus interfaces.

That's sort of the complaint, why I accused them of "doing their own weird version of EEE". When faced with a choice of "make everybody else do a whole bunch of work so that they're not forced to use your entire project-umbrella" or "make some minor changes to our architecture so things aren't as tightly coupled" they almost always choose the one that forces you to use systemd.

logind has a stable API, it is possible to build alternative implementations not coupled to systemd, yet so far I don't see much on that front.

Re: DirectX is coming to the Windows Subsystem for Linux

#445

Post by toxik » Wed, May 20, 2020, 3:56 PM UTC

jfkebwjsbx wrote: post #343

m12k wrote: post #264

Earlier quoted context omitted.

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

> 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, Perhaps in some countries, definitely not everywhere. At my university, there is only a single Mac across 40 or so laptops. > because it compiles iOS apps I doubt students buy Macs for that. iPhones are not nearly as popular outside the US. > and it's a *nix Students don’t care about its UNIX certificatio…

What is this, an attempt at gaslighting? Macs are really common in university settings, I won't bother discussing why here, but it is undeniably so in much of the western world.

Re: DirectX is coming to the Windows Subsystem for Linux

#446

Post by cycloptic » Wed, May 20, 2020, 3:57 PM UTC

AnIdiotOnTheNet wrote: post #433

cycloptic wrote: post #430

Earlier quoted context omitted.

I'm not making a case for shipping on the "Linux desktop" because that doesn't exist and has never been a real platform. Most smaller distros are not trying to be "relevant" to whatever the gaming community's fad of the day is. They're perfectly fine filling what niche they do. If you want to target those smaller distros as a platform, you can give them some source code to work with, or you can pay all the cost of ma…

So what are you saying? Developers should just choose a major distro and target that, then get all the flack for issues their product has on every distro that isn't supported? Because that's basically what's already happening and developers hate it, which is why they often don't ship on Linux at all. And many proprietary pieces of software license components from other proprietary pieces of software, so that even if…

In general, distro maintaners can't help you with legal conundrums you created for yourself (you signed restrictive NDAs and proprietary license agreements and didn't consider the fine print until it was too late) or with other unrelated market problems (lack of popularity, lack of developer interest in supporting your game).

If you need to strip out some parts and there is enough will in the community to replace those pieces that you stripped out, then it will happen. If you have a product that is anywhere near being popular among the FOSS developer communities then I don't think it makes sense for you to claim that this will doesn't exist, or that distro maintainers will lose interest.

Re: DirectX is coming to the Windows Subsystem for Linux

#447

Post by monocasa » Wed, May 20, 2020, 3:58 PM UTC

codys wrote: post #434

monocasa wrote: post #359

Earlier quoted context omitted.

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

The standard for Linux gpu access is the dri/drm kernel interface, not the new wsl specific api they've added. Their porting Mesa to use a proprietary library that interacts with the wsl only kernel interface isn't that same as behaving like a standard Linux gpu

It's not really a standard though, each GPU has a totally different set of ioctls and device files to the point that you can't write against a generic kernel interface either way. AFAIK, the only DRI/DRM interface with two used clients is amdgpu (of which one of the clients is proprietary).

And part of the discussion on the mailing list is how to integrate this with DRI/DRM and dma-buf so it can be used by more Linux clients with less work (although still non zero like you'd have on a DRI scheme as well).

Re: DirectX is coming to the Windows Subsystem for Linux

#448

Post by AshleyGrant » Wed, May 20, 2020, 4:00 PM UTC

NeverFade wrote: post #372

halbritt wrote: post #357

Earlier quoted context omitted.

> As the other comment explained, they are still a huge gorilla in spaces that are absolutely vital to Linux: server, desktop, and laptop. No reasonable person at Microsoft considers Linux to be a threat on the desktop/laptop. No reasonable person at Microsoft considers Windows Server to be a threat to Linux on the server.

Microsoft holds a large and fast-growing share of the enterprise server market with products like Office365, Exchange, and Sharepoint.

O365 is SaaS. Customers that are hosting Exchange on-prem are being encouraged to move to O365 for email. Same for SharePoint. If I had to guess, O365 is helping to reduce, not grow, the market share of Windows server.

Re: DirectX is coming to the Windows Subsystem for Linux

#449

Post by wvenable » Wed, May 20, 2020, 4:01 PM UTC

rymate1234 wrote: post #191

wvenable wrote: post #141

Earlier quoted context omitted.

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…

I'm not too sure about that, what about the support for DX12 in WSL? Can't deploy that to production outside WSL right now as far as I'm aware, unless they add DX12 support to azure Linux vms...

> I'm not too sure about that, what about the support for DX12 in WSL?

It's an implementation detail -- they're exposing the Windows graphics driver to the Linux system with the most minimal amount of translation and overhead.

You could code directly to it in your Linux application code but it makes no sense to do that. You'd be literally writing a Linux application that can only run under Windows -- the smallest market ever proposed. Instead library/framework developers will add it as another target to improve performance in WSL for generic Linux applications.

Re: DirectX is coming to the Windows Subsystem for Linux

#450

Post by munchbunny » Wed, May 20, 2020, 4:02 PM UTC

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.

If your dev or production stack is Linux based, I think it makes sense to try to bring the GPU to your dev stack instead of the other way around. If you're working with other devs who are on actual Linux stacks, it'd be a pain in the ass to always require for there to be hybrid Windows/Linux tooling.