Steam for ARM / Android

[Hafas]

It would really be nice if Valve provides a full Steam Client for Linux for ARM (e.g. Raspbian) and/or Android and let game developers upload compatible binaries for these platforms, just like they can already for Windows, Mac and Linux; basically extending SteamPlay by additional platforms.

I don't know if game developers are interested but it would be nice if Valve could start setting the stones in this directions.

[meheezen]

There is a reason mainstream gaming consoles switched to x86

[🐧 thohal]

Im aware of their OS Specs which clearly state it is for x86 " Intel or AMD 64-bit capable processor " CPU Architecture

, but thats exactly the use case MultiArch was build for.... What sth like

dpkg --add-architecture i386
apt update && apt install steam 

and if this fails poorly i would suggest to open an GH issue and wait for their kind reply :)

Did anybody take a short ride of "windozed steam" via Hangover [github.com] backed by wine as they did not even mention steam?

edit: typo

[SIGKILL]

Originally posted by 🐧 thohal:

, but thats exactly the use case MultiArch was build for.... ?! What about sth like

dpkg --add-architecture i386

Because an x86-64 CPU can natively execute both 32bit and 64bit instructions. Basically, you're telling your system to also download and manage 32bit x86 binary packages in addition to 64bit ones. This is, basically, mostly useful for programs which are only available as 32bit binaries and need 32bit libraries to support them.


Aditionally...
It may be possible, depending on hardware, kernel and qemu to add [read: emulate] a totally different architecture like ARM, but it isn't going to automatically emulate all the other hardware in, say, a Nintendo Switch, for example. You can't just magically turn your x86 computer into a PS4 with a single line ; ). Performance will also be greatly hindered by the use of software emulation.

[Hafas]

Emulation is not really what was on my mind.
Just wishing that Valve may one day go beyond x86 and offer a platform for both game developers and customers for ARM-based systems, as well.

[🐧 thohal]

they should start pushing their steam-client code so we can support them :-)

but IIRC the next apple generation will be backed by ARM only which may help

[N0P3]

There's a continuing mass adoption of sbc products like Raspberry PI with enthusiasts targeting things like gaming using the systems and am quite certain that a Steam port to the devices (ARM sbc) would be widely accepted if not start a fire n the community. Honestly, would only serve to gain the Steam service even more traction through market attraction considering ARM based sbc.

Running Steam in a little ARM sbc server stack configuration is slightly intriguing.
sbc: single board computer for anyone unfamiliar with the terminology FYI.

[🐧 thohal]

Originally posted by (LINUX) Hot Sick:

......
Aditionally...
It may be possible, depending on hardware, kernel and qemu to add [read: emulate] a totally different architecture like ARM, but it isn't going to automatically emulate all the other hardware in, say, a Nintendo Switch, for example. You can't just magically turn your x86 computer into a PS4 with a single line ; ). Performance will also be greatly hindered by the use of software emulation.

i was referring to binfmt [en.wikipedia.org] support and qemu user-mode, which provides good performance and pretty handy for my embedded stuff - eg sth like

$ uname -a
Linux thohal 5.7.22-0.4-thohal-amd64 #1 ZEN-custom SMP PREEMPT liquorix 5.7.22-4ubuntu1~focal (2020-25-08) x86_64 x86_64 x86_64 GNU/Linux
$ docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static arm32v7/debian uname -a
Linux 7ed14d3be5ff 5.7.22-0.4-thohal-amd64 #1 ZEN-custom SMP PREEMPT liquorix 5.7.22-4ubuntu1~focal (2020-25-08) armv7l GNU/Linux

would run armhf binaries on x86_64 - same goes for sh4. mips, risc, ppc etc and vice versa

qemu-user doesnt emulate all the hw, just the CPU.. It executes foreign code in the "emulated CPU", captures all the syscalls and forwards them to the host kernel... User mode has many benefits, by not emulating all the hardware, which is slow, and also not emulating the kernel which is a decent part of the computation that takes place, which should give you an idea why this runs much faster than qemu system emulation.

We can even run foreign arch binaries transparently by setting up our own interpreters for binfmt_misc! eg

$ cat /proc/sys/fs/binfmt_misc/qemu-sh4
enabled
interpreter /usr/bin/qemu-sh4-static
flags: OCF
offset 0
magic 7f454c4601010100000000000000000002002a00
mask fffffffffffffffcfffffffffffffffffeffffff

, which instructs kernel to recognizes the SH4 ELF magic and make use of the interpreter /usr/bin/qemu-sh4-static , which is the correct QEMU binary for SH4 architecture of older enigma2 boxes. Couple it with runc/nspawn/docker/chroot/whatever - eg use sth like

