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.
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?
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
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.
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.
Intel claims to have caught up with the upcoming Lunar Lake series but still to be seen.
That may be too late for whatever new device Valve is working on as given the lead time for such devices they may already have committed to an architecture for devices next year.
Also running X86 games on Arm devices is not likely to be efficient. I doubt the energy efficiency of Arm chips would outweigh the overhead of X86 to Arm translation?
But it's all speculation - even without hardware, getting Proton to work with Arm is good for steam regardless of any specific devices. For example it would allow steam to push the compatability tools onto Mac devices and even potentially mobile devices. Makes sense for Valve to do this without it meaning anything more that it being a god idea in itself.
It depends for the translation speed, if they only make a single device, they can likely do what apple does and improve their translation layer (FEX) to use specific instructions of the CPU they are using. Apples Rosetta is very efficient at what it does
Part of how they're identifying that proton arm and steam Waydroid exists is that the tools are being used to test VR games uploaded to steam, or were uploaded in a batch of other VR assets.
I fully hope to see this apply to Steam Deck/Chromebooks/Android/etc, but right now any hints of these have been VR specific. We haven't seen the Proton ARM before, but previous leaks about Waydroid have also all been VR related.
About Intel catching up I might add that even if it proves to be true, this was not something that seemed to be expected. Valve might have been working on IR for a few years now?
Perform terribly on modern AAA titles, sure, but that’s a tiny % of the total Steam library. A lot of people these days don’t even bother with new AAA titles, instead playing older games or indie games. I bet Valve knows this and is working on the ARM transition specifically because of this fact.
Which you said is a backward compatibility issue. Some games that are developed only for x86 or the DirectX API have performance issues, but other games that support cross-platform or cross-platform APIs like Vulkan do not have this problem.
An obvious example is the Nintendo Switch, which goes against your argument.
Because of backward compatibility, x86's efficiency still can't match ARM's. That's why I said games run on ARM would be more efficient, lighter, and smaller (when they natively support ARM).
If you have any doubts, just look at the Nintendo Switch.
This myth that ARM is more efficient needs to die already. The ISA has almost no impact on efficiency, and especially no impact on gaming, where the GPU is the much more important thing.
Winlator already does this on Android, for what it's worth. Oblivion plays fine on my phone although touch input sucks.
As for games on Asahi, there's box64/box86 to accelerate games (redirecting graphics APIs and such to native code).
You can already run apps made for foreign architectures by simply installing the right qemu package (not the virtual machine, the binary translator) and running the software using standard Wine. Conversely, you can also run Raspberry Pi software this way on normal PCs, which has proven very useful to me for cross compilation scenarios.
I assume Valve will take all of this tech and optimise it a bit more. If you're on a MacBook, your biggest challenge will probably be driver support, which is advancing at a rapid pace, but I'm not sure if you can get maximum performance out of it yet.
A part of me does hope that they'll hold off and release riscv products instead (headset and deck). I know box64 can already translate to riscv and I remember reading that FEX was working on it (android is also getting riscv support so waydroid should too?). Given their focus on linux it has to be on their radar
In the shorter-term the issue is the lack of sufficiently powerful commercially-available RISC-V hardware for the level of gaming people expect out of a Steam Deck or VR headset, which ARM already has a number of SOCs capable of.
I don't doubt that the work will continue but Valve isn't likely to pour time or money into it until they think the hardware is there.
i mean better efficiency is one thing, but having "so much better power efficiency" isn't that large, especially under load. Arms major advantage is efficiency while doing lighter workloads, which is kinda the antithesis of a gaming device would be.
What arm based designs excel at is if whatever workload utilizes some of the specific built hardware in them, which is why the modems and camera image processor on the snapdragon cpus are better than x86, because x86 designs dont really have dedicated hardware for those functions integrated fully(intel cpus do to some extent)
Arms major advantage is efficiency while doing lighter workloads, which is kinda the antithesis of a gaming device would be.
That's important too for gaming devices. It's great the the steam deck can get 6-8 hours on low power games like Stardew Valley. A significant problem with many of the windows competitors is that they don't see significantly better battery life at low loads. The original ROG Ally gets about 1.5 hours in a game like Cyberpunk 2077, but only gets 2-2.5 hours in a game like Stardew Valley.
the lighter workloads isn't like stardew valley levels workloads, it would be like watching a video level loads. Just being arm doesn't outright make it that battery friendly, its like the non application use(e.g sleep, super basic app) where the battery level is better. The qualcomm laptop reviews kind of show that platform when its battery life is mildly better than last gen amd/intel chips and worse under gaming. Qualcomm rushed the release because they new they needed to release before AMD's Strix Point and Intels Lunar Lake to make it look like they were more efficient. (X elite was on TSMC N4, Meteor lake was on N5/N6, Phoenix and Strix were on N4X, but they knew AMD would have the highest NPU performance had it released first.
the BIGGEST flaw that the arm based designs have that isn't tegra is that their graphics drivers are inferior to both Nvidia and AMD, and graphics drivers play a huge role in whether something works correctly or not.
I don't think a budget deck is likely tbh. The non oled deck already goes for 250 on sales. To make a clear distinction the budget one would need to be <150. And I don't think that's feasible with all the other hardware necessary alone. Except making it a lot smaller which I don't think is a good approach.
ARM based Deck would be a huge improvement to battery life.
Don't get your hopes up too high. You will need an emulation layer like FEX of Box64, and unlike WINE those do have quite a substantial overhead.
It is impressive how far those emulators have come, especially since they got the option to use native libraries instead of emulated ones, but the game logic itself will always need emulation...
This doesn't mean it can't be done, it just means that the ARM CPU needs to be pretty fast to counter the emulation overhead, and that's why I have my doubts about the energy efficiency...
(Btw: I have tried running several AMD64 games on my A311D powered MNT Reform laptop with Box64. It's impressive how well the emulation runs, and how many games are actually playable already. However, I also encountered a lot of games that don't reach enjoyable FPS on that hardware. With a faster ARM chip though....)
With a big dev like valve backing it they could probably implement a pretty impressive JIT/cacheing scheme - of course nothing beats native but this gap will close over time
Yep. The big question is if the gap will close enough that ARM chips indeed end up delivering better power efficiency with emulation than an AMD64 chip that delivers the same performance without emulation.
My bets would be on the native AMD64 chip ending up more power efficient. To be honest, I would not bet too much money though.
This would presumably let x86 windows games run on ARM hardware.
Doesn't that require something quite different?
Proton is improved (matured?) WINE, right? And Wine Is Not an Emulator - the point being it doesn't emulate hardware, it translates instruction sets. From for-Windows x86 to Linux x86. Can you do that cross cpu architecture?
Well, not exactly... WINE is a compatibility layer for syscalls between the x86 Windows API and (among others) the x86 Linux API, quite similar to how DXVK translates from DirectX to Vulkan.
What proton does is combine utilities like Wine and DXVK into a user friendly bundle, along with contributing substantially to the projects it bundles to make them interoperate well.
This looks to me like they want to bundle another utility, which does fast emulation of x86 user code on an ARM Linux system. Another commentator mentioned they are using FEX for this, which looks to me to do the same core task as qemu-user, but more focused on x86 to ARM and generally user-friendlier. That emulator could then be used to run x86 Wine on ARM.
The way qemu-user and FEX emulate one ISA on another is actually very cool btw. They realise massive speed gains by intercepting syscalls and executing them directly, instead of emulating a whole x86 Linux system.
by intercepting syscalls and executing them directly
Not only syscalls. FEX and Box64 also allow using native libraries instead of emulating them. That leaves basically only the game logic to be emulated.
This is something I’ve always wanted from them ever since I learned that the current ways that emulate x86 use proton on top of a bunch of other stuff. Would love if this was able to be used on phones.
Rosetta is for the game makers, proton is for the fans. So its easier for people to make the games work vs waiting on the game developers to manually port it using rosetta
I know you're referring to a VR headset but my mind immediately started imagining standalone over-ear headphones that can play all PC games through a purely audio interface. Imagine the accessibility possibilities lol