AMD and Valve Working on New Linux CPU Performance Scaling Design | Hacker News Reader

AMD and Valve Working on New Linux CPU Performance Scaling Design

phoronix.com

172 pointsbpierre34 comments

If Steam Deck reaches even a moderate level of success, it will be a huge incentive for developers to make games target Linux (or, more likely, the Proton compatibility layer).

I actually prefer for devs to target Wine/Proton compatibility instead of providing native builds.

Native games can break over time. I have lots of older proprietary Linux games that aren't super straightforward to get running on modern Linux distros, usually because they rely on libraries that aren't included by default anymore (and sometimes not even maintained). The Steam runtime smooths this over a bit, but I still run into native games from only 4 or 5 years ago that are now broken out of the box.

Proton has the benefit of being a "framework" that isn't likely to be abandoned anytime soon. It is essentially a re-implementation of a platform whose primary selling point is long-term backwards compatibility and API stability. It abstracts (or outright eliminates) most of the variability between Linux distros.

Plus, games running in it can run mods that rely on DLL injection.

Ironically, many games I install on Steam run better in Linux under Proton than Windows 10 (especially from the 98/XP era)

I think this usually boils down to incomplete or buggy support for older 3D apis in modern graphics cards, as the fixes for these games almost always end up being to use a wrapper that translates them to modern Vulkan or DirectX like dgvoodoo or nGlide, similar to what Proton already has to do for these games.

Even brand new ones.

On my Windows 10 system, Katamari Reroll wouldn't even launch. Just a black scfeen.

In Proton on my xUbuntu desktop, it runs flawlessly.

I tend to expect older games to run better due to Microsoft depreciating older Windows libraries and apis, but a native newly released title was surprising.

Katamari Damacy Reroll fails to install a dependency that is fairly common in Windows but not included by default, and gets fulfilled automatically within Proton. So the problem here is less Microsoft's fault and more the developer not doing their due diligence.

Well... Games are such a pain to support or port exactly because of the nature of development. For most games post-release life cycle is supershort, i.e. nobody cares about long-term polishing, bug-fixing, proper platform support.

This is why Proton/Wine are such a massive undertaking.

I remember a Linus Torvalds video on this exact problem. I found it both blunt at insightful:

Linus Torvalds on why desktop Linux sucks : https://www.youtube.com/watch?v=Pzl1B7nB9Kc

Oh my God, Linus hit the nail on the head there. Prior to stabilising on a policy of "AppImage or GTFO", this was by far the biggest headache when it came to supporting Linux.

Steam uses flatpak-like runtimes now that should hopefully make backwards compatibility a non-issue going forward.

https://gitlab.steamos.cloud/steamrt/steamrt/-/wikis/Soldier...

It's a sad irony that we rely on a Windows userland to get games that work for more than a few years on a Linux distro.

It's even more amusing when you realize that a reverse engineered open source re-implementation of the Windows userland for *nix systems has better compatibility with legacy software than actual Windows.

Not the case anymore with Steam Linux Runtime (AKA Pressure Vessel AKA Flatpak)

On reflection I'm very OK with targeting Proton.

I actually don't want a closed source commercial blob TOOOOO comfortable on my linux box.

I want a heavily sandboxed but performant package that runs reliably.

That said, if those requirements are met and there is more performance etc on the table by doing a native/or partially native port that's great.

I don't know, wine kinda just barely works as it is. Introducing another layer of complexity through sandboxing would be opening a can of worms. Like I know Chromium's GPU sandbox has caused weird bugs in the past because it prevented the graphics driver from doing something it needed to do.

Proton isn't really about sandboxing the blob though, so it's not any better in that sense than running the blob natively.

Proton is a bit of a double-edged sword for gaming on Linux. On the one hand, it makes a lot of games playable on Linux that weren't previously. On the other hand, some developers have said that since Proton works well enough, they're going to stop officially supporting Linux versions of their games.

