Steam-on-Ampere | Hacker News Reader

Steam-on-Ampere

github.com

79 pointsmarcodiego32 comments

For those confused by the title, there's Ampere computing (which makes ARM processors) and Ampere the Nvidia GPU generation (eg. A100). This is about steam running on the former though x86 emulation, and also can use the latter GPU architecture.

Steam works very well on macOS/ARM64 (M1 or later). I didn't even know it used Rosetta until I checked out due to this article, this specific sentence:

> The bummer is that the Steam portal that runs on Linux is purely coded for x86/amd64 based system, that is why the Steam Deck is based on AMD.

Bummer to only see Nvidia GPUs in this article btw. They're only better bang for buck for AI/ML (obviously, thanks to CUDA, and therefore it makes sense Ampere focuses on these) and for 4k. Steam Deck needs to do neither as its 720p.

> and for 4k.

AMD seems to be doing pretty well on raw performance this generation. The 7900XTX is about £200 and £500 cheaper than the 4080/4090 respectively and often comes out much closer to the 4090 in benchmarks.

They still haven't cracked ray tracing though. Their implementation performs much worse than comparable Nvidia cards. Hopefully they'll figure it out before ray tracing actually takes off.

I can see adoption being fairly slow though due to AMD's partnerships with console manufacturers and Nvidia's absurd pricing on the cards that can achieve decent ray tracing performance.

It's disgusting how high GPU prices have risen though. My first build included 2 top of the line AMD Radeon R9 290X cards for less than the cost of a single 4070 Ti.

An ARM SOC on the steam deck would be really interesting in terms of battery life. But I guess game compatibility is the issue.

Right; I expect any energy efficiency improvements would probably be swallowed up by having to run qemu binfmt or such because basically every single game you're going to play on it was targeted to x86

You couldn’t just take any old ARM SoC off the shelf either, you’d need one with the ability to switch to a memory model as strong as x86’s (as M1 does), otherwise any emulated mulithreaded applications will misbehave.

Not really... the GPU would still be the main driver for the consumption

Nvidia hardware "just works" for a lot of ARM-based systems. ARM has been a big priority for Nvidia since the start, and their Linux drivers are plug-and-play on multiple arches and OSes. Prior to that, their hardware was in PDAs and laptops from pre-2010 using Nvidia-designed ARM SOCs.

What else would you really put in one of these systems? Intel's cards are very fresh and probably won't focus on ARM for quite some time. AMD's hardware and user sentiment is great, but their drivers are flaky enough already on x86.

> Steam Deck needs to do neither as its 720p.

So was the Nintendo Switch, and it sold like gangbusters.

Yeah, sadly AMD seems to not be making much investment into the Arm ecosystem, whereas Nvidia's proprietary drivers have been built for and tested on multiple Arm systems (likely due to Nvidia building their own Arm silicon for years now).

There aren't many changes required to get some amount of AMD GPU support going in Linux on modern Arm systems, but I'd still consider support 'experimental' there.

I was about to comment this fellow Jeff Geerling ran these PCIe GPUs on RPis but then I figured you're that fellow.

I think there's also some ARM Mac machines running on AMD GPUs. Though default models use Apple's stuff.

Btw, very interesting comments my comment sparked, thanks!

> I think there's also some ARM Mac machines running on AMD GPUs.

I don't believe any non-Intel Macs, including the new Mac Pro, support external GPUs: https://appleinsider.com/articles/23/06/05/apple-silicon-mac...

With macOS? Mac Pro I don't know, but its actually the Intel Macs which eGPU which are supported (with older macOS versions) and not Apple Silicon Macs [1]

[1] https://egpu.io/forums/mac-setup/definitive-macos-thunderbol...

Nintendo has always been able to overcome computational power constraints by focusing on game design (both through leading the industry with their first-party work and by fostering a third-party ecosystem where those qualities are also valued).

For Valve, the main asset is the PC gaming ecosystem; Being able to run popular titles from that arena is table stakes.

The reason I made the comparison is because the parent said Nvidia GPUs are "only better bang for buck for AI/ML [...] and for 4k." The existence of a popular, cheap, high-performance 720p console SOC manufactured by Nvidia sorta proves otherwise. Nintendo's capability of turning shit (PowerPC) into relative gold (GC/Wii/WiiU) is impressive, but besides the point.

Steam on Mac OS takes a very long time to start up and doesn’t respect the windowing system.

Are you just referring to games? Because I agree that Rosetta works well but those are all still Mac native (x86) games. There’s a lot you simply can’t play still unlike Linux with proton.

The number of steam games available on mac peaked before Catalina killed 32-bit support: I can still play 64-bit games via something like proton, but I have to stream from my Linux box for a good portion of my library.

I've been waiting for Steam to come out with a M1 (arm64) version as it's the last application I have installed that uses Rosetta. I haven't been holding my breath, since arm64 is not a priority for Valve. Hopefully this accelerates adoption of arm64 gaming.

Even if the Steam launcher were aarch64-compatible right now, you still need to emulate for all the games, and I don't see those getting ported soon if ever

Not all, just the vast majority... but the same could be said on macOS for x86-64 Steam games anyways. Funnily enough, many games on Steam beat Steam to the punch already and launch as aarch64 even though the launcher client is emulated.

If steam were ported to ARM, or at least ARM-aware, it could bundle a solution like fex or qemu or box86 just like it bundles proton/wine.

Box86 instead of qemu-user-static? I'd love to see a benchmark comparing these two.

Same. It's a shame that Steam is purely coded for x86/amd64 and doesn't try to use either of these tools on ARM.

I think that's a bit harsh of a criticism.

Up until very recently gaming on ARM was a non-starter. Even today, majority of the Steam library probably cannot run on ARM even if they tried.

We can't dig Valve here, especially given the impressive amount of work they've already plowed into gaming on Linux in general.

To abuse a meme I find funny - "let [Valve] cook".

Even if Steam could run on ARM my outsider’s understanding is that essentially nobody codes to the Apple GPU system. So the number of compatible games would be extremely limited.

The Asahi Linux team recently completed an OpenGL 3.1-compliant driver for Apple's ARM-based Macs, and is now working on a Vulkan-compliant driver, so hopefully that will change in a year.

The only OpenGL 3.1 compliant driver iirc.

Is Steam capable of delivering aarch64 native games? For instance, is it correct to assume that a game developer can upload both an x86 and aarch64 version?

Its already happening for a while. Some games have both binaries

i mean really, the dev can stuff whatever they want in a steam depot and point at it as the thing to run, so yes

I do have my doubts. Steam uses a Chrome(CEF I think)-based framework for most of its UI, and x86 Chrome runs like a dog's dinner on x86-to-ARM emulators (which is entirely unsurprising, considering it does a ton of JIT compilation)

Yes please, encourage more game on steam to have their gameservers compiled for arm.

A lot of indie games also use open source game engines, which allow (relatively) easy DIY native ports.

Reply on news.ycombinator.com