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
You must log in or register to comment.
This is almost certainly meant for the next Valve VR headset
Based on what? Looks more likely to be Android to me. Or it could be an ARM Steam Deck.
ARM has so much better power efficiency than x86
x86 has pretty much caught up already if you look at the latest mobile chips from AMD and Intel.
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.
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
I mean… It mentions waydroid so it is probably going to use that for android compatibility…
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?
Imagine someone can game on their Mac using ashi linux or heck even your phone
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.
yeah true i dont rlly have a mac but imagine gaming on apples m4 chips
Amazing! I hope I can buy a Linux on ARM Steam Deck someday. It should be more efficient, lighter, and smaller.
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.
And perform terribly because it’d have to emulate x86 because there’s no native ARM games (for Windows).
There’s no way there’ll be an ARM steam deck, unless valve wants to build an android gaming handheld for some reason.
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.
DirectX is being translated to Vulkan in the background using dxvk already. And box64 exists for intercepting those translated Vulkan (and OS) calls and running them through native code instead.
There’s a performance hit to engine code to be dealt with, but on the graphics side these tools already exist. With Qualcomm producing ARM CPUs that run x64 software as well as some mid tier x64 CPUs using emulation, and with the Steam Deck already being a low spec machine, I don’t see why running Windows games on a Qualcomm Steam deck would have to be a problem.
That’s a backward compatibility issue, which means some games developed for x86, Windows, or DirectX just can’t be translated without glitches. This means not every game developed for x86, Windows, or DirectX can be translated well on ARM.
I said that ‘some games that are developed only for x86 or the DirectX API have performance issues’; I didn’t say ‘every game.’ I mean that games with native support or cross-platform support are certainly better than those developed only for DirectX, Windows, or x86.
For example, many games developed exclusively for Windows/DX can’t be played on SteamOS. So how can you be certain that games developed for x86, Windows, or by DirectX would be well supported on ARM?
And you mentioned Qualcomm. Fine, look at the Qualcomm X Elite SoC computers. Do they run x86, Windows, or DirectX software or games steadily, efficiently, and well? Do they have many glitches when running Windows and x86 software?
Most games target DirectX, though, yet my Steam Deck is doing just fine. Targeting DirectX doesn’t impede running the games on Linux or on another architecture anymore thanks to decades of work by the Linux community.
I’m sure there are edge cases where dxvk support isn’t working well yet, but the same is true for Vulkan games. One of the reason Windows drivers for GPUs are gigabytes in size is because they come packed with shades for games you probably don’t even own, because the shades game devs write aren’t all that good and companies like Nvidia rewrite them to perform well on their hardware.
In my experience, dxvk is less glitchy than running games that target Vulkan using Wine or Proton. Some games don’t even work in Proton if you try to use Vulkan. I’m 100% sure that’s a Linux driver issue.
The nice thing about using dxvk is that the output is platform independent, as long as there are Vulkan drivers. If a game runs glitchless on x64, it’ll run glitchless on ARM. Qualcomm’s desktop Linux support doesn’t seem very present (or no Linux users are buying them yet) so I can’t find any reviews of box64 on these new chips, but on Windows these chips run games like Tomb Raider and the latest Total War just fine at 80fps at 1080p (using the 35W model).
The biggest challenge isn’t emulating CPU architectures, that’s a solved problem; it’s getting Windows games to work well on Linux, and for Qualcomm to release competent native drivers for their GPU. Especially the latter is the biggest problem at the moment, with Linux support not being finished yet and their Windows drivers sucking like Qualcomm software on Windows often does.
My Android phone, a five year old mobile Qualcomm CPU with about 2GB of available RAM, runs DirectX games targeting x86 Windows just as well as any comparably performing Intel chip does. Layering box64+Wine+dxvk works perfectly fine.
And the second example is Rosetta 2 for gaming on ARM-based Macs. You mentioned that some emulators running x86 games (on ARM) are inefficient.
That’s the point: emulation is not the same as translation.
Translation is generally more efficient than emulation and can sometimes even match or exceed the performance of native execution.
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
M1 these days is pretty mid though.
Snapdragon X Elite?
Definitely doesn’t have even close to the graphical horsepower
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.
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.
X Elite has those same tricks
The world is getting a better place
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.
this could be the biggest thing to ever happen to Mac gaming.
This is basically what Apple’s game porting toolkit does, except that’s not meant for distributing to end users (probably because they don’t want to expose their users to the bugs inherent to such emulation layers).
does rosetta 2 not already handle this scenario for macs?
AFAIK Rosetta deals with Intel Mac apps, not Windows. If this handles Windows games like Proton does… pretty big news!
Apple has their own wine based tool called Game Porting Toolkit that runs windows games and uses Rosetta.
exactly, rosetta has nothing to do with windows apps.
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
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.