Think however what happens if developers start actually targeting Proton, instead of Windows. Suddenly Microsoft isn't the one holding the reins :).

Yeah, well. Not as long as developers use Microsoft's headers for development.

OTOH, if there was a Proton SDK...

I could see how one might come away with this opinion but if you reflect on the nature of video games the fact of the matter is they're inherently proprietary software. Given that video games are more art than function, I think I'm okay with that too.

If we accept that video games are proprietary, whether or not they target a native Linux runtime (which no standard exists) or a Valve blessed windows emulation runtime hardly matters. We as users have no power to build these applications for a desired runtime and it's unreasonable to expect publishers to work against an undefined moving target. History has already proven that this tends to be a worse experience in the long term for Linux users and even more recently native builds can be worse than Proton builds.

I'd say Linux directly, since performance would be still better than in Proton. Proton is a gap solution that helps building up user base while developers still ignore the platform.

I.e. some developers don't care about performance much, so they might rely on Windows builds. But others might care enough to make native versions once they see the platform as a significant target.

One of the great successes of Intel has definitely been establishing their processors as the default optimization status quo. Beyond the scheduler, compilers also optimize (by default) for Intel instruction latencies and pipelines.

One way to remedy this would be to ship more distros with march=native as the default. You only need to specify the architecture when you are building binaries for distribution (which mostly happens on CI servers these days). This would result in better perf on not only AMD chips, but also newer Intel chips.

I wonder if it is worth it to select a few core libraries like glibc, and get the distro to install multiple variants, each optimized for a different CPU.

glibc already does dynamic dispatch for the memcpy family of functions.

Recently (in the last year or so), the platform ABI for x86-64 has been augmented with 4 levels of variants: base x86-64 (i.e., up to SSE2), and then assume up to SSE4.2, assume up to AVX2, and then a base AVX-512 level. (Not mentioned in each of these levels is the random other instructions, such as BMI/BMI2 that get sprinkled throughout.)

Intels Clear Linux does this IIRC. Wins most comparisons on Phoronix. Works on AMD CPUs too.

(edit) Even though i'm a sucker for efficiency/performance, i prefer Tumbleweed myself. Since i like KDE, whose integration is as good as it gets on SUSE but left a lot to be desired on Clear which ships with GNOME by default. Both are rolling releases. SUSE has automatic btrfs snapshots on updates for easy rollback. But Clear has the performance edge.

https://www.phoronix.com/scan.php?page=article&item=ubuntu-2...

https://www.phoronix.com/scan.php?page=article&item=cascade-...

https://www.phoronix.com/scan.php?page=article&item=icelake-...

Oh nice this one shows Tumbleweed is not far behind:

https://www.phoronix.com/scan.php?page=article&item=amd-epyc...

Imo, the solution is to stop using C/C++ for high performance applications. Today's computers are diverse enough that distributing compiled binaries leaves a ton of performance on the table.

What would you like you use instead? C/C++ code which targets generic x86_64 is a few percent slower than march=native but that still leaves it way faster than most other languages.

I think Rust and Julia are 2 of the stronger contenders.

Rust also produces compiled binaries?

For x64, you don't need to distribute multiple binaries. You can have one binary with variants of a function each optimized for a particular microarch, and resolve which variant to use at runtime using the CPUID instruction. gcc already does this for you with function multiversioning, and glibc makes use of it for its string routines.

I don't think it's even slightly true that compilers default to Intel-specific optimizations. All the Linux compilers default to k8-generic, an obsolete AMD platform.

Intel P state drivers and linux schedulers are working great on my recent generation CPU. Power saving is important to me so I run PowerSave governor with turbo boost enabled, for most of my work load it stays at lowest P states with <50 deg C core Temp and during demanding tasks it scales up without delays.

It's unfortunate that AMD's scaling is not par with intel on Linux, I didn't know this earlier.

Wow, Valve is rocking!

I'm so hoping steam deck goes big. Suddenly we have pc gaming as portable version... Could be insane

Reply on news.ycombinator.com