Steam Deck lead reveals Valve is funding ARM compatibility of Windows games “to expand PC gaming” and release “ultraportables” in the future
Steam Deck lead reveals Valve is funding ARM compatibility of Windows games “to expand PC gaming” and release “ultraportables” in the future
Stuff like this is the main reason why I only buy from Steam if I can help it. GOG has a noble anti-DRM goal, but Valve is doing a lot more stuff that matters. Besides, I count Steam's apathy towards their own easily-bypassed DRM as effectively DRM-free at this point, and as far as I understand Steam's DRM is also voluntary for game devs to use.
GOG does game preservation, which is nice.
I wish they'd align more at least on the Linux issue. What's the use of preserving games for an OS that's not going to last? It seems antithetical to their goals. Meanwhile, Wine and the rest of the Linux emulation components are also doing real work for preserving games by just making their original releases continue to work on modern operating systems through translation layers. My guess is GOG is waiting for gaming on Linux to be "worth it" before devoting their time and effort into it, which is basically just being a fair-weather friend and not actually helping.
Me too. If GOG would support Linux, I would have chosen to buy there too. Valve is actively developing on Linux related stuff and their client and software is supporting Linux. Steams DRM is not anti consumer in a way usually DRM is. It allows us to play offline in example and does not get in our way. Off course DRM free is the best case, but without official Linux support I don't want to buy from GOG.
The same roadblock has existed for ARM PCs as Linux PC - the mountain of legacy stuff that only runs on x86 Windows. Which is something Steam's Proton has directly addressed.
Now that they've wrapped legacy software in an OS compatibility layer (Wine/Proton) and that is being wrapped in an instruction set compatibility layer (FEX) that mountain of software is ready to roll!
Best part is, valve's contributions are virtually all being pushed upstream, meaning unrelated projects will all benefit from the work.
2026 - Year of the Linux ReactOS desktop!
I love ReactOS I just want something as stable as XP
ARMs Race
Valve is dropping a wrench in microsoft gaming monopoly. And I fucking love the sound of it.
If they get this working well, next deck is gonna be ARM for sure.
I've seen ARM64 in action firsthand in the new Macbooks. The energy efficiency especially is off the charts. Since battery life was the Steam Deck's greatest flaw, chances are an ARM architecture version can squeeze a lot more juice out of the same battery size in the future.
Was is biggest flaw? Have you SEEN the other options out there for handhelds? Everyone craps on SD because it feels underpowered, and it kind of is, but watt for watt you get more performance than machines costing several times its price.
The SD is an absolute beast in its class, battery life being best in class, compared to what everyone else is doing.
Though I agree, for heavy loads, it's not quite enough for proper mobile use. Even better battery life would be preferred, and ARM can hopefully bring that.
Oh I agree completely. There are many "more powerful" devices out there, but very few people actually prefer them if they've used a Steam Deck before. And its battery life is fine for what it is, but it would be awesome if it was twice as much.
Valve phone? I don't really want an arm steam deck. It's important to me I be able to run stuff outside of games on my deck. It's not just a handheld, it's a full fledged pc in a handheld body.
But if they want to make a valve phone with a Linux based os....
You do realise that the same runtime that makes x86 games work on ARM, will also work for... drumroll please... regular software too?
The whole point of FEX is running x86 applications on ARM. Much like WINE, it won't be limited to games.
Valve phone? Nah. I'll be surprised if you're not able to run x86 Windows games using the Steam Android app though. You already can with GameNative and GameHub anyway.
I'm completely a novice at understanding this, but is ARM battery efficient because of how its executables are compiled or is it battery efficient because of ARM chip architecture? I guess my question is if you run a comparability layer like this will the ARM chips still be as efficient running x86 programs and games?
A smaller handheld like the DS would be neat. Also can you imagine a Steam Phone? While it would make sense to do so, its a total another beast to develop and maintain a phone based operating system.
I want laptops with ARM processors, like Apple's been doing, but not from Apple.
Why?
What is the difference between a phone based operating system, and a Steam deck you jam a Cellular antenna into?
The entire operating system is? I mean its like asking what the difference between Ubuntu and SteamOS is. One is optimized for a specific use case. You do a lot of other stuff with a phone. Even the controls are different from a gaming device or PC. The display is much smaller. Why don't you think we have more phone based operating systems like Ubuntu for phones?
This problem is far more difficult to solve than x64 windows apps running on x64 linux.
While x64 and ARM are both turing complete and thus anything one can do, the other can also do, there can be subtle differences to the way they do them.
Like one I'm aware of is the atomicity of loading memory using a co-processor register, which is required for accessing thread local storage, and introduces a subtle race condition if someone uses user mode multithreading (which can be way faster than kernel mode multithreading) without handling the case where they get preempted between moving that register's value and doing the load, and end up running on a different kernel thread when they get back (because you need one kernel thread per core). That thread would end up with the pointer for another thread's thread local storage, which tends to break things pretty badly.
That's just one that I'm aware of. There's probably tons of other subtle differences that mean you can't just have a map of "x in x64 means y in ARM" and use that to generate a compatible binary. It would probably run, but it would have bugs that the original doesn't that are only seen in rare edge cases.
Not that I want to discourage this effort, but this is a problem an order of magnitude or two more difficult than the one proton solved, which was essentially just a bunch of wrappers that convert one API or OS behaviour to another equivalent one.
I understand the technical challenges with running x86 apps on arm... but multiple wrappers that do something similar to proton have already been released.
If you follow the r/emulationonandroid subreddit, they have gotten PC games working on android for a while now. One of the wrappers, gamehub, has made it to the playstore. You can just sign in to your steam account (don't do that gamehub is sketchy af, proprietary, and by a company that stole gpl code fro, yuzu and didn't release a derivative product), download games, and play them.
The current concern is performance, but most lower and midrange games run just fine.
Yeah, a lot of programs will likely run fine. The common issues will be solved. But the subtle ones will be frustrating. Plus I worry about a situation where apps target x64 and run on ARM but aren't supported on ARM, kinda like what we've got with games on linux right now.
Arm Steamdeck? Sign me up! Arm on Linux ftw. I also have high hopes for the snapdragon x elite 2 to finally push me off macOS. Tangent on that I saw some reddit thread (yeah yeah reddit) and it mentioned that x elite 2 might support dgpus everyone said “but why though”? Well the answer is so that you can disable it and have killer battery life and then just enable it later for performance. Why wouldn’t everyone want that?
I’m guessing something about PSP sized because they have their Android Linux emulator project ongoing too
I hope they make arm Steam available for all devices and oses.
Like macos arm
Windows arm
And Linux arm
In this age of leaks and industry insider speculation I'm very impressed they've kept this under wraps for so long
They have not. I can‘t provide you the link, but it was long speculated that they are working on an ARM device. Also you cannot really hide activity in an open source project. It was just not officially communicated that these changes have been funded by Valve.
You cant hide the activity but you can hide the contributors and/or the funding.
Sure it's been speculated, but if there were obvious signs like commits in the fex repos by valve employees then wouldn't there have been more than speculation?
You could, if the person was not known to work for the company.
I find this very possible that they kept it hidden for so long. After all, Valve has been very tight on leaks for very long. Guess that HL2 dev build leak taught them a fair lot in how to protect their business from leaking info.