ARM support for Wine

[setsunati]

https://wiki.winehq.org/ARM

So we can run Windows games on Raspberry Pi, Odroid, Nintendo Switch, Android, etc. any ARM CPU Architecture. (You can install Linux on Nintendo Switch in case you didn't know.)

Since Wine on ARM already gets packaged with Debian, i guess you just have to do is add Wine on ARM source code to Proton and make it work with Proton.

[rkfg]

Wine is not an emulator as the abbreviation suggests. It runs the binary as is and wires the system calls so that they work the way they do on Windows. For ARM that would mean that you'll be able to run Windows games compiled for ARM on RPi, are there many games like that? IIRC, there's only one Windows ARM device, their Surface tablet.

[kisak-valve]

Hello @setsunati, this is not a realistic objective for Proton. As @rkfg, mentions wine for ARM does not magically make x86 based games work on ARM cpus.

Even if Steam were brought to ARM, and an x86 emulation layer was run underneath wine, the amount of games that could run fast and without hitting video driver quirks is small enough not to entertain this idea any time in the near future.

[jazir555]

@kisak-valve

The Galaxy S10 Plus has insane specs: https://www.techradar.com/reviews/samsung-galaxy-s10-plus

I do not think that running games with adequate speeds will be that far out of reach for very long. The development cycle for smartphones is rapid. Is this technically possible were anyone to have the impetus to actually attempt to implement this?

[mdrejhon]

Relevant: https://github.com/ValveSoftware/Proton/issues/7200#issuecomment-1835537144

The recent breakthroughs merits reconsideration of this feature;

I believe Valve's future Deckard VR headset actually has enough computing power to run PCVR applications standalone, Steam Deck Style.

One can use the same 3dof rescue reprojector already in Quest 2 for fixing WiFi PCVR stutters, but for fixing x64->ARM Proton dynarec stutters.

Steam Deck Almost Ran PCVR at 90fps With Some Hacks

"I've tried this on Windows with Virtual Desktop and I was able to get about 60fps, and you can turn on spacewarp to raise that to 90 or 120, or use Snapdragon Game Super Resolution to upscale, but unfortunately Valve doesn't support Windows properly and the GPU encoders don't work so it's running on the CPU and that takes up a lot of usage."

https://www.reddit.com/r/SteamDeck/comments/17gh0e9/steam_deck_can_run_pcvr_using_a_quest_2/

With some further native optimizations (not done by public), it could possibly get the rest of the way (GPU-based instead), like using Snapdragon Game Super Resolution on the GPU instead of CPU.

Then you add the additional rescue 3dof workflow algorithm that I suggsted in my previous comment;

Combine it all together -- and I think we're just in the envelope.

I think that an M1+ style ARM (or Snapdragon equivalent) with a performance margin 3x+ of a similar x86 in the Steam Deck -- can probably more than overcome the emulation penalty. Especially if the tricks (all 5 of them, combined to keep the frame rate 90fps) that I suggest are utilized. Especially with a Steam Deck style wizard to babystep the end user to optimal PCVR settings for standalone PCVR on Deckard, perhaps?

---

EDIT:

With some further native optimizations (not done by public), it could possibly get the rest of the way (GPU-based instead), like using Snapdragon Game Super Resolution on the GPU instead of CPU, and do it like as the "FSR2" equivalent on the realtime priority GPU schedule just outside the Wine layer.

[PVCR game running Steam Deck style on Deckard] -> [Wine+ARM] -> [Deckard Proton Driver] -> [Outside Wine] -> [Native Driver + FSR2 + 3dof Reprojector] -> [Deckard Screen]

Then you add the rescue 3dof reprojector algorithm that I suggsted in my previous comment. The rescue 3dof reprojector will interrupt whatever is running in the emulator (much like de-stuttering an briefly interrupted WiFi VR streaming connection), to 3dof-reproject the last full frame, whenever no new frame has arrived from the Proton ARM emulator. This is existing technology in Quest 2, apparently, to de-stutter remote stuttery PCVR.

[Spidy123222]

Hello @setsunati, this is not a realistic objective for Proton. As @rkfg, mentions wine for ARM does not magically make x86 based games work on ARM cpus.

Even if Steam were brought to ARM, and an x86 emulation layer was run underneath wine, the amount of games that could run fast and without hitting video driver quirks is small enough not to entertain this idea any time in the near future.

There’s not a lot to know if there is that much driver qwerks. There is already many games that have been tested that have no issues on these devices. In my closed issue that I accidentally made as GitHub wasn’t showing this thread some reason. Something like FEX-Emu can already run in many snapdragon devices and even the Orin with AMD pro gpu without issue running steam itself inside it. As shown here in fex-emu channel from the developer. Since FEX-Emu supports both 64 bit and 32bit, it can actually run programs that uses both type of libraries which makes compatibility higher also. It’s a known translation layer to have high compatibility compared to qemu-user and box64.

https://youtu.be/0ZVC2Q_91FY?si=mNKysK2uALiIYbOa

They can run pretty demanding games on the Orin on a rdna3 gpu under Mesa using radV drivers. Theres now even an android community that runs pc games with wine even a new one coming called cassia that will try using fex-emu with I believe proton also.

Snapdragon 888 with 12gb of ram can run god of war on android using wine in a termux container (mobox) rather slowly (almost full speed) using box64 but other devices with higher specs could do better because of the gpu. https://youtu.be/mrNIijDGOBk?si=AmHFHAVhQMMEr0KI

m1 devices can run valve games in a microvm (doesn’t support 4kb pages in the mmu properly so it used microvm to get around issue) https://fosstodon.org/@slp/111099674670375388

Even if there is driver quirks, usually they get fixed in turnip drivers or in Mesa just like for the steam deck when it had issues. Things take time to develop just like proton.

There is a clear desire to have arm devices run steam games under steam play. No one is saying it’s magic as this is all from efforts from people that did a lot of work to get stuff going. A few of these points are from the other issue but since it was duplicate thought I would re-iterate to fit this thread.

[Skorpion96]

Hello @setsunati, this is not a realistic objective for Proton. As @rkfg, mentions wine for ARM does not magically make x86 based games work on ARM cpus.

Even if Steam were brought to ARM, and an x86 emulation layer was run underneath wine, the amount of games that could run fast and without hitting video driver quirks is small enough not to entertain this idea any time in the near future.

Excuse me..... Don't support x86 apps on arm but allow to run on arm with Proton exes for arm, same for arm64, this should be doable

[mdrejhon]

Excuse me..... Don't support x86 apps on arm but allow to run on arm with Proton exes for arm, same for arm64, this should be doable

That's an interesting idea, since Windows ARM platforms are now coming onto the market. Games are being recompiled to arm64 Windows to allow them to run on ARM-based Windows more often because of the new Qualcomm Snapdragon X developments.

By the time a theoretical Deckard is ready, perhaps the Windows arm64 ecosystem is mature enough. Deckard could also run a Windows ARM VM inside, for virtual-monitor applications (e.g. remote working without a laptop screen) like Vision Pro and Quest Pro is occasionally used for.

This could be extended to run arm64 PCVR games in-headset, as a lower-engineering compromise by Valve, to support easier porting of PCVR ecosystem to standalone. There's still a lot of great VR content on the PCVR side of things, even with standalones becoming more popular.

The post by @kisak-valve is dated 2018, which is now 6 years ago, so the status quo has probably changed with the newly extremely well-performant ARM subsystems whose integrated GPUs now have 3DMark (Time Spy) scores overlapping the scores of early PCVR subsystems (900 series and 1000 series GPUs) -- and that's even before doing framegen improvements such as FSR or Qualcomms' equivalent.

But don't forget the in-headset 3dof reprojection (headturn) already industry standard in all Quest headsets. That optimization will be mandatorily critical as a "rescue reprojection" OS-level algorithm that goes between the VM and the metal. I wrote about this in the earlier post above...