Live data from Hacker News

FEX-emu – Run x86 applications on ARM64 Linux devices

fex-emu.com

131–140 of 145 posts

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

#131
post #86

Earlier quoted context omitted.

Oh yeah, maybe that one was too obscure for me. I don't think I've ever seen something use PF/AF… You do want FEAT_AFP though, so you do want ARMv8.6+.

SETP is used rarely to compute parity, though it doesn't really save anything if you can use POPCNT. PF is also used by floating point comparisons with a different meaning though that is not useful for the Arm extension from Apple. AF indeed is basically unused. The problem for both is that you need them for accurate emulation "just in case".

You can eliminate flag generation almost all the time with a little optimization (slash deoptimizing if you hit an unexpected use) but it certainly is less convenient to have to implement an optimizer.

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

#132
post #65

Earlier quoted context omitted.

I don’t know if the two companies have such different futures. The games industry as a whole is in potentially terminal decline, have you seen all of the redundancies lately?

The AAA games industry with their multi-million budgets and "being too big to fail" mentality is on decline. It seems that anything that is not a new Call of Duty is considered not worth by the industry. But smaller games and indie studios are thriving. We got lots of very interesting indie games this year.

Games take years to make, as a consumer you’re seeing results from the past. Most indie studios are doing poorly, I know several that have closed and many friends looking for work.

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

#133
post #117

Earlier quoted context omitted.

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.

I don’t think Apple is catering to developers at all. If that were the case they wouldn’t be charging them $100 a year just to exist. They have the marketshare especially in iOS to force developers on to their platform.

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.

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

#134
post #117

Earlier quoted context omitted.

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.

Why do you assume that dropping support for Intel hardware from the OS will coincide with dropping hardware features that help support for x86 applications? Have you not seen Apple's documentation that states they plan to retain some Rosetta functionality beyond macOS 27 for the sake of x86 games?

I think that documentation essentially demonstrates how Apple wants to put as little resources into it as possible without making users of popular applications mad.

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.

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

#135
post #134

Earlier quoted context omitted.

Why do you assume that dropping support for Intel hardware from the OS will coincide with dropping hardware features that help support for x86 applications? Have you not seen Apple's documentation that states they plan to retain some Rosetta functionality beyond macOS 27 for the sake of x86 games?

I think that documentation essentially demonstrates how Apple wants to put as little resources into it as possible without making users of popular applications mad. 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 might even decide that they will be moving that functionality to software and decide to also leverage FEX.

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.)

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

#136

Earlier quoted context omitted.

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 rele…

I don't think your link contains the evidence you think it does. I'm not seeing anything that looks like Qualcomm contributing device trees on behalf of system OEMs, for any of the Snapdragon X products, so I don't see how you can claim that they're being selective. It looks like the device trees are mostly being reverse-engineered by the community, adding new system support derived from device trees for systems that already have some support.

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?

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

#137

Earlier quoted context omitted.

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 rele…

I don't think your link contains the evidence you think it does. I'm not seeing anything that looks like Qualcomm contributing device trees on behalf of system OEMs, for any of the Snapdragon X products, so I don't see how you can claim that they're being selective. It looks like the device trees are mostly being reverse-engineered by the community, adding new system support derived from device trees for systems that…

> 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?

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.

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

#138
post #134

Earlier quoted context omitted.

I think that documentation essentially demonstrates how Apple wants to put as little resources into it as possible without making users of popular applications mad. 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 might even decide that they will be moving that functionality to software and decide to also leverage FEX. 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. >…

The motivation is that die space on the chip is precious.

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

#139
post #138

Earlier quoted context omitted.

> They might even decide that they will be moving that functionality to software and decide to also leverage FEX. 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. >…

The motivation is that die space on the chip is precious.

If carrying around a little bit of x86 compatibility baggage had enough die size cost to matter for Apple, then Intel and AMD would be pushing much harder to reduce their comparative mountain of x86 compatibility baggage.

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.

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

#140

Earlier quoted context omitted.

I don't think your link contains the evidence you think it does. I'm not seeing anything that looks like Qualcomm contributing device trees on behalf of system OEMs, for any of the Snapdragon X products, so I don't see how you can claim that they're being selective. It looks like the device trees are mostly being reverse-engineered by the community, adding new system support derived from device trees for systems that…

> 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? 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…

> Qualcomm only ever pledged to support Elite processors

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.

Post reply on HN