> 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 possible. Furthermore, a per-app configuration system allows tweaking performance per game, e.g. by skipping costly memory model emulation. We also provide a user-friendly FEXConfig GUI to explore and change these settings.
> On the technical side, FEX features an advanced binary recompiler that supports all modern extensions of the x86(-64) instruction set, including AVX/AVX2. The heart of this recompiler is a custom IR that allows us to generate more optimized code than a traditional splatter JIT. A comprehensive system call translation layer takes care of differences between the emulated and host operating systems and implements even niche features like seccomp. A modular core enables FEX to be used as a WoW64/ARM64EC backend in Wine.
Used by the new Steam Frame (https://store.steampowered.com/sale/steamframe) which is an ARM64 Snapdragon 8 Gen 3 that will run PC and PCVR gaming titles.
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.
https://news.ycombinator.com/item?id=45903610#:~:text=Valve%...
The Alpha was such a great platform. It is too bad it’s reign was so brief.
https://interfacinglinux.com/2025/06/30/fex-emu-gaming-on-th...
The old games don't really matter with regards to FEX perf, so the only relevant bit is the semi newer games at 30/40 fps, which seems very slow to me, given that you are only running at 1080p/Medium, so you likely have a CPU bottleneck there.
FEX also has settings which weaken or disable TSO altogether, favoring performance over correctness. You wouldn't want to rely on those for anything important but a game possibly crashing isn't the end of the world.
The history of the PC is one of commoditization. A fractured multi-polar landscape is detrimental to the ecosystem/productivity and should ultimately fail.
x86 emulation is an important puzzle piece, and I'm happy Valve recognizes this and sponsors it.
Only the CPU code has to be emulated. The GPU runs natively.
That does not help with poorly supported GPUs of course.
A little old but still interesting.
Fex straight drm games.
(I know I'm describing an M2 Air, but I'd like to explore alternatives.)
As you can tell from my past comments about Chromebooks as Linux workstations here, I'm a daily user and very happy with them.
Qualcomm is already upstreaming support into Linux.
Qualcomm is already upstreaming support into Linux.
Take this with a grain of salt but since we are one the topic of games….
https://www.techpowerup.com/343081/qualcomm-says-90-of-games...
FEX is the shootstring, extra special discount budget (not maligning) version of Rosetta. Apple should sell Rosetta to Valve.
The other stuff is all present in ARMv8.5 I think.
QEMU exists. I doubt they want the bad press of suing an Open Source project everyone is using.
Isn't Rosetta kinda bad though? And won't get much better because it's not open source?
Gabe Ownership/co-founder:
- Valve - Yacht Companies - Starfish Neuroscience (Neuralink) - Submarine Companies
https://files.mastodon.social/accounts/headers/110/652/595/6...
Center of left side, it is a Valve product. All main devs are employed by Valve.
If they contribute to FEX at even a fraction of what they did to wine and Proton it is indeed huge.
They seemed quite happy to destroy their eco system if they won.
https://www.rcrwireless.com/20251001/business/qualcomm-arm-2
It's like comparing Office 2024 Excel on Windows to Excel for iPad. They're both called Excel, and share basic features, but once you start using features like VBA, it will not run on iPad Excel.
Also does it even work in Wine? Last I checked EAC only worked in Proton with the env variable to enable it being PROTON_EAC_RUNTIME
https://www.gamingonlinux.com/2025/05/denuvo-will-lock-you-o...
There's probably a mountain of x86 games that would not need to hit above 15-30fps to be fun.
1. https://www.qualcomm.com/developer/blog/2024/05/upstreaming-...
As for not improving, it is likely that Apple no longer feels the need to invest in Rosetta improvements now that Apple silicon is so dominant and software support is already very strong, but nothing is stopping them from investing in it if they need it for example for gaming
Why would a company on its way to the moon, entrust such an important project as translation layer between two major architectures to a single rinky-dinky corp that got rich selling common electronics marketed as luxury fluff, that's on the decline and has head so far stuck up its butt that it thinks it can do whatever it wants, instead of just write it themselves with support of the global developer community?
Apple could never do games because there are no luxury games. That's completely out of their zone of comprehensibility.
Apple products have pretty good build quality and perf per watt that more than justifies the premium. AS far as I can tell, the only payer in the market thats even trying to compete with apple on quality in the laptop space is framework. But Framework can't make their own chips.
The games industry as a whole is in potentially terminal decline, have you seen all of the redundancies lately?
The JavaScript instruction is cooler though.
https://developer.arm.com/documentation/dui0801/g/A64-Floati...
But smaller games and indie studios are thriving. We got lots of very interesting indie games this year.
> 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...
Do you have any clear instances of Qualcomm contributing something that's specific to Snapdragon X Elite parts and does not work for Snapdragon X Plus bins of the same silicon?
Or even for the more general issue: have you ever seen a Linux driver include arbitrary restrictions that make it refuse to work on identical hardware just because the marketing name for that bin of the same silicon was different?
You're getting caught up by inconsistencies in an argument you brought up. Which suggests the argument itself is flawed.
My unchanged position is Snapdragon X Elite laptops have better Linux support than the Plus variants. You thought I was wrong on that count - but I wasn't (see the thread).
Qualcomm only ever pledged to support Elite processors, and perhaps not coincidentally all of the Plus laptops require reversing- this is enough for me to draw conclusions. If you need the technical root cause, feel free to delve into why the originally supported models with devicetres had Elite chips.
Link, please.
> and perhaps not coincidentally all of the Plus laptops require reversing
You're still acting as though Qualcomm has made meaningful contributions to Linux support for Snapdragon X Elite in a way that has not also helped Snapdragon X Plus support. But you haven't specifically pointed to any Qualcomm contributions of any nature, let alone ones that were as narrow as you claim. All you've done is point to weak evidence that machines with Snapdragon X Elite bins reached a reasonable threshold of "supported" earlier than models with lesser parts, while ignoring that your evidence also points to the lower-tier processors coming to market later.
Can you point to any laptop device tree that was contributed by Qualcomm, and not merely reverse-engineered from the device tree for the reference design that was not offered for sale to consumers? Can you point to any driver contributed by Qualcomm that works for Snapdragon X Elite SoCs but requires further modification to work for Snapdragon X Plus SoCs?
You made a claim about a pattern in Qualcomm's public behavior, and have identified zero instances of that pattern.
Try the first Qualcomm link I sent upthread. I have trouble accepting you're arguing in good faith because you could have checked this for yourself. All the articles I can find pivlished by, or quoting Qualcomm concerning Snapdragon X and Linux consistently refer to the Elite version: I challenge you to find a single counterexample that mentions Plus.
You call my evidence weak, and yet you have provided no evidence to support your evolving argument thus far, so I hereby invoke Hitchen's razor, and will not engage with you beyond this comment. I refuse to spend any more of my time and energy trawling a 1200+ page Discord thread, Gthub, or the kernel mailing list searching for empirical evidence to counter your 10-second thought experiments, when you can't be bothered to open links I've already shared unprompted.
I bid you good day.
> 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.
macOS 26 is the last OS with an Intel build. Presumably this means that in all likelihood, M6 chips will remove this functionality.
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.
You do want FEAT_AFP though, so you do want ARMv8.6+.
AF indeed is basically unused. The problem for both is that you need them for accurate emulation "just in case".
I believe that running Windows games is something that Apple does not care about at all. Their efforts to create the game porting tool kit are 100% about getting more Windows games ported to the macOS App Store.
They might even decide that they will be moving that functionality to software and decide to also leverage FEX.
I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior.
That's crazy. Modifying an already-working CPU design to remove hardware features, and modifying Rosetta to implement that capability in software instead, or wholly replacing Rosetta with FEX, would all require investing more resources and effort than continuing to ship what's already done and working.
> I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior.
Fair enough, but we don't actually have to make projections based on past patterns of behavior when Apple has explicitly shared their plans. They do plan to maintain support for unmaintained games.
I think the only reasonable way to interpret what Apple has said about their plans for Rosetta is to assume they're not likely to muck about with the low-level details of how they handle running x86 machine code, but they are likely to start dropping some x86 libraries from the OS, breaking applications that depend on them. We can reasonably expect that they're retain all the pieces necessary for running x86 Windows software (especially games) under Wine. (Keep in mind that Apple's approach is to not mix x86 and Arm code in the same process; they didn't do anything like Microsoft's Arm64EC.)
In reality, the costs of design changes and validation and updating software to not rely on a newly-deprecated hardware feature can easily outweigh the potential per-chip cost savings of eliminating an instruction or two from a CPU core.
Intel and AMD have to maintain compatibility in a much different way. They don’t control what is done on the OS, they don’t control what is done with the physical product sold in stores. They have gigantic customers like Dell and HP and Microsoft that make specific technical demands out of their architecture.
Apple controls the whole stack. They decide exactly what features are in software and are in hardware. There are zero Apple machines in data centers running BigCorp’s legacy CashCow software. There are zero laptop or desktop OEMs that use Apple’s chips besides Apple. Apple won’t piss off their core consumer or creative professional customers by changing some technical behind-the-scenes feature.
I think Apple would gladly cut a very small and specific architecture feature from their chips if they feel it’s obsolete, better accomplished in software or not at all.
And this isn’t just for cost savings, it could be for performance and/or battery life optimization, or to make room for something else in the package.
