Glad you found the PR useful, @kjliew.

My original hack was unnecessarily slow due to brute-force invalidation of the entire cache region every time, and I made it a bit smarter with https://github.com/dosbox-staging/dosbox-staging/pull/1072, if you're interested.

There was also an experimental tweak I made that dramatically sped up several titles such as Frontier: First Encounters in commit https://github.com/dosbox-staging/dosbox-stag … ef22e1aaa815c26.

If you do come across M1-related issues with specific titles, feel free to drop a ticket in our repo.

Thanks @valuedcustomer.

As a temporary hack, I think the PR is good enough. It's simpler and does not mingle with inner implementation of core_dynrec.

Well, I come to understand why DOSBox devs is taking their time. 😉 Here's the comparison data between x86_64 and AArch64 with MDKDOS.

1 @max 105%  | normal | dynrec | dyn-x64 |
2Ryzen 2500U |  25    |  42    | 475     | pristine r4459
3Apple M1    |  43    | 110    | n/a     | pristine r4459 Rosetta2
4Apple M1    | 105    | 218    | n/a     | r4459 with hack

If there was no dynamic_x86 or @jmarsh didn't come up with dynamic_x64, then Apple M1 would have blown any x86 out of the water with just normal core. Frankly, 90% of DOS games just need normal core on x86. Dynrec core was nice on x86 and 64-bit ready, but M1 is truly a beast. And, those scores didn't take real screen pixels into consideration. The Ryzen has the advantage of just a 1080p screen with 1:1 display scale. The M1 would have pushed lots more pixels with the retina screen.

Oh please, Intel/AMD don't cry... 🤣 And, when can we have the next AArch64 SOC not from Apple for Windows/Linux on ARM laptops?

Or, shall we say "32-bit emulators are dead"?! 😉

The hack didn't touch anything on core normal, I believe. Normal should just be the same and dynrec does not work on pristine r4459 without the hack. So the scores are 105 and 0 if you would complete the chart.

I would be more interested to have more recent x86 implementation such as Ryzen 5000 and Intel 11th- Gen into the chart but I have none of those.

I am still puzzled why dynrec targeting x86_64 is so slow compared to dynrec targeting AArch64. I wouldn't have thought dynrec was capable of matching QEMU TCG performance in AArch64 and apparently I was wrong. I am curious if this would be the same between DOSBox dynrec and QEMU TCG on other non-Apple AArch64 implementation such as the RPi4, RockPi64 and OROID.

Kudos to @jmarsh! Similar to how x86 virtualization saving the grace of x86 CPUs for QEMU, his master piece dynamic_x64 saves the grace of x86 CPUs for DOSBox. 😉

If anyone has other ARM SBC at hand to post similar data for academical assessments, please be my guest. Thanks!

I have to say that CPU core dynrec on Apple M1 is simply amazing. Though it is not faster than dynamic_x64 with Rosetta.2 translation, being native AArch64 is always more future-proof. A similar concern on dynamic_x86 was there before the CPU core was overhauled to be 64-bit ready. Kekko's Voodoo chip emulation was so fast with CPU core dynrec that it made me slacking in bringing up OpenGlide for Glide pass-through. I don't remember CPU core dynrec was that good ever on any x86 CPUs in the past even with Core i7-6600U IIRC which forced me to keep MSYS2/mingw-w64-i686 or bloating up my Linux installation with 32-bit libs to just have DOSBox. CPU core dynrec couldn't play 3Dfx DOS games such as Tomb Raider 1 and Screamer 2 at 30 FPS. The same perception had made me skeptical towards having DOSBox on ARM SBCs to play games.

The Apple M1 experience had shaken off all such believes. Tomb Raider 1 locked at 30FPS, Screamer 2 raced at all-time smooth and Blood 3Dfx frag at absolutely zero lag. No stuttering or audio crackling from all those games. And, Kekko's Voodoo emulation has the advantage of running static linked 3Dfx DOS games. Battle Arena Toshinden just played flawlessly. OpenGlide also suffers several issues with Apple OpenGL that games such as Screamer 2 and Blood 3Dfx do not work on QEMU Glide pass-through on Apple M1 (which I have no idea how to fix/debug them because Windows & Linux work just fine).

