+- Dolphin, the GameCube and Wii emulator - Forums (https://forums.dolphin-emu.org)
+-- Forum: Dolphin Emulator Discussion and Support (https://forums.dolphin-emu.org/Forum-dolphin-emulator-discussion-and-support)
+--- Forum: Development Discussion (https://forums.dolphin-emu.org/Forum-development-discussion)
+--- Thread: Compiling Win32 ARM64 (/Thread-compiling-win32-arm64)
RE: Compiling Win32 ARM64 - Gerdya - 05-15-2018
(05-14-2018, 08:24 PM)degasus Wrote: Maybe we violate something in the ABI specs and some windows syscall overwrites our stack. We use the stack in a non-common way, with propper stack guards or anything similiar.
Yes indeed - at the moment i am trending to some data corruption, either globals or stack.
Currently i am writing out 2 kind of logs:
[color=#000000]1) [/color][color=#000000]e:\dolphin-master-org\dolphin\source\core\core\powerpc\jitarm64\jit.cpp:562 D[JIT] ....along with full PPC state.[/color]
From what i understand this log is written each time a new Jit-Block is generated.
[color=#000000]2) [color=#000000]e:\dolphin-master-org\dolphin\source\core\core\memtools.cpp:39 N[JIT]: EXCEPTION: CODE:c0000005 ACCESSTYPE: 0 BADADDRESS:00000002CC005020[/color][/color]
T[color=#000000][color=#000000][color=#111111]his is written on each exception and is typically handled by fastmem_handler, which inserts a trampoline to the proper C-functions - i intensively reviewed most of the code and could not find anything suspicious.[/color][/color][/color]
[color=#000000][color=#000000]The crashes happens undeterministically. Sometimes it runs for up to 3000 log lines and literally one run later i crashes after log line 400 or so....and from quick checks up to this everything is ok/identical. So it must have something to do with address layout ,which is different each run (i guess partly due to ASLR).[/color][/color]
[color=#000000][color=#000000]My biggest problem, since each crash is different, i cannot set proper breakpoints beforehand - and after the crash i do not have much insights what happened.[/color][/color]
[color=#000000][color=#000000]I assume i need to write out much more logs/traces...any idea which would be helpful?[/color][/color]
RE: Compiling Win32 ARM64 - Gerdya - 07-16-2018
After Microsoft released the remote debug tools for ARM64 i went back to debug my issue.
I am happy to report that i have found the issue:
In JitArm64_BackPatch.cpp
Code:
m_fault_to_handler.erase(slow_handler_iter);
emitter.FlushIcache();
ctx->CTX_PC = (u64)slow_handler_iter->first;Rootcause:
slow_handler_iter->first is accessed after element has been removed from the std::map.
Issue was that PC got randomly (rarely) a wrong value and crashed after return from exception.
After doing the erase operation after updating the context JitARM64 is working now for Windows!
*cheers*
RE: Compiling Win32 ARM64 - JMC47 - 07-16-2018
Great to hear!
RE: Compiling Win32 ARM64 - degasus - 07-16-2018
Nice. Do you want to open a PR for this bug? I've already dropped the plattform register, so upstream should be close to working already.
Edit: You should rebase your branch. This bug has been fixed a month ago: https://github.com/dolphin-emu/dolphin/pull/7033
RE: Compiling Win32 ARM64 - Gerdya - 07-17-2018
(07-16-2018, 05:20 PM)degasus Wrote: Nice. Do you want to open a PR for this bug? I've already dropped the plattform register, so upstream should be close to working already.
Edit: You should rebase your branch. This bug has been fixed a month ago: https://github.com/dolphin-emu/dolphin/pull/7033
Thanks for the hint! This fix must have gone into the code shortly after I decided to wait for remote debugging support...
Positive things first. ARM64 version is running great and stable under Windows with Snapdragon 835 SoC using Direct3D/XInput/XAudio2.
Getting 60 fps with 2x native resolution in quite a few games like: Soul Calibur 2, Burnout, Viewtiful Joe, Rayman 3. RE4 is also running fullspeed @30 fps - all with perfect sound.
As comparison Viewtiful Joe was running with 16 fps with cached interpreter before
Did a pull a and merge...now for some reason WxWidgets is removed from externals - likewise the main project is now Dolphin_QT
Does this mean I need to get hold of QT framework and compile this externally?
RE: Compiling Win32 ARM64 - Helios - 07-17-2018
(07-17-2018, 08:03 AM)Gerdya Wrote: Does this mean I need to get hold of QT framework and compile this externally?
Yes.
RE: Compiling Win32 ARM64 - Gerdya - 12-01-2019
(07-17-2018, 08:42 AM)Helios Wrote: Yes.
Hi all,
after the move to QT I stopped working on this as i had bigger issues compiling QT and was running out of spare time. However since i had some spare time recently i was working on QT again and i have it now compiled for ARM64.
In addition i grabbed the latest Dolphin sources and it compiled without any issues - seems like all issues i had last year are gone by now. It runs fine as well - tested on HP ENVY X2 and Surface Pro X.
Can anyone help me with upstreaming the changes? It is mostly Visual Studio project file related with only a few (like 10) of source files changed. Ideally i would like to just zip the changes without going via public repo and pull-request but if thats not possible i will be trying to go the public repo path.
Gerdya
RE: Compiling Win32 ARM64 - MayImilae - 12-02-2019
Things are a little different now: https://github.com/dolphin-emu/dolphin/pull/8495
RE: Compiling Win32 ARM64 - Gerdya - 12-02-2019
(12-02-2019, 12:24 AM)MayImilae Wrote: Things are a little different now: https://github.com/dolphin-emu/dolphin/pull/8495
Not so cool. Seems someone already pushed some ARM64 changes to the project files like 5 days ago - while apparently also upgrading platform toolset and compiler to VS2019. This pretty much mean my commits would be conflicting.
RE: Compiling Win32 ARM64 - dampflokfreund - 12-02-2019
So an ARM64 build of dolphin is in development right now? That's awesome! Will be great for future ARM users.