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

321–330 of 548 posts

Re: DirectX is coming to the Windows Subsystem for Linux

#321

Post by hgoel »

unnouinceput wrote: post #295
wvenable wrote: post #148

Earlier quoted context omitted.

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.

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.

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?

Re: DirectX is coming to the Windows Subsystem for Linux

#322

Post by welterde »

soraminazuki wrote: post #314
traverseda wrote: post #298

Earlier quoted context omitted.

I don't think we should have stuck with something like SysVinit, there's definitely room for improvement, but saying "it's either SysVinit or systemd" is a false dichotomy. If I was approaching building an init system I'd make a better language for writing init scripts than bash, some kind of interpreter that processes mostly declarative init files, sets things up, and then exits. An incremental improvement that work…

How can people replace SysVinit without "doing their own take on EEE"? Your alternative approach is still not going to be compatible with SysVinit either, not to mention it being strikingly similar to systemd.

Archlinux had their own non-sysvinit system (which went away in favor of systemd) as does voidlinux (runit based) and alpine (OpenRC) today.

The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard).

[1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

Re: DirectX is coming to the Windows Subsystem for Linux

#323

Post by soraminazuki »

golergka wrote: post #281
foxhill wrote: post #276

Earlier quoted context omitted.

i (and others) called this 3 years ago[1]. people need to stop using windows, entirely. i recently built a gaming machine, pretty high spec, and i've resolved to never install windows on it. there are plenty of games i can't play, a few that i would like to. but i wont give money to developers that wont release linux versions of their games - even when they are utilising engines that have linux ports (PUBG being the…

As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no. And regarding using Windows: company's behavior is important, but product quality, especially when it's a tool you use every day for work, is more important. 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 Windo…

> not a choice if you develop Windows software

A minor nitpick, but cross platform development is usually a painful work regardless of which platform you use.

Re: DirectX is coming to the Windows Subsystem for Linux

#324

Post by skohan »

m12k wrote: post #264
lalaland1125 wrote: post #213

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…

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…

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

So in other words, what you're saying is they are Embracing this FOSS linux-based developer workflow...

And you could almost say they're Extending the linux kernel to support DX12 on WSL...

Am I missing something?

Re: DirectX is coming to the Windows Subsystem for Linux

#325

Post by soraminazuki »

welterde wrote: post #322
soraminazuki wrote: post #314

Earlier quoted context omitted.

How can people replace SysVinit without "doing their own take on EEE"? Your alternative approach is still not going to be compatible with SysVinit either, not to mention it being strikingly similar to systemd.

Archlinux had their own non-sysvinit system (which went away in favor of systemd) as does voidlinux (runit based) and alpine (OpenRC) today. The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard). [1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

Is applications depending on systemd particularly a bad thing? If we don't want applications to use non-SysVinit features, we might as well keep using SysVinit.

Re: DirectX is coming to the Windows Subsystem for Linux

#326

Post by sailingparrot »

0-_-0 wrote: post #270
lawik wrote: post #235

Earlier quoted context omitted.

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

This is not the code of the extension, it's just documentation.

Re: DirectX is coming to the Windows Subsystem for Linux

#327

Post by chrsw »

monocasa wrote: post #189
vopi wrote: post #188

Earlier quoted context omitted.

Probably because its a shim to use a proprietary (only distributed by MS) binary blob version of DirectX compiled for Linux. Outside of ML utilizing DirectX in WSL on Windows, the only group that this helps is MS. FTR, I'm not arguing whether or not this should be upstreamed. I just see where the other poster could be coming from. I could be wrong on my take and if so, someone please correct me.

They also ported OpenCL and OpenGL to it via Mesa. Vulkan is in the works, and you can use CUDA if the host GPU supports it. Would y'all be so worked up about VMWare upstreaming their virtual GPU bridge?

Depends. If VMWare had the history Microsoft had one would be naive not to get "so worked up".

Re: DirectX is coming to the Windows Subsystem for Linux

#328

Post by carlosrg »

noderat wrote: post #65
christoph-heiss wrote: post #3

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…

No, if you read the blog post on Microsoft's site it goes into more detail: This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target. It offers the same level of functionality and performance (minus virtualization overhead).

That's the user space code. It still depends on the Windows drivers to do the work.

Re: DirectX is coming to the Windows Subsystem for Linux

#329

Post by simias »

AsyncAwait wrote: post #313
simias wrote: post #305

Earlier quoted context omitted.

This is a loaded way to frame the question, some of us were just fine being "stuck" with SysVinit. I try not to get dragged into systemd flamewars because life is too short but it's disingenuous to claim that before systemd init systems were some kind of inescapable hellscape. I administrate multiple systemd-based linux distros, FreeBSD servers and buildroot-based embedded systems and I can tell you that systemd stil…

> systemd still gets in my way regularly while the sh-based init systems tend to Just Work For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. They allow me to reliably monitor and restart services, they shut things down properly instead of just force killing as many init scripts end up doing. I instantly know how to manage most major distros now that systemd's com…

Arguing that the advantage of systemd is portability is rather bold!

And even if portability was the point I'm not sure I see the big deal. Writing an RC script from scratch if the software you use doesn't provide it is generally trivial. The vast majority of the time you wouldn't have to do that anyway as it ships with your OS's packages anyway. Sure, systemd might be "tidier" with its standard APIs and whatnot but it's also a lot more complicated and opaque than a bunch of shell scripts running one after an other. And if you're serious about sysadmin you'll have to learn shell scripting one day or the other anyway.

>Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic.

They're non-portable, that much is true but so is systemd, that's a weak argument. If everybody had adopted FreeBSD-style init it would be equally as portable, it's a self-fulfilling prophecy. With that logic we should just all ditch un*x and start running Windows since most people already use that anyway.

The rest is nonsense. It's poor quality, non-consistent and non-deterministic if you write them that way. Sure, shell scripts being turing-complete opens the door to a lot of nonsense if people go wild and gives more latitude for very sloppy code but it doesn't have to be that way.

>the people who sit down and actually write the code we all use find the services systemd provides valuable

Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. I'm sure many of them use it because that's what's available. I wrote a bunch of systemd unit files myself, I assure you that it wasn't meant as an endorsement.

Besides it's only one side of the equation. Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them. I'm sure many software maintainers would prefer if everybody ran the same OS on the same hardware with the same use cases but that's not how the real world works.

Re: DirectX is coming to the Windows Subsystem for Linux

#330

Post by coldpie »

franga2000 wrote: post #306
golergka wrote: post #281

Earlier quoted context omitted.

As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no. And regarding using Windows: company's behavior is important, but product quality, especially when it's a tool you use every day for work, is more important. 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 Windo…

> As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no. What are the main costs of releasing a Linux version of a game when using Unity or Unreal? My limited experience with Unity has been "check the Linux box, click the build button". It even cross-compiles no problem. People I know tell me Unreal is similar. It's not like they have to do a full run of play-te…

I can tell you've never released a popular product on Linux. It's a lottttt more effort than you're implying. To do it well, you need to have Linux as a target from the start of your development, it's not something you can tack on to the end. Linux graphics drivers are very different from Windows (the AMD stack isn't even the same codebase). Linux window managers are... wild. You need to build to an ABI that will be supported across distros, which mostly means the Steam Runtime, which means you need to go learn about and understand that. You can't introduce any platform assumptions ("ehh, I'll just hardcode this path with a backslash... oops"). Once you release, you're talking support for dozens of different distros, different versions of distros, different package managers, different filesystems. I know what you're going to say: "Just support Ubuntu LTS and ignore everyone else". Well, now you've just cut your customer base by at least 75%[1], and your customers on other distros are going to demand support anyway. Do you tell a paying customer to F-off because they're not using a distro with only ~20% of the market?

Supporting Linux is hard. So is supporting Windows, but if Windows makes up 98% of your customer base, it's justified. 2%? Ehhhhh.

(P.S. I love Linux. See my profile. This is the kind of stuff I deal with every single day.)

[1] https://boilingsteam.com/we-dont-game-on-the-same-distros-no...

Post reply on HN