Hacker News Reader

Comment by chaorace | Hacker News Reader

Proton has been fantastic for me, it finally gave me what I needed to reclaim my Windows partition and go full-on Arch! In some cases, running the Windows version inside Proton has actually worked out better for me than the native port (Dead Cells, for example. The native port crashes the Steam overlay and lacks Steam Controller support, but running the Windows version in Proton is seamless)

I highly encourage you guys to check out the tech making this possible: DXVK. It's incredible what you can do with these lower level APIs. I'm not sure if this is the right word, but "meta shader pipelines" like this are absolutely the way of the future in emulation. See also: Dolphin Ubershaders.

Ubershaders: https://dolphin-emu.org/blog/2017/07/30/ubershaders/

View on HN

DXVK also works on Windows, to translate DX11 calls to Vulkan and pipe them thru the graphics card's own Vulkan driver.

Video here: https://www.youtube.com/watch?v=FVYprONeDtY

> In some cases, running the Windows version inside Proton has actually worked out better for me than the native port

I, for one, am not surprised. Windows userland APIs are more stable, consistent, and well documented than their Linux equivalents.

Keep in mind most "native" ports are just crappy, but official, wrappers that just do what proton does but worse. This is why you will see a lot of native ports perform worse, they weren't really native in the first place.

I'm gonna blow your mind: the word "native" doesn't actually mean anything in this context. The only thing that matters is official support from the developer, regardless of the technology used.

I was explaining how an official port could perform worse than an unofficial one, so yes "native" would absolutely mean something in this context. It's commonly understood that using the native system interfaces would usually be faster than using a compatibility layer.

> The only thing that matters is official support from the developer, regardless of the technology used.

The only thing that matters for what? I'm not sure what point you are trying to make.

It's supposed to mean no system call translation but alas, you're right, it usually doesn't.

The implication from the comment was that Wine is better at running old Windows games than Windows itself. I’m not sure where this Linux vs. Windows comparison is coming from.

No, you mis-read. chaorace said that Windows EXEs running in Proton gives them better results than running the Linux binary that the game developer ships ("native"). AnIdiotOnTheNet stated that Windows APIs are more stable and better documented than Linux APIs.

As a long-time Linux dev (see my profile), I have also found this to be true. Linux userland APIs are unstable and change all the time. Some transitions that come to mind that have affected me personally: ALSA->pulse; libudev->libudev2->systemd; gstreamer 0.10->1.0. All of those changes required modifications to my software, and the backwards-compat tools that are provided are buggy and insufficient. Meanwhile, you can still write and run winmm[1] applications on Windows 10, and they will work in almost all cases. It's simply the case that the win32 API is more stable than Linux userland APIs, so it's entirely plausible that games will run better in Wine, which shares that stable ABI, than they will on Linux, especially as time goes on and Linux userland shifts yet again.

[1] winmm dates to the Windows 3.x days!

The audio subsystem changes definitely could have been done better. Ideally /dev/dsp should have been extended like has been done on the BSDs instead of inventing completely new interfaces. That said, doesn't libasound still work with pulse?
gstreamer on the other hand is something you can just as easily ship yourself. I wouldn't consider that a Linux userland API as much as a random library that is present on many Linux system just like some crap you'd find in system32.

I'm less familiar about the API/ABI changes in the libudev transition - is there anything there that broke API compatibility.

The "lower level" userland libraries (glibc, libGL, libX11) tend to be pretty good at maintaining backwards compat. Well, except for Mesa pulling in the C++ standard library which can be a real problem when older games also dynamically link (incompatible) versions.

For software like games, all that pain is abstracted away by SDL. No need to deal with userspace libraries!

And, of course, the syscall layer is stable in Linux, so no issues there either.

However, companies claim Linux is still a pain for other reasons, so I guess it is mostly about testing/support cost and perhaps OpenGL driver issues?

I've been suspicious of user-led development (e.g. open source), expecially Linux. Its popular to put in new features; less so to test, endure backward compatibility, control user experience. So it doesn't get done (much) in Linux.

My cohort have a phrase they attribute to me: Linux is not ready until they get the 'Have Disk' dialog.

Eh, I don't agree. Linux has been "ready" for my usecase for more than a decade. There's pros and cons to each certainly, but I find Linux much more pleasant to use than Windows, and I like actually being in control of and able to modify the software I run. Until I can do that, Windows is not ready for me :)