The only problem is that Voodoo chip emulation cannot play in windowed, it is too small on retina screen and Voodoo chip emulation can't scale to match DOSBox. Everything becomes little tiny square. Fortunately, SDL1.2 fullscreen mode switching works and one can just play all 3Dfx DOS games in fullscreen. Apple macOS Big Sur even has the way to save & restore states of desktop layout in & out of fullscreen mode switch. Into fullscreen, the games stretched up and filled the retina screen with black bars on both sides to keep the aspect ratio at no cost. I think most would have loved to play 3Dfx DOS games this way. 😉

So I guess I will also take my time for DOSBox Glide pass-through with OpenGlide. 😉

I need to test this! (@kjliew I was sound asleep when you pinged me on irc 😀)
The most important test is whether I can codesign and notarize it with entitlements so it actually works on other machines. It wouldn't work with another path we took back a while with the DTK.

To work around SDL 1.2x limitations, the SDL12compat project has seen tons of improvements that work nicely on an intel macOS.

@Dominus, can you help to fill the chart for DOSBox M1 with Rosetta 2?

EDIT: Chart filled.

Shadow Warrior USA with BUILD_FPS=1 for performance stats measurement
Native AArch64 DOSBox SVN CPU core dynrec with Kekko's Voodoo chip emulation.

QEMU won't be able to play this game with Glide pass-through, so DOSBox SVN just fill the shoes then. 😉
It was captured in windowed 800x600. Fullscreen mode 640x480 will have better FPS. It is still too small to play at 800x600 in retina screen and 800x600 fullscreen mode switch seems to be broken in macOS Bug Sur or Apple just didn't care to emulate it properly. I think external standard display should work in windowed, but I don't hook up mine with any.

Apple M1 rosetta2: normal 43, dynrec 110
pristine r4459

Now I need to build the hack myself to see how that compares on my machine 😀

Dominus wrote on 2021-07-16, 15:56:

Apple M1 rosetta2: normal 43, dynrec dynamic_x64 110
pristine r4459

Interesting, I believe the Rosetta 2 should be dynamic_x64 compiled as x86-64 and translated. So native AArch64 dynrec is actually faster, that is yet another surprise.

Dominus wrote:

