ARM64 (aarch64) DRC backend #13162
ARM64 (aarch64) DRC backend #13162
Conversation
|
I’ll take a look at this when I get a chance. |
|
A small note about my experience cross compiling for Raspberry Pi: I had to change the |
|
What happens on 32-bit arm? Looking at the makefile and genie scripts changes, it looks like arm64 backend would get built. Is this what we want? |
|
It shouldn't do anything on 32-bit. asmjit only supports aarch64. |
I know. But looking at makefile changes, c backend is no longer forced if On an odroid HC1 NAS as follows: |
|
That doesn't mean it won't use the C backend though. On MacOS it matches using the |
|
MIPS: gauntleg shows an out of memory error with the AArch64 BE but -drc_use_c boots fine. Also sfrush, calsped, and mwskins - same error. (The error is shown by the game, not MAME). PPC: scud doesn't boot without -drc_use_c. |
|
ppctest results: Mismatch: instr=MULLW., src1=0x80000000, src2=0x80000000 Mismatch: instr=MULLWO., src1=0x80000000, src2=0x80000000 |
987123879113
force-pushed
the
drc_arm_pr
branch
from
fd7af38 to
cc4bafa
Compare
|
Fixed some more multiplication errors in addition to the ones AJR commented. That fixes the Midway/MIPS-based games RB mentioned. Also tried to emulate the call stack similar to how the C backend does it so that mapvars can be recovered properly which fixes |
|
@seleuco you might want to take a look at this, as ARM CPUs are the predominant targets for Android builds. |
Yes. I was already aware of this pull request. I will start testing and will report back to you. |
|
Next up: pmac6100. -drc_use_c will show the mouse pointer and flashing disk, aarch64 loses track of the return address during an exception and crashes to PC=0x00000004. (And to clarify, you don't need any of my WIP changes to the driver to get that). |
|
@rb6502 More mapvar/recover issues. The callstack depth wasn't actually storing the new depth so it would overwrite the hashstacksave pointer sooner than it should've. I tested the previously mentioned |
987123879113
force-pushed
the
drc_arm_pr
branch
from
e3af311 to
f0e0561
Compare
|
Confirmed full functionality in pmac6100 with that change. I think this is good to go in terms of my regression testing now. |
|
I've successfully cross-compiled the pull request and tested performance on these Android devices without any problem at first sight: Qualcomm Snapdragon 685 (low-midrange; Geekbench 6 single core: 473)
Qualcomm Snapdragon 8 Gen 2 (high-end; Geekbench 6 single core: 1595)
A build with these changes is available for testing: https://drive.google.com/file/d/1aJcKK-ugzOzx_f5ridu-nPR3qnbFDYaC/view?usp=sharing I don't plan to publish anything until the next version of MAME that includes these changes, obviously. |
|
@seleuco Thank you for testing and providing benchmarks. Those are some really significant improvements for Android. |
|
I am happy to report this PR is working fine on a Windows ARM64 device with a Snapdragon X Elite CPU.
I was just looking at the makefile with the intent of streamlining Win/ARM64 builds, and I think I can shed some light on this. macOS ARM64 builds use this target: ...whereas Linux ARM64 builds use this generic target: The macOS recipe passes Interestingly, the This leaves me with a couple of questions:
The answers should clarify the right thing to do in this PR. |
|
I'm unable to compile this via My build environment is here: If I remove If I try the trick above of replacing GNU gold produces similar output. The asmjit documentation suggests that Interestingly I see that I'm out of my depth here a bit, but it almost feels like asmjit isn't picking up the cross-compile environment and arm64 target instructions, and things are getting confused at compile/link time. Other than the linker errors, there are no compile time errors relating to asmjit or drc or anything similar. I'll keep poking at it, but I'm running out of ideas on what to try next. |
You're probably getting the linkage error because you haven't modified the script in 3rdparty.lua and you haven't removed "configuration { "x64" }" there as well. But that's not the way to go. The real problem you're having is that you're not running a rule that calls config=$(CONFIG)64 so the x64 configuration isn't being selected. I personally haven't checked the Linux aarch64 target so I don't know where the problem is right now. You definitely need to avoid NOASM=1 because it forces the use of FORCE_DRC_C_BACKEND no matter what you do and asmjit won't be included. |
|
@danmons seleuco is right, it's due to the same issue with the config string stuff. That'll eventually need to be address for this PR I think but I'm not very comfortable with makefiles and genie and such so it'll have to be discussed and decided on how exactly to approach that. Having said that, I was using your build environment (inside Docker) and with some changes I did get it to work with the DRC after a few failed attempts. Here's the .patch file I made for testing with your Docker build environment: diff --git a/scripts/genie.lua b/scripts/genie.lua
index bcdbc82236f..f6a5abc5486 100644
--- a/scripts/genie.lua
+++ b/scripts/genie.lua
@@ -711,11 +711,10 @@ end
if not _OPTIONS["FORCE_DRC_C_BACKEND"] then
if _OPTIONS["BIGENDIAN"]~="1" then
if (_OPTIONS["PLATFORM"]=="arm" or _OPTIONS["PLATFORM"]=="arm64") then
- configuration { "x64" }
+ configuration { }
defines {
"NATIVE_DRC=drcbe_arm64",
}
- configuration { }
else
configuration { "x64" }
defines {
diff --git a/scripts/src/3rdparty.lua b/scripts/src/3rdparty.lua
index e56665ef121..6466637d760 100755
--- a/scripts/src/3rdparty.lua
+++ b/scripts/src/3rdparty.lua
@@ -1949,7 +1949,7 @@ project "asmjit"
}
if (_OPTIONS["PLATFORM"]=="arm" or _OPTIONS["PLATFORM"]=="arm64") then
- configuration { "x64" }
+ configuration { }
defines {
"ASMJIT_NO_X86",
}
diff --git a/src/devices/cpu/drcbearm64.cpp b/src/devices/cpu/drcbearm64.cpp
index 5a895392852..6e0b989b8b8 100644
--- a/src/devices/cpu/drcbearm64.cpp
+++ b/src/devices/cpu/drcbearm64.cpp
@@ -826,6 +826,8 @@ drcbe_arm64::drcbe_arm64(drcuml_state &drcuml, device_t &device, drc_cache &cach
, m_baseptr(cache.near() + 0x80)
, m_near(*(near_state *)cache.alloc_near(sizeof(m_near)))
{
+ printf("Using ARM DRC\n");
+
// get pointers to C functions we need to call
using debugger_hook_func = void (*)(device_debug *, offs_t);
static const debugger_hook_func debugger_inst_hook = [] (device_debug *dbg, offs_t pc) { dbg->instruction_hook(pc); };And also removed The printf there in drcbearm64.cpp was to be sure it was actually using the ARM DRC. My guess is you need to also edit |
I don't think I was clear on that - yup, Thank you both for the notes. I'll try them out shortly. [edit] Ooh yeah that sorted it. Running all of these with |
|
I have tested some games out on my Ayn Odin 2 Pro and i have seen a lotta small and big improvement in performance for games that ran poorly on MAME4droid or a lil jump in speed. Here are links to my tests for the ARM64 beta for MAME4droid. Panic Park - https://youtu.be/025FNrFFo6M?si=XLUwAjCc8GycoIl5 AYN Odin 2 Pro Specs RAM: 12GB |
Philosophically, I’d say that Linux and Windows systems, where 32-bit ARM binaries are supported, should probably be using a *64 configuration for AArch64 builds. However, macOS no longer supports 32-bit applications at all, so there may not be any point keeping the *64 there. |
|
FYI, the latest Windows 11 feature update (24H2) dropped support for 32-bit ARM applications. |
|
I pushed a change that I think should probably clear up the build issues. I tested macOS (which reports |
987123879113
force-pushed
the
drc_arm_pr
branch
from
5d891f2 to
5683a37
Compare
What happened to Microsoft’s famous backwards compatibility? |
I think that not Microsoft decided. Edit: |
987123879113
force-pushed
the
drc_arm_pr
branch
from
f14c9b2 to
7ac5cf4
Compare
987123879113
force-pushed
the
drc_arm_pr
branch
from
d5fdae1 to
88acdd8
Compare
It's a big PR. I've done my best to make it work but I'm sure there are still bugs or questionable implementation choices. It passes all of the same tests I was doing for the previous DRC changes so I think the outputs should be the same as the other DRC backends.
Additional testing and/or misc feedback like benchmarks on various devices would also be appreciated. For hardware I've tested with an M1 Pro CPU and a Raspberry Pi 4 Model B. For software I've been testing using a few games on the Naomi (SH4), Firebeat (PPC), NWK-TR (PPC), and some very small testing of dgpix (Hyperstone E1-32XT).