WinArm64-MSVC#1910
Conversation
There was a problem hiding this comment.
NOTE: I see that this has now been marked as a draft PR. But since I started reviewing this before then. I hope my feedback will guide you through a compatible solution that can be merged, because I think as-is there's some concerns.
Thanks for making this PR. It would definitely be nice to support windows ARM support in this project, with the assumption that the code is properly written and doesn't increase complexity for other architectures. So the fixes in this PR would ideally be as small as possible, and extend our existing ARM code so that its arm support extends to Windows. I do think this PR is kind of chaotic. From what I can see, a big issue seems to be the assembly, at least with the dependencies. Its preferable if we used the upstream version.
I did see a number of tells that a decent amount of AI usage was involved with these changes. Although its fine to use AI while writing code, we have some hesitations about PRs like this that change existing code in multiple places, potentially affecting other platforms as well. Reviewing code takes a good chunk of time away from working on our own projects within Cemu, and with the increase of AI PRs, we generally will be quite conservative with what to merge.
So, ideally in the next PR, please declare whether you've used AI, and if yes, know that we expect you to understand the changes it has made and whether those changes match the quality of what you or any other maintainer would've written manually. This includes checking the coding guidelines, bundling up unrelated changes and making a precise, targeted PR.
There was a problem hiding this comment.
I think this whole file was rewritten by AI? A lot of changes, removal of comments and making things shorter? I'm not sure what you changed. It seems like a lot of files are now no longer compiled? I would prefer to keep the source code of dependencies the same, if that's possible.
There was a problem hiding this comment.
I wonder if there's some upstream changes that are merged since we forked it. Would be more ideal to not diverge from that source code.
There was a problem hiding this comment.
Did you check if ih264d had any upstream changes to make it compile-able on MSVC ARM?
| SetThreadContext(hThread, &ctx); | ||
| } | ||
| ResumeThread(hThread); | ||
| } |
There was a problem hiding this comment.
You added support for setting the breakpoint registers for the debugger. But when I check the ExceptionHandler_win32.cpp code, I'm quite sure that this is not actually handled? I feel like this should've come up if you had tested it, which would've been nice. You can use the PPC debugger to make a write/read breakpoint in the PPC debugger at some memory address.
Thanks for the feedback. Set this as draft since the Windows on Arm code for MSVC is giving some issues i did not experience with Clang Arm for Windows. Specifically a thread lock when closing Cemu. And interaction between WxWidgets windows and the backend. |
276c226 to
c52b5dd
Compare
c52b5dd to
6a5219f
Compare
| if(MSVC) | ||
| message(STATUS "MSVC ARM64 detected: Forcing portable C implementation.") | ||
| target_sources(ih264d PRIVATE | ||
| "decoder/arm/ih264d_function_selector.c" | ||
| "decoder/arm/ih264d_function_selector_av8.c" | ||
| ) | ||
| target_compile_definitions(ih264d PRIVATE PORTABLE_C ARCH_GENERIC DISABLE_NEON) |
There was a problem hiding this comment.
What's the purpose of this? MSVC should be able to support NEON.
b34c2be to
f368efc
Compare
4 participants
Build Windows on Arm using MSVC