Live data from Hacker News

FEX-emu – Run x86 applications on ARM64 Linux devices

fex-emu.com

121–130 of 145 posts

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#121
post #6

I'n incredibly impressed by valve's commitment to playing the long game. It makes sense to have the frame by arm since the system is lighter and its clear this is just the trojan horse to get arm linux into every gamer's house. I wouldn't be surprised if we end up with an arm steamdeck 1-2 version from now when the tech is ready.

Too bad Arm doesn't allow architectural licenses, because this is exactly the kind of thing Valve and the FEX developers would want to extend the ISA to support. I bet we see a RISC-V backend to FEX in the next 6 months, it probably already exists in a private repo. FEX is the shootstring, extra special discount budget (not maligning) version of Rosetta. Apple should sell Rosetta to Valve.

ARM already has most stuff required for this on board. Two proprietary extensions are used by Rosetta: one emulates the parity (rarely used) and half-carry (obsolete) flags, which can also be emulated conventionally. The other implementa TSO memory ordering, which can either be ignored or implemented with explicit barriers; some other chips apparently have a similar setting.

The other stuff is all present in ARMv8.5 I think.

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#122

Earlier quoted context omitted.

The GPU is not run through a translation layer. The GPU is not an x86-64 CPU. Only the CPU code has to be emulated. The GPU runs natively. That does not help with poorly supported GPUs of course.

Pretty sure the GPU doesn't understand DirectX, which is used for Windows games, so it must be run through a translation layer.

Wrapping graphics APIs adds effectively zero overhead if the featureset of the hardware and drivers are a close enough match.

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#123

> FEX allows you to run x86 applications on ARM64 Linux devices, similar to qemu-user and box64. It offers broad compatibility with both 32-bit and 64-bit binaries, and it can be used alongside Wine/Proton to play Windows games. > It supports forwarding API calls to host system libraries like OpenGL or Vulkan to reduce emulation overhead. An experimental code cache helps minimize in-game stuttering as much as possibl…

A binary recompiler for running x86 on a different architecture? Where have I heard this story before?

https://en.wikipedia.org/wiki/FX!32

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#124

Earlier quoted context omitted.

CodeWeavers' Crossover just released a Preview version for Arm that incorporates Fex and allows games like Cyberpunk 2077 to run: https://www.codeweavers.com/blog/mjohnson/2025/11/6/twist-ou... I've tested it on an Ampere workstation, and was trying it on a Pi, but it seems with Trixie, there may be some bugs with both that and box64 right now, I was having trouble with both of them.

What motivates CodeWeavers specifically to work on this?

> The main corporate sponsor of Wine is CodeWeavers, which employs Julliard and many other Wine developers to work on Wine and on CrossOver, CodeWeavers' supported version of Wine.

https://en.wikipedia.org/wiki/Wine_(software)

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#125

Earlier quoted context omitted.

yeah that is correct. The m series chips can turn on total store ordering memory model solely for Rosetta. There's also some hardware extensions to arm to support x86 condition codes in the hardware because it's way more instruction efficient that way.

If you mean FEAT_FlagM, that's standard in ARMv8.4. (There's also FlagM2 and AFP that are optional.) The JavaScript instruction is cooler though. https://developer.arm.com/documentation/dui0801/g/A64-Floati...

RISC is dead; long live RISC

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#126

Earlier quoted context omitted.

My apologies to you and the entire Qualcomm marketing team for my brand-guideline violations - I was going off the top of my head. What I meant in my inscrutable comment was: "Elite X" => "X Elite", "Elite P" => "X Plus", I really should not have mangled the products using such an elegant and intuitive naming convention.

Ok, so having clarified the naming, it still looks like you're wrong about which chips are getting driver support upstreamed, because the Snapdragon X Plus parts are (with maybe one exception, IIRC) literally the same chip as the Snapdragon X Elite parts. Do you really believe that the upstream Linux kernel would accept patches that are specifically crafted to only work on certain bins of the chip, or to fail to enab…

Don't take my word for it - go to the Ubuntu Concept Snapdragon thread[1] and search for "plus" or "x1p".

> Do you really believe that the upstream Linux kernel would accept patches that are specifically crafted to only work on certain bins of the chip, or to fail to enable a peripheral if not enough of the CPU cores are enabled?

It takes more than a kernel patch to boot a laptop. Qualcomm has been neglecting to release the dtbs for Plus laptops. If you want good peripheral support, don't buy a "plus" variant. Getting back to your question, the answer is "Yes, Linux has always accepted patches that only work on some configurations" with no requirement to support all h/w configuration variants. Infact, some configurations are so obscure only the submitter can test - the maintainer/subsystem chief/Linus may not even know what the potential variants are.

1. https://discourse.ubuntu.com/t/ubuntu-concept-snapdragon-x-e...

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#127

Earlier quoted context omitted.

The GPU is not run through a translation layer. The GPU is not an x86-64 CPU. Only the CPU code has to be emulated. The GPU runs natively. That does not help with poorly supported GPUs of course.

Pretty sure the GPU doesn't understand DirectX, which is used for Windows games, so it must be run through a translation layer.

Sure, you are translating DirectX to Vulkan and that work is done on the CPU. So it may need emulation. But the Vulkan instructions passed to the GPU are effectively native. The amount of work the GPU has to do to execute against those calls is the same regardless of CPU architecture.

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#128

Earlier quoted context omitted.

CodeWeavers' Crossover just released a Preview version for Arm that incorporates Fex and allows games like Cyberpunk 2077 to run: https://www.codeweavers.com/blog/mjohnson/2025/11/6/twist-ou... I've tested it on an Ampere workstation, and was trying it on a Pi, but it seems with Trixie, there may be some bugs with both that and box64 right now, I was having trouble with both of them.

What motivates CodeWeavers specifically to work on this?

It is quite likely that Valve is paying for this work. It benefits the Steam Frame.

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#129

> FEX allows you to run x86 applications on ARM64 Linux devices, similar to qemu-user and box64. It offers broad compatibility with both 32-bit and 64-bit binaries, and it can be used alongside Wine/Proton to play Windows games. > It supports forwarding API calls to host system libraries like OpenGL or Vulkan to reduce emulation overhead. An experimental code cache helps minimize in-game stuttering as much as possibl…

A binary recompiler for running x86 on a different architecture? Where have I heard this story before? https://en.wikipedia.org/wiki/FX!32

The example that most people think of these days is Rosetta. But I also always think of FX32 as I think it was the first.

The Alpha was such a great platform. It is too bad it’s reign was so brief.

Re: FEX-emu – Run x86 applications on ARM64 Linux devices

#130
post #117

Earlier quoted context omitted.

https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f... > Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.

Perhaps another interesting aspect of this is that it’ll be Apple with their vertical stack that will decide when to physically remove this logic from the chips. macOS 26 is the last OS with an Intel build. Presumably this means that in all likelihood, M6 chips will remove this functionality.

I am not sure I consider it that likely.

First, these features are a big draw for developers (a key macOS audience).

Second, the ability to run Windows games is not getting less valuable.

Post reply on HN