FEX-Emu Is Working On Speedy x86/x86_64 Games Support On AArch64, Including Proton

[phoronix]

Phoronix: FEX-Emu Is Working On Speedy x86/x86_64 Games Support On AArch64, Including Proton

While the Apple M1 SoC is a great piece of hardware, a large part of what has made Apple Silicon so successful with their newest Macs has been their Rosetta 2 software for dynamically translating x86/x86_64 software to run well on these 64-bit Arm systems. Existing applications and games optimized for prior Intel Macs continue running generally in excellent shape on their newest hardware thanks to Rosetta 2. While there is the ongoing Linux bring-up work for Apple Silicon on Linux, the open-source world doesn't currently have that advantage of a compelling Rosetta 2 alternative but the FEX-Emu project hopes to change that outlook...

https://www.phoronix.com/scan.php?page=news_item&px=FEX-Emu-2022

[mirmirmir]

Once valve gain big success from their handheld console. Next big step is to make the games work on arm, projects like this have valve's attention, then they release arm-based console.

And the year of linux desktop come: we beat microsoft on arm desktop computing race.

Linux arm desktop let's goo...

[bple2137]

Well working solution like this is exactly what we need to make Linux gaming not only an alternative that tries its best to keep up with Windows, but to make it actually better in terms of power efficiency.

Donate form where?

[sinepgib]

Once valve gain big success from their handheld console. Next big step is to make the games work on arm, projects like this have valve's attention, then they release arm-based console.

And the year of linux desktop come: we beat microsoft on arm desktop computing race.

Linux arm desktop let's goo...

Even if that happens you need this kind of compatibility solutions. Ports will only happen for actively supported games, and that time frame is usually short. Older games will never run natively.

[skeevy420]

Even if that happens you need this kind of compatibility solutions. Ports will only happen for actively supported games, and that time frame is usually short. Older games will never run natively.

Not to mention that after that short time frame new games and programs might also end up needing a compatibility solution. BF4 and Mantle comes to mind. That game isn't even a decade old and it's already under a compatibility solution. While I support native games on their respective architecture and OS, I live in the real world where there have been dozens of game consoles, architectures, and operating systems just in this century, let alone the 90s and earlier.

Compatibility solutions will never go away regardless of the operating system or hardware used. In fact, the amount of compatibility solutions available probably means that native gaming will become less and less the norm. Why target a specific operating system and architecture when you can target a compatibility solution that runs on multiple operating systems and multiple architectures?

[kiffmet]

I think taking an approach like RPCS3 would might work aswell. I.e pass all binaries through LLVM and recompile them for your current hardware ahead of time. Patch library calls to use host libs where applicable and be done with it. JIT will just always result in performance loss.

[schmidtbag]

Not to be a downer, but how is this supposed to handle some of the more complex instructions like AVX2 without totally butchering performance?

[skeevy420]

FEX-Emu wraps around all Linux 5.0 to 5.16 era system calls for the guest coverage.

That's how you create a stable Linux API: wrap up everything

Linux Emulation/Wrapping
●Linux on Linux, not usually emulation
●Supports Linux 5.0 through 5.16
●Most syscalls and ioctls can passthrough
●Need to capture and emulate what doesn’t

But, seriously, I wonder if the BSD's could use the "capture and emulate" portion of FEX for their Linux compatibility layer or if 64-bit Linux could use it for 32-bit programs?

[MastaG]

Noice! I'll soon give it a try on my Odroid N2.
I wonder how it compares to Box86, which was already making progress running Steam and games such as HL2 on ARM.

[DrYak]

Why target a specific operating system and architecture when you can target a compatibility solution that runs on multiple operating systems and multiple architectures?

The same reason why, despite Java games having been a thing since almost forever (including back on feature phones and colour dumb phones, before smartphone became a thing), you don't see much AAA title entirely running in Java/.NET:
performance.

Wordle is entirely written in Javascript, Cyberpunk 2077 isn't.

When you want to squeeze the maximum out some hardware, you often need to go a bit closer to the hardware (lower level API, optimized machine code, etc.) at least for the graphic engine part.
So big studio writing the next AAA title with as many bells and whistles as possible is going to go native to optimize as much as possible and cram as many effects in as possible. But what will happen is that this ultra optimized graphical engine is going to have some ultra optimized port across the most promising platform of its era.
So in a way the games will be targetting some compatibility solution: whatever high-level scripting is available on the engine ultra-optimized for that game.

But as long as there will be companies that want to make insanely power-hungry eye-candy-fests, there will still be platform exclusive and game that run natively on a couple of select platforms.


---

for the rest, the lighter games that try to run on as many platforms possible, you're going to indeed see more and more portable non-native implementations:
WebAssembly is an example that come to mind as a binary format that is used by some devs for rapid deployment to everywhere that can then be AOT/JIT -ed to local native with relatively low overhead.