Steam Hardware
A place to discuss and support all Steam Hardware, including Steam Deck, Steam Machine, Steam Frame, and SteamOS in general.
As Lemmy doesn't have flairs yet, you can use these prefixes to indicate what type of post you have made, eg:
[Flair] My post title
The following is a list of suggested flairs:
[Deck] - Steam Deck related.
[Machine] - Steam Machine related.
[Frame] - Steam Frame related.
[Discussion] - General discussion.
[Help] - A request for help or support.
[News] - News about the deck.
[PSA] - Sharing important information.
[Game] - News / info about a game on the deck.
[Update] - An update to a previous post.
[Meta] - Discussion about this community.
If your post is only relevant to one hardware device (Deck/Machine/Frame/etc) please specify which one as part of the title or by using a device flair.
These are not enforced, but they are encouraged.
Rules:
- Follow the rules of Sopuli
- Posts must be related to Steam Hardware or Steam OS in an obvious way.
- No piracy, there are other communities for that.
- Discussion of emulators are allowed, but no discussion on how to illegally acquire ROMs.
- This is a place of civil discussion, no trolling.
- Have fun.
view the rest of the comments
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.