Right. But the point is the vast, vast (non-HNer) use case is not in favor of Linux. For every 1 Linux-on-the-desktop person, there are what, 1M others?

I hope that I never see the "Have disk" button again. The Linux way of distributing hardware drivers is so much easier.

As for usage, linux on the desktop is between .5% and 2% market share. And there reason to suspect that Linux usage is undercounted.

https://www.netmarketshare.com/operating-system-market-share...

https://store.steampowered.com/hwsurvey/

https://www.statista.com/statistics/268237/global-market-sha...

https://hostingtribunal.com/blog/operating-systems-market-sh...

> The Linux way of distributing hardware drivers is so much easier.

You mean having to recompile them whenever there's a new kernel because the developers consider a stable driver ABI to be abhorrent?

I don't think I've ever compiled a driver. So no, I don't think that's what they meant.

Only because the disto does it for you. If they mean because the driver is distributed from a centralized repository over the internet... that's how it works in Windows too, only Windows also has the option to use alternate media and a stable enough driver ABI to have that make some kind of sense.

I don't know if API stability is a barrier to adoption or not, but I was just explaining my experience with both platforms. For me, I don't much care how many people use Linux; I just want to use my computer how I like to, and Linux suits my needs best.

What dialog is that?

Perhaps this one?

https://www.dell.com/support/article/en-us/sln286269/how-to-...

About a third of the way down.

I don't believe that is correct.

> (Dead Cells, for example. The native port crashes the Steam overlay and lacks Steam Controller support, but running the Windows version in Proton is seamless)

Suggests the comment is about running the Windows version under Proton being a better experience than running the native Linux version.

Both are correct. Some native ports run better under Proton because the port sucks, but I recently saw a video where they compared Doom Eternal with Proton vs running native on Windows, and the Proton version ran better than the Windows version running natively.

https://www.youtube.com/watch?v=h-XnlUMfkjM

It would be interesting to have some analysis digging into potential causes for this result. As someone who was recently surprised at how much impact a CPU upgrade (G3258 -> 4570 on the same LGA 1150 motherboard [1]) had on overall performance even in older indie titles where I wouldn't have expected it to matter much, I would be curious to look at what background services are running, what their cpu/memory footprint is, and how well the OS handles scheduling them.

Even without the obvious pigs like virus scanner, printer utility, launchers for other storefronts, various chrome-embeds like Slack and Spotify, I wouldn't be surprised if the Linux desktop does a better job of this.

[1]: https://cpu.userbenchmark.com/Compare/Intel-Pentium-G3258-vs...

The most common theory is that it's the Denuvo anti-piracy software. It's known to cause performance drops on Windows, and it often has to be bypassed or disabled in Linux games.

I see now. I stand corrected.

Ah, the parent comment is actually correct here. Dead Cells is a modern release with a released Linux port. Unfortunately, it isn't interacting correctly with the Steam overlay API and the issues haven't been fixed for months. Running the Windows version via Proton, ironically, is a more stable experience for my use-case.

Ditto here. My wife's PC, for example, is now running OpenSUSE full time. She used to dual boot with Windows 10, primarily for games, but she would spend most of her computing time using Windows just because of the game inconvenience. Now pretty much everything she plays 'just works' with Proton, and she has no need for Windows.

Thanks for the Ubershaders link it's very interesting, I had not heard of it despite being a casual Dolphin user!

I wasted a lot of time with DXVK when I tried to play Tomb Raider 4.

WineHQ said you need DXVK when you want proper shadowing, but I could not get it to work.

Finally, it turned out my laptop is probably too old for DXVK (i7-4600U).

But Wine 5 can run the game without DXVK. I just needed to install it from outside the distro repo, since the distro only had wine 4

Well yeah, the VK in DXVK stands for Vulkan.

Also Tomb Raider 4 uses DirectX 7 which is not supported by DXVK so you'd need to combine it with dgVoodoo2 [0] to translate DX7 -dgVoodoo2-> DX11 -DXVK-> Vulkan, which did work quite well for me with Tomb Raider 4 and 5 while Wine's DirectX 7 implementation had rendering issues at the time.

[0] http://dege.freeweb.hu/

How so you know if someone is an arch user?

> I needed to reclaim my Windows partition and go full-on Arch!

They tell you.

I considered making this joke myself lol. In reality, I actually just use Manjaro, but I enjoy playing into the stereotype :)

Reply on news.ycombinator.com