[Build] Add Windows ARM64 support #2258
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Wunkolo
force-pushed
the
arm64-windows
branch
2 times, most recently
from
1f74da1 to
6f8cc82
Compare
Separates the `Windows` platform into `Windows-x86_64` and `Windows-ARM64`. Adds `--arch` argument to `build`. Removes x64 backend on non-x64 targets.
Marked as TODO for now
Adding the `a64` backend will be a different PR. For now it's stubbed to the null backend to allow the main executable to open without failing initalization.
|
Stubbed the Null CPU-backend on ARM64 to get the main application running. The new Arm64 backend( |
This value is currently returning `0` on ARM machines and throws an exception.
|
Dear @Wunkolo, congrats on this great leap in (portable) Xbox emulation! Perhaps you could point me towards my missing puzzle piece. compilation log: |
Addresses a build issue that seems to occur now that xenia-app is not getting SDL2 through one of its submodues
|
Just pushed a fix that should address the SDL linkage issue! |
|
Hello @Wunkolo, well it's a (compiling) Bingo 😜:but no (running) Waltz 😒: Have you (already) adapted the paths and filenames to ARM yet? Thanks for the quick reply and ongoing efforts. |
|
You are currently still compiling an x64 build at the moment. It will still compile x64 by default. If you want to build the ARM version you have to set the build-target to the ARM64 version when building from Visual Studio. When compiled, build artifacts will be found within the |
That makes a lot of sense. Restarting the batch file with: leads to ARM64 results: But a few libraries (SPIRV & ImGui) complain, about beeing double defined/linked:Let me fire up the Visual Studio GUI, as that will output all English text results. |
|
Here are the three failed projects ( 
MSVC log |
|
Not sure what's happening here in particular. I can't seem to recreate it locally in Debug or Release in the case that these are LTO issues. |
|
Hi team, Thanks again for all the work on ARM64 support! I’ve been following both this PR and #2259 closely. Just wanted to check is the current state of these branches stable enough to attempt a test build of Xenia on a Windows ARM64 device (Snapdragon-based)? Or would you recommend waiting until further integration or fixes are in place? Appreciate any guidance on whether it’s a good time to try building and testing locally. Regards, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Separates the
Windowsplatform intoWindows-x86_64andWindows-ARM64.This is dependent on xenia-project/FFmpeg#8
Windows-x86_64builds as usual and is the default target whileWindows-ARM64breaks in expected x64-specific areas.Implements some basic build support for Windows on Arm:
