Desync on all replays and games with Windows 11 Arm on M1 Max Apple
-
@geosearchef Not sure what you're talking about here, you can perfectly play solo campaign, so yeah the M1 is perfectly fine. Problem is to do a multiplayer game or run a replay.
Not sure if there will ever be a way to mitigate that calculation discrepancy.
-
On that note, did someone had the possibility to try running 2 FAF setups on M1 in a multiplayer game ?
We do know that between a Windows PC and a windows with emulation on M1 it does not work... but how about 2 identical emulated setups ?
-
In addition to FPU shenanigans, lightly quoting Marcan, the cores in the M1 speculate execution extremely hard, and that is making pre-existing unknown bugs surface. It's possible FA itself is broken in a way that never shows up in Intel/AMD cpus, and if that were the case it's probably pretty much unfixable.
It would also mean that the game would likely stop working at some future point when x86 cpus get more complex and trigger the bug. (you can talk about retro compatibility being x86's only reason to exist though and argue that last point may never happen)
-
@corsaire said in Desync on all replays and games with Windows 11 Arm on M1 Max Apple:
Not sure what you're talking about here, you can perfectly play solo campaign,
Yes, what he/we meant, was that you would need to perfectly emulate an X86 to play with other X86.
Singleplayer and playing with other M1 should/might be fine?But i also heard from someone on discord, that he successfully plays ladder with an M1, but gets desyncs in lobbies, which is quite strange.
-
I've checked some sources. In https://gafferongames.com/post/floating_point_determinism/, a developer of SupCom confirms that they already use the IEEE754 float standard to avoid desync problems with different x86 processors (AMD and Intel). They use the _controlfp command to determine how floating-point calculations work. The problem is that on ARM Windows, _controlfp has a slightly different effect - it affects a different set of registers (https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/control87-controlfp-control87-2?view=msvc-170).
This is only a guess, but it seems like we can just rewrite some code and change the used float registers.
I'm not sure that this will solve everything, but it looks like a good first attempt. -
@Eyvind that is an interesting find
, I'm not sure how trivial it would be to fix what you describe. We don't have access to the source code of the engine, for example -
@Eyvind Great find! Even without source code, perhaps it could be possible patch? (or if Microsoft needs to do something?)
It would be interesting to compare with Qualcomm ARM based Windows 11 laptop, if anyone have access to one of those?
-
From the first link these two function calls are important to ensure deterministic floating point calculations across different systems (such as Intel and AMD):
_controlfp(_PC_24, _MCW_PC)
_controlfp(_RC_NEAR, _MCW_RC)The first is Precision Control, the second is Rounding Control. According to the microsoft documentation linked for controlfp - setting the Precision Control to 24 bits is not supported on ARM. Making this call on ARM will simply not change anything. The Rounding Control to NEAR seems to be ok.
(Precision Control is not supported for x64 either, but supreme commander FA is 32-bit application I think)
-
On a second thought, might also be this assert that fails the first tick:
gpAssert( (_controlfp(0, 0) & _MCW_PC) == _PC_24 );
Since setting the _PC_24 flag does not do anything on ARM, when checking the flags, that will be unchanged. First thought - could we disable one of these asserts with a patch? Or somehow pretend the flags are always set as expected on Apple Silicon with _PC_24 set (or redefine _MCW_PC)?
However, two more interesting bits of information I found, comparing Intel and Apple Silicon, which seems to hint at calculations using binary64 (double) match but binary32 (single float / 32 bit (24 bit precision)) don't match:
https://eclecticlight.co/2021/04/22/can-you-trust-floating-point-arithmetic-on-apple-silicon/
If so, that would mean the proper fix would be to replace all single floats in the game with double floats.
-
Hello everyone,
wondering if this issue was still being looked at by someone?This post made me remember about it.
https://x.com/lauriewired/status/2113322490219118804Quite related according to https://github.com/FAForever/downlords-faf-client/pull/3504
`There’s a hidden dagger in almost every PC game from 1995-2005 that murders ARM processors.
It’s kind of an accident, and it all has to do with floating points.
x87 was Intel’s floating point extension to x86. I won’t get into all the historical drama, but Intel decided that all internal float math would be at 80-bit extended precision to reduce rounding errors.
Of course, today no one in their right mind uses 80-bit; standard 64-bit doubles are just too convenient. Modern ARM64 doesn’t have any 80-bit hardware!
This creates a nasty problem for emulation. How much x87 arithmetic can you replace with say, native ARM64 floating point (losing precision!) without breaking behavior?
It’s not so simple; dropping 16-bits of precision can cause funny physics glitches and such. But boy, if you need all 80-bits, the software fallback REALLY stinks.
With all the decomp/recomp hype lately, porting OG Xbox and PC games to mobile / ARM devices is extra tricky. Not impossible, but you’d be amazed at how much x87 code is in old games!`
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login