This would presumably let x86 windows games run on ARM hardware.
This is almost certainly meant for the next Valve VR headset, but ARM has so much better power efficiency than x86 that a future ARM based Deck would be a huge improvement to battery life.
Also see this tweet:
VR games that have already secretly pushed Android ARM builds onto the Steam Store are ran via Waydroid (androidARM to LinuxARM)
VR games that do not have an ARM build on Steam (windows x86) are being translated/emulated via ProtonARM and FEX
Edit: here’s gamingonlinux coverage of this info, includes some more information
Well, Steam and Proton both already run on top of FEX or Box64 on ARM Linux, but it’s nice to see an official effort from Valve.
Also, does ARM still have better battery life when all of the machine code has to be translated from x86? That adds a not insubstantial amount of CPU overhead, which does hurt battery life.
And perhaps most importantly, is there any ARM chipset out there that can deliver performance on par with the Steam Deck’s CPU (even after factoring in the overhead of the x86 JIT) at a viable price for a Steam Deck successor?
is there any ARM chipset out there that can deliver performance on par with the Steam Deck’s CPU
Yes, but they’re made by Apple.
I got a M1 Pro MacBook a couple weeks ago. I’m astonished at how fucking powerful those thing are. An Intel laptop I had with similar specs would start screaming for mercy for any heavy Programming work I’d do. The MacBook just shrugs it off. Fans don’t even come on
keep in mind, for the longest time Intels processors were still on Intels fab. a huge chunk of the efficiency/performance gains was less x86 > arn and more Intel Fab > TSMC. even to a lesser extent, compare the snapdragon 8 gen 1 to the snapdragon 8+ gen 1. Samsung wasn’t as far behind tsmc (compared to intel) at the time and both designs basically are the same chip but implemented at two different fabs.
It also involves how manufacturers decide how to handle price performance. Most laptop manufacturers see any performance lost due to clocking it low bad for sales(so they agressively clock it higher for performance) causing louder fans. Apple takes the opposite approach, where they tune it for noise performance because they control what people see on their graphs (while being misleading, by essentially never including anything faster than it) and asking users to pay top dollar for the top tier fab runs (apple essentially has top cut priority at TSMC) so they always get to see the bleeding edge efficiency nodes/performance before anyone else does at the higher cost to them(which is then passed on to the consumer)
Also, does ARM still have better battery life when all of the machine code has to be translated from x86? That adds a not insubstantial amount of CPU overhead, which does hurt battery life.
No idea, and that’s a pretty good question. The again some games run better on proton through Linux than they do on windows, so the performance overhead isn’t that bad.
True, but I feel like having to reroute x86 calls to ARM will produce more overhead than just Proton.
Depends on how it’s implemented. If they have a version of Proton that translates all x86 windows syscalls to ARM Linux, some operations could be extremely efficient.
There’s definitely got to be more overhead overall, though. Especially for devices with memory page sizes other than 4K, like the M-series Apple chips do (they use 16K as their page size), likely a VM will need to be sandwiched in there to ensure memory alignment. It’ll more fully be emulation and not just translation.
does ARM still have better battery life when all of the machine code has to be translated from x86
afaik macos/rosetta is more efficient than native windows/x86, but that could be down to OS integration, or any number of confounding factors… i’d suggest though that x86 windows applications sometimes run better and more efficiently on alternative platforms, even with the translation layers - whether that’s down to the instruction set or a combination of factors
IIRC, the M chips also have a couple of specific hardware accelerators for some parts of x86 code that ARM devices would usually struggle with. That’s something that other ARM chips (presumably) don’t have.
It’s more like a built-in hardware emulation mode than anything else. Modern ARM chips use out of order execution as the default, whereas x86 uses ordered execution as the default. M-series and Snapdragon X chips have a little flag that can be passed to tell the hardware to run in in-order mode instead of out-of-order mode.