Benchmark PCPbench: iMac Pro 3 GHz, Core 10 Intel Xeon: 167 fps MacMini 2.5 GHz, Dual-Core Intel Core i5: 105 fps MacMini M1 (Ro […]
Show full quote

Benchmark PCPbench:
iMac Pro 3 GHz, Core 10 Intel Xeon: 167 fps
MacMini 2.5 GHz, Dual-Core Intel Core i5: 105 fps
MacMini M1 (Rosetta2 emulation): 127 fps

How was that possible in your other post? Did you have display scaling on MacMini M1? Or, perhaps it was the Apple M1 8-core GPU that was doing the wonder and the MacMini better thermal budget compared to MacBook Air.

Can you also redo the PCPBENCH benchmark between native AArch64 and Rosetta2 on MacMini M1?

Interesting...
native M1 with this patch:
mdkdos: dynrec 232 (but on the very first run after starting DOSbox it goes up to 340-354), normal 107
pcpbench: dynrec 93, normal 33

rosetta2 64bit build:
PCPbench dynrec64 127,5, normal 23,7

But all this with output surface, your opengl fix doesn't seem to fix it, only makes it "different" to what was the problem before.

Dominus wrote on 2021-07-16, 19:52:

But all this with output surface, your opengl fix doesn't seem to fix it, only makes it "different" to what was the problem before.

So how did it look when you removed the OpenGL fix?

I think that is "the fix", so I also have this to scale up all VGA games nicely.

1windowresolution=2048x1280
2scaler=none

I have `output=opengl`. Otherwise, `output=surface` caused crackling in Munt MT32 audio in games such as GODS and LSL3 which I don't know why. For both games, cycles was set to the default 3000 with normal core, so the audio crackling wasn't due to CPU hogging AFAIU. With `output=opengl` or `openglnb` , it cures all the audio issues even before I had the fix. I don't have audio issues on Ryzen laptop regardless of any output type for those 2 games be it on Windows or Linux. So I would say the OpenGL fix is more critical for DOS games, the dynrec is just for a show. 😉

This is the same for Windows build, too, for high display scaling. Otherwise, it will just be the same tiny rect in windowed for those with Surface 4k panel crammed into 12.2 inch. I used to be able to get DOSBox SVN WIN64 to respect OS display scaling, so a 640x480 will look like 640x480 after display scaling but I couldn't reproduce the build anymore.

ok, tested it again without the fix and opengl works fine just out of the box for me... huh...
So on my MacMini M1 OpenGl works right away. The only thing (that so far has never been an issue) is that the MacMini is not hooked up to any display and is remote desktop controlled.
I did have OpenGl problems on the DTK machine that's why I thought this would still be the case and didn't even test it again and just assumed I'd still have a problem as you wrote you had one (on the DTK the DOSBox window was the right size but the actually displayed part would be much smaller in the lower left part of the window).
This makes this not easier 🙁
The culprit could be the SDL 1.2 you are using... My SDL 1.2 was built from their development version of March 13 2021 against SDK 11.1 with deployment traget 11.1.
And it's NOT using X11 which might be a possible clue since you are relying on X11 for your other stuff.

On intel macOS all other output than opengl was very noticeably slower, btw. Curiously that is not the case via the Rosetta2 emulation, surface is reproducibly only slower by 3 or 4 fps.

That's what I have been yelling *Display Scaling*. If you do remote desktop or Hackintosh on VM, then there is literally no display scaling in action.
If it drives a local retina display, such as the MacBooks, or a 8k/4k panel at 27 inch on the MacMini, then I think you will see the problem. This is not just macOS, it is everywhere, but Linux typically has poor usage of display scaling.

Dominus wrote on 2021-07-16, 21:43:

(on the DTK the DOSBox window was the right size but the actually displayed part would be much smaller in the lower left part of the window).

This was exactly my OpenGL problem before the fix. Are you sure the window size was right? It was only *looked* right because the window was created taking display scaling into consideration while OpenGL rendered at real screen pixels. That's the reason display stayed in the lower-left part of the window.

Dominus wrote on 2021-07-16, 21:43:

This makes this not easier 🙁
The culprit could be the SDL 1.2 you are using... My SDL 1.2 was built from their development version of March 13 2021 against SDK 11.1 with deployment traget 11.1.
And it's NOT using X11 which might be a possible clue since you are relying on X11 for your other stuff.

Unlike for QEMU, my SDL1.2 is pristine version out of HomeBrew. I don't recompile it for customization. It does not rely on X11 at all. If I want an easy way out for Glide pass-through to work for DOSBox with OpenGlide, then I may recompile it for additional X11/XQuartz support. I think it may actually help the situation with display scaling because of X11/XQuartz. 😉

Dominus wrote on 2021-07-16, 21:43:

On intel macOS all other output than opengl was very noticeably slower, btw. Curiously that is not the case via the Rosetta2 emulation, surface is reproducibly only slower by 3 or 4 fps.

Yeah, you're right. all other output than opengl was noticeably slower, even on my Ryzen laptop, but "no one needs more than 30 fps in PCPBench (tm)"... 😉 Munt MT32 BGM matters for DOS games that support it.

I'll try connecting my thunderbolt display next. Might be in a day, though.
And the DTK was also only on remote control, so that part did not change.

In the meantime maybe give a self compiled SDL1.2 from current git a chance, I have no idea at which commit the homebrew version is.

No one thought about installing glew and glfw (as well as freeglut, maybe) from homebrew or compile yourself, to bump OpenGL on macOS from 2.1 to 4.1 ?

Even though you'd still have to (re)link and (re)compile any program that uses OpenGL to benefit from that?

Dominus wrote on 2021-07-16, 22:36:

And the DTK was also only on remote control, so that part did not change.

The DTK was right in every sense by forcing HiDPI handling even through remote control. It was made to behave just like MacBooks with retina display to force the early access development to focus on HiDPI aspects of software development which Apple had always been touting. So you already knew about the problem then, great! 😁

The HomeBrew version is the last official snap 1.2.15 with macOS patches cherry-picked. I believe most systems are doing the same, MSYS2/mingw-w64, Arch Linux, Debian/Ubuntu etc. with their own platforms respective patches cherry-picked. I think going for current git is a bad idea.

I have hooked up my Thunderbolt display and tested all available display options and it just works without your fix and goes wrong with it.
("Default for Display" and "Scaled" with all available modes: 2560x1440, 2048x1152, 1920x1080, 1600x900, 1280x720).

I just checked Brew and it is missing this vital SDL12 commit: https://github.com/libsdl-org/SDL-1.2/commit/ … cdac2636c82ff5f
Totally forgot that this was fixed due to my reporting 😀
So try getting the SDL --head via brew or however that works and your issue might be fixed without messing with DOSBox sources.

You can always make a custom homebrew formulae by modifying the original formulae and run it with "brew --build-from-source formulaname.rb" (must match the same name) to fix it...

I'm sure you already knew it, but I have no clue on how to add that commit to the formulae to be used for build.