-
Notifications
You must be signed in to change notification settings - Fork 678
General aarch64 improvements & Apple Silicon support #1255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
I'll be honest, it will probably be a while until we have a decent ARM recompiler that will outperform Rosetta so this seems a bit early. But I generally don't want to stand in the way of adding new target platforms. That said, the changes made here are detrimental for other platforms. Just on a quick glance some obvious issues:
|
On OSX, C functions are compiled with a leading underscore and the header files define the ASM functions as a normal C function, resulting in functions being called with a leading underscore but defined without one.
Makes sense, I'll revert that and try something else
Ah, I wasn't sure but that's what I somewhat assumed. |
e9a00d3
to
0328901
Compare
6998fdd
to
ebb249c
Compare
…m64 rather than aarch64 cmake: Fix compiling for Apple Silicon
I've changed the range to accommodate for the Project Zero bug stated however I'm not sure if causes any other issues or if this is used, however it seems to work fine. Please correct me if true.
On Apple Silicon, PPCTimer estimates a terribily inaccurate RSTSC frequency and results in games (specifically tested Color Splash & MK8) run extremely fast especially in the title screens which unsurpisingly doesn't work that well. The value hardcoded is the same frequency as on Rosetta. Admittedly this probably isn't the best solution however it is accurate and it works.
"A MenuItem ID of Zero does not work under Mac"
Despite being disabled in InitBlendState, this still causes errors on MoltenVk, so just skip it altogether Seemingly fixes cemu-project#396 (there's a multitude of errors there in the comments, specifically referring to the issue), however I don't own BOTW and can't confirm
Apple seemed to not have offsets for arguments on the stack Either that or the offsets were just wrong, I'll test on a Linux VM and remove the conditonal if this still happens
dependencies/ih264d/common/armv8/ih264_intra_pred_luma_8x8_av8.s
Outdated
Show resolved
Hide resolved
Co-authored-by: neebyA <[email protected]> Revert "Update ih264_intra_pred_filters.h" This reverts commit 0ac296d. Revert "Update ih264_deblk_edge_filters.h" This reverts commit 0e48f86. Revert "fix CI on windows" This reverts commit 2ccb5dd. Revert "fix compiling on x64" This reverts commit 99378f1. Revert "update ih264d macros" This reverts commit 0924e11. Revert "ih264d: Modify to compile with AppleClang & for M1" This reverts commit d2a9c31.
This reverts commit e6e65af. Superseded
Co-authored-by: neebyA <[email protected]>
This comment was marked as resolved.
This comment was marked as resolved.
@neebyA Try changing the start of the loop to this as a workaround:
I am not familiar with macOS development so I am not sure what the best strategy is in regards of which xcode version to target. But in general I am against bumping a compiler version when something can be worked around easily. |
Co-authored-by: Exzap <[email protected]>
I used @Exzap 's workaround in order to avoid said issue, and it seems to compile fine. Otherwise, with the addition of the aarch64 recompiler, this PR is essentially done. I haven't done much testing, from what I've tested it seems to run smoothly with no new issues and the only real difference I've noticed being that the arm64 seemingly has less lag spikes, whereas under Rosetta it would stutter while compiling shaders, but otherwise it's seemingly the same. (though Rosetta already ran at 60/30 fps on the games I tested, so any performance improvement wouldn't be noticeable) |
I suggest building a universal version would be better, to avoid distinguishing between x86_64 and arm64 versions. After all, the universal version can run directly on both x86_64 and arm64 platforms. Moreover, on arm64 platforms, the universal version can switch to running the x86_64 version through the Rosetta 2 option. |
The re-compiler hasn't been implemented and only the interpreter works. (and there's already an WIP aarch64 recompiler for cemu android, assuming that they plan on merging into this repo)
Closes #1490