I think ARM is their end goal, it’s really the only option for a handheld console, as today ARM is the only way you’ll get enough performance/power rate to make it both good on battery with good enough performance.
Win-win for everyone if they invest in an open source x86 to ARM project, similar like they did with Wine.
The Switch is more than proof enough that pretty much any modern game engine can compile to an ARM target with zero issues (though Nvidia’s low level APIs help, not sure about Qualcomm).
But there’s zero chance older PC games would ever be updated, and by older I don’t mean ancient, some AAA studios stop issuing updates in about one year after release.
So it all comes down to being able to emulate X86 on ARM… The best example we have is Apple, and games run but with a massive performance hit. Microsoft’s implementation is borderline unusable. I’m not sure what to expect from Valve.
Checkout Box86/64 and Fex-Emu. They both do x86 translation/emulation on ARM Linux and the results are wayy better than any reasonable expectations I had going in.
Emulation is from one architecture to another, translation layers like wine just translate windows instructions to linux, see also: every WIP ps4 “emulator” is just a translation layer, and doesn’t have the over head that it would if it was your traditional emulator
The way windows ABI works is syscalls always should go through dynamic libraries first, while on linux syscalls do syscall instruction/*. How windows syscalls work allows project like WINE just implement those libraries that will do linux syscalls. No instructions translated.
But with other architectures story is different. You either make instruction decoder for processor, make interpreter or make binary translator. First is itanium-way, second is naive way and third is how everyone does. Third is basically compiling one machine code to another. It has overhead of, well, compiling one machine code to another. And it works badly with other JIT compilers.
*there is vDSO, which is dynamic library, that implements syscalls like getting time. It is totally optional.
Aren’t the AMD in Deck 1 using x86 architecture? It would be impossible to change to ARM now. That would mean starting at square 1 and redesigning everything. And games compatibility would be thrown out the window.
The whole point of the Steam Deck for me is playing my older games. Unless they get x86 translation working without a performance hit them I’d rather they stay on x86.
Imagine Valve going the Apple route: “Fuck it, we will design our own hardware to suit our needs” and making hardware tailored to linux.
Edit: what about qualcomm’s new ARM: Snapdragon X Elite?
I think ARM is their end goal, it’s really the only option for a handheld console, as today ARM is the only way you’ll get enough performance/power rate to make it both good on battery with good enough performance.
Win-win for everyone if they invest in an open source x86 to ARM project, similar like they did with Wine.
The Switch is more than proof enough that pretty much any modern game engine can compile to an ARM target with zero issues (though Nvidia’s low level APIs help, not sure about Qualcomm).
But there’s zero chance older PC games would ever be updated, and by older I don’t mean ancient, some AAA studios stop issuing updates in about one year after release.
So it all comes down to being able to emulate X86 on ARM… The best example we have is Apple, and games run but with a massive performance hit. Microsoft’s implementation is borderline unusable. I’m not sure what to expect from Valve.
Checkout Box86/64 and Fex-Emu. They both do x86 translation/emulation on ARM Linux and the results are wayy better than any reasonable expectations I had going in.
Every year they are more likely to go RISC-V.
Nah ARM is barely more efficient than X86. As soon as AMD went TSMC 3nm they got almost similar power efficiency. As the Apple M chips.
Apples “magic sauce” is just being the first one on the new TSMC nodes.
I’m no expert so id love to be proven wrong but Emulation has more of an overhead than a translation layer, so that probably wouldn’t work as well
Not sure what point you trying to make. Translation is just one of ways to emulate.
Emulation is from one architecture to another, translation layers like wine just translate windows instructions to linux, see also: every WIP ps4 “emulator” is just a translation layer, and doesn’t have the over head that it would if it was your traditional emulator
This… Is not exactly how it works.
The way windows ABI works is syscalls always should go through dynamic libraries first, while on linux syscalls do syscall instruction/*. How windows syscalls work allows project like WINE just implement those libraries that will do linux syscalls. No instructions translated.
But with other architectures story is different. You either make instruction decoder for processor, make interpreter or make binary translator. First is itanium-way, second is naive way and third is how everyone does. Third is basically compiling one machine code to another. It has overhead of, well, compiling one machine code to another. And it works badly with other JIT compilers.
*there is vDSO, which is dynamic library, that implements syscalls like getting time. It is totally optional.
As I said, I’m not expert, thanks for the info, I’ll look that stuff up more when I have time
They already did it.
They didn’t. They asked AMD to do it.
Aren’t the AMD in Deck 1 using x86 architecture? It would be impossible to change to ARM now. That would mean starting at square 1 and redesigning everything. And games compatibility would be thrown out the window.
Computer is like AC. It becomes useless the second you open Windows.
Developers already did half of work for porting on ARM: they ported on Linux.
The whole point of the Steam Deck for me is playing my older games. Unless they get x86 translation working without a performance hit them I’d rather they stay on x86.
Does a performance hit matter for older games (I’m assuming they’re already 60+ if not a multiple)