debootstrap --arch=foo && chroot ...

and you got fully transparent cross arch support by using dynamic translation with really good performance out of the box!

edit: typo

[i_nive]

Originally posted by 🐧 thohal:

they should start pushing their steam-client code so we can support them :-)

but IIRC the next apple generation will be backed by ARM only which may help

Go Apple, go! kidding

Historically, games have driven PC hardware. Not the case with phones, SBC and similar small factor computing.
Gimme Power, no more, no less ;-)
https://www.youtube.com/watch?v=Q_7KaMDHoGs

[🐧 thohal]

Originally posted by i_nive:

.......snip.........
Gimme Power, no more, no less ;-)
https://www.youtube.com/watch?v=Q_7KaMDHoGs

you r missing more RAM [downloadmoreram.com] :)

[i_nive]

Originally posted by 🐧 thohal:

Originally posted by i_nive:

.......snip.........
Gimme Power, no more, no less ;-)
https://www.youtube.com/watch?v=Q_7KaMDHoGs

you r missing more RAM [downloadmoreram.com] :)

Me? Impossible, I have two pairs of 32 GB for a total of 128 GB RAM. It's true MB is half empty(or filled ;-) ) having half of the 8 memory slots utilized (speaking of TRX40 Taichi mobo)
Time is something I don't have as much as I like... Sadly, it's still a global unmutable variable -- can't do much with it, must take it as it is.

[🐧 thohal]

128GB on ARM SBC sound sweet :)

[Marlock]

Even if Steam is ported to ARM, the games would need an emulation layer...

When Valve decided to support Proton compatibility layer, they tapped into Wine, which was already very viable outside Steam.

I doubt they can replicate that burst of success with x86 to ARM emulation, because the available FOSS bricks they would need to tap into aren't as ready to perform as Wine was.

It's not that it can't be done... Wine also evolved very fast once Valve started acting as a catalyst... but it was already a solid and performant foundation... so this may take a long long while before anything gets going for heavier games, right?


ps: I'm so sorry for Apple gamers... OpenGL deprecated, Vulkan eschewed for Metal, architecture change... how is it even possible for them to maintain a respectable games library these days?

[Prezidentas]

Originally posted by meheezen:

There is a reason mainstream gaming consoles switched to x86

That's because it's cheaper, not because it's magically better in any way. Your video card is not x86 processor anyways.

Originally posted by 🐧 thohal:

they should start pushing their steam-client code so we can support them :-)

but IIRC the next apple generation will be backed by ARM only which may help

A lot of mac steam library games are already unplayable after apple removed 32-bit support from their operating system. The switch will finish this job and make all of the library unplayable. At first only their laptops will be ARM-based, and you can't play much on those anyways, so don't expect magic when the percentage of users are so low.

Originally posted by Marlock:

Even if Steam is ported to ARM, the games would need an emulation layer...

When Valve decided to support Proton compatibility layer, they tapped into Wine, which was already very viable outside Steam.

I doubt they can replicate that burst of success with x86 to ARM emulation, because the available FOSS bricks they would need to tap into aren't as ready to perform as Wine was.

It's not that it can't be done... Wine also evolved very fast once Valve started acting as a catalyst... but it was already a solid and performant foundation... so this may take a long long while before anything gets going for heavier games, right?


ps: I'm so sorry for Apple gamers... OpenGL deprecated, Vulkan eschewed for Metal, architecture change... how is it even possible for them to maintain a respectable games library these days?

Keep in mind the main reason valve supports linux is to have an easy way out when the need to ditch windows arises. There is no such reason with apple products.

[meheezen]

Originally posted by Red Star Gopnik:

Originally posted by meheezen:

There is a reason mainstream gaming consoles switched to x86

That's because it's cheaper, not because it's magically better in any way. Your video card is not x86 processor anyways.

yep, and that is what it usually comes down to, unfortunately.
but who's is going to invest into a different architecture if there is no clear consumer target for it? it might be a huge success, but who is willing to take that risk?

[Prezidentas]

Originally posted by meheezen:

Originally posted by Red Star Gopnik:

That's because it's cheaper, not because it's magically better in any way. Your video card is not x86 processor anyways.

yep, and that is what it usually comes down to, unfortunately.
but who's is going to invest into a different architecture if there is no clear consumer target for it? it might be a huge success, but who is willing to take that risk?

Well, apple is already doing it and all mobile devices are using different architecture too. RISC-V might do something too. Currently it's mostly for lower power usage, but it might change someday.