@kcgen

I would rename this PR as "Add game mode support for macOS Sonoma or newer" or similar. If supporting the game mode causes problems then its easy to find out when that was added.

@Burrito78

@Grounded0 > would be nice to see PERFDOS score with that enabled

👍

The updated manifest was accepted as part of the .dmg packaging.

(As this is a recommended tag to categorize an application, it seems useful regardless of the test results)

This should be documented in 0.81 release notes so tagging this with documentation.

PERF_DOS.EXE gives 370 with latest DEV version and 225 using this build.

EDIT: After a lot of testing I can say that both DEV and this PR can get low (220) or high (370) numbers, it happens randomly.

Game Mode works though...mmm.

😂

@Burrito78

Can you plug your computer to charger and try again.

Quake

DEV
Run 1: 181 fps
Run 2: 151 fps
Run 3: 149 fps

This PR
Run 1: 128 fps
Run 2: 115 fps
Run 3: 114 fps

It would be interesting to find out what causes it to drop that much exactly.

I think we can scrap that feature currently. :(
EDIT: Not so clear after further testing, problem seems to lie elsewhere.

EDIT: This was on battery too - but it shouldn't be that much worse.

@Burrito78

Can you plug your computer to charger and try again.

Yes, will rerun both benches tomorrow on the M2 mini.

I always warn people not to run macOS releases until they hit xx.6.

Amazing, @Burrito78.
This is literally just a change in the MacOS manifest.

"Of course frames rates are lower, but we deliver them at tighter latencies" 😅

Keep the test results coming :-)

We can leave this PR open until @apple fixes the game mode on macOS Sonoma. Still want more data points so calling all macOS 14.x/Apple silicon users to test this out and report back benchmarks.

For the record, I was forced to upgrade to Sonoma yesterday too (company laptop).

It gets weirder and weirder.

Machine: Mac mini 2023 / Apple M2
OS: macOS Sonoma 14.0

All benchmarks run in fullscreen mode with default config except vsync.

Shiny PERF_DOS.EXE v1.4
			vsync = auto	vsync = off	vsync = on 
Main DEV		223		221		10
PR Branch		223		225		30

Quake SW 1.06
			vsync = auto	vsync = off	vsync = on 
Main DEV		175/148/148	117/96/96	4.3/-/-
PR Branch		119/99/98	119/97/98	9.3/-/-

Shiny Benchmark 1.4: https://daryldixonretro.111mb.de/Sonstiges.html
Quake SW 1.06: https://archive.org/details/Quake_802

@johnnovak

Can you run game mode benchmarks on your Sonoma when you have time. Need more data points. Do note that game mode requires Apple silicon hardware.

Shiny Benchmark results for different versions, five runs in short order.
Default config for all

DEV	0.80.1	PR
375	389	225
222	236	224
376	388	223
375	232	224
223	233	224

@johnnovak

Can you run game mode benchmarks on your Sonoma when you have time. Need more data points. Do note that game mode requires Apple silicon hardware.

At some point yes, but I'm quite busy now, then offline for 3 weeks from Wednesday.

@Burrito78 : looks like thermal throttling.

After five back-to-back runs, all versions were getting the low ~220 score.

Game mode will unfortunately accentuate this by running the CPU and GPU in their most power-hungry modes.

If you search for m2 throttling, there are reports about people getting defective systems that run really hot and slow. They replaced them, and the problem is fixed.

It looks like the m2 studio has a better cooling system; perhaps it wouldn't throttle?

Other benefits of game-mode would be that the performance and power are fully dedicated to the game, and not to other wasteful power hungry applications.

So you could try running something like the multi-core Geekbench test in the background, and then simultaneously run some dosbox benchmarks; maybe this is where game-mode will pull out some wins?

PERFDOS/Shiny has no time limit so it can be left running for 30 minutes and then you get 30 minute average of the performance. That's a good way to test if thermal throttle affects performance.

If Mac Mini M2 posts weak results like those after 30 minutes of PERFDOS/Shiny it should be returned to seller for potential hardware defect. Thermal dissipation system should be fully up and running by then and would have no problem keeping it in thermal limits.

Running for 30+ Minutes, no throttling happening.

Those graphs help, thanks @Burrito78.

Is it possible to get the same charts across a 5 min run of the PR while in game mode the entire time?

I'm very curious if or how game mode influences the clock frequency ramping behavior.

What we're seeing in the existing screenshots is Apple's CPU scheduler drip-feeding slightly increased CPU frequency (over and over, a bit more each time) combined with DOSBox's auto-cycler detecting and using those new, slightly higher CPU frequencies by ratcheting up the auto cycle count.

When the Shiny benchmark score finally grinds its way to the peak of 370, that's when Apple's scheduler is also giving it the peak CPU frequency.

My guess is that there's some slightly different dynamic at play in game-mode.

Is it possible to get the same charts across a 5 min run of the PR while in game mode the entire time?

This is the PR running at full 370 for 5 minutes.

At the first dip i switched to windowed to see how much time is left on the graph an switched back to fullscreen.
On the second dip i switched to windowed mode permanently (game mode switches off).

Thanks for that last screenshot, @Burrito78 !

This is the PR running at full 370 for 5 minutes.

Do you know what changed? (maybe, cycles = 105?)

In the previous DEV screenshot, the CPU speed only briefly crested 3 Ghz:

Where as the PR + game-mode ramped faster to ~3.2 Ghz, and scored a full 370 (and probably got there faster):

I think the solution is to try to make DOSBox's auto-cycler, specifically in cycles = max, more demanding and clearer to the host CPU scheduler. By demanding, I mean trying to consume 100% duty cycle from the host faster and with fewer calls to sleep().

Do you know what changed? (maybe, cycles = 105?)

Nothing changed, it's random if it will get high or low fps.
It's just so that the PR build -for whatever reason- gets high fps less often than DEV currently.

It's just so that the PR build -for whatever reason- gets high fps less often than DEV currently.

Yeah; that's definitely worse!

Let's see if game-mode is helpful again competing load.

In a separate terminal, paste this in to simulate a competing load on all cores:

while true; do /usr/bin/openssl speed -multi $(($(nproc) * 3)) &> /dev/null; done

With that running, see if the PR game-mode fullscreen can produce better scores than DEV fullscreen.

@kcgen macOS doesn't have 'nproc'. Can you hardwire the command line to 4 or 8?

(Oh, I'm using nproc from HomeBrew; sorry!)

Yes - use three-fold num-cores (yes, we want to oversubscribe CPU demand); so 30 in your case:

while true; do /usr/bin/openssl speed -multi 30 &> /dev/null; done

• I expect DEV to run very badly, scoring 1/3rd or less.

• If game-mode is a competent butler, it'll adjust priority and give openssl only table scraps while DOSBox feasts like a king and runs almost as fast as normal.

macBook again, but plugged-in this time. :)

DEV with stresstest, started benchmark after a short while after being sure that I was getting "high" numbers:

PR with stresstest, 5 Minutes, only minimized for screenshot:

The numbers of this benchmark are not very stable, btw. Can't be an average over the whole time for sure.
So take the numbers in the screenshot not as an absolute result.

Apple says this about game mode:

Game Mode optimizes your gaming experience by giving your game the highest priority access to your CPU and GPU, lowering usage for background tasks. And it doubles the Bluetooth sampling rate, which reduces input latency and audio latency for wireless accessories like game controllers and AirPods.

I don't see any negative impact and we can't test every advertised aspect of it.

Currently I'm seeing two issues here for which I think we should have separate tickets:

-Benchmarks randomly show either high or low performance on macOS.
-'sync = on' is currently broken on macOS (Sonoma?), see the table:
#3016 (comment)

Thanks @Burrito78 - will have a follow up commit switching to adaptive vsync, to solve the second point.

Updates with newest PR build including 'adaptive sync'.

Mac mini 2023 (M2)
 / Sonoma 14.0

All benchmarks run in fullscreen mode with default config except vsync.
I started the benchmarks multiple times to make sure i’m always in the „high fps“ mode (this is currently a Staging or macOS bug).

Shiny PERF_DOS.EXE v1.4

			vsync = auto	vsync = off	vsync = on 
Main DEV		377		375		7
PR Branch		379		378		232

Benchmark with latest changes on a separate machine and i'm happy to sign this off if we make sure release notes bring up that we use game mode by default on Sonoma or later as per Apple guidelines. Anyone who doesn't like this behaviour can comment off that line from their Info.plist.

Pinging @kklobe if he's happy with these changes.

Thanks @Burrito78.

Edit: based on feedback from @GranMinigun , the PR now exposes OpenGL's actual vsync = adaptive mode, which I've found works better on macOS.

macOS's OpenGL drivers appear to excessively block when non-adaptive vsync is used (ie: vsync = on), which you discovered with those crushingly low PERF benchmark scores above.

So to address that, this PR adds a new condition for presentation = auto condition specifically for macOS to prefer CFR in these cases -- because otherwise the result is essentially unusable, like you found.

So let's put it all to the test. I've tested this on macOS and Linux. Hopefully we can get some result from more systems.

Vsync Test Pack

📁 vsync-pack.zip - rev2

Each game comes with an included dosbox.conf.

Open your terminal, enter the game's directory, and launch your DOSBox Staging build with the --noprimaryconf flag.

For example:

cd dangerous_dave-60Hz-EGA-VFR
/path/to/dosbox-staging/dosbox --noprimaryconf
cd .. 

Dangerous Dave (EGA, 60 Hz, VFR)

• The intro sequence has a huge static image that pans left to right, which should be free from mid-frame tearing or displacement.

Jazz Jackrabbit (VGA Mode X, 60 Hz, VFR)

• In-game frames are rendered at variable rates depending on what's happening.
• The background should be tear-free when running and jumping.

Keen (VGA, 70 Hz, VFR)

• The intro sequence has huge scrolling graphical text plus vertical scrolling credits.

• The vertical lines should be free from mid-frame tearing displacement, and the credits should be smooth without juddering.

Pinball Dreams (VGA, 60 Hz, CFR)

• Let the intro splash screens go by until credits scroll vertically. Watch for signs of vertical judder.
• At the game selection screen, press F4 for the Nightmare board.
• When the board is panned vertically, watch for tearing and judder.

Try testing full screen and windowed-mode.

Does the PR branch have any regressions versus main?

Hopefully we can get results on all platforms to confidently answer this.

@kcgen How about automatically setting 'vsync = adaptive' on macOS if 'vsync = on' is used? I'm thinking about existing conf files here. This should be indicated in logging of course to prevent confusion.

Or are there cases where 'vsync = on' actually makes sense on macOS?

Tested your pack on macOS Sonoma 14.0 using included confs.

Dangerous Dave: PASS
Jazz Jackrabbit: PASS
Keen: Horrible slowdowns/audio stutters, the box in the top left isn't steady but moves when keen moves around.
Pinball Dreams: Scrolling intro text shows random phases of judder from time to time but mostly smooth.

All happens in regular DEV too, so nothing to do with this PR.

I personally would like the game mode to be enabled without any vsync fixes for now. This clearly is something to be included in a subsequent PR preferably after 0.81 is shipped.

Will test Windows on Monday if nobody else can do it by then.

are there cases where 'vsync = on' actually makes sense on macOS?

Yes, when it comes to tearing prevention, vsync = on is useful and behaves correctly on all platforms.

It simply passes that request through to the OpenGL drivers, and users can expect real vsync behavior. There some caveats out of our control though:

• The OpenGL drivers might not honor the vsync request (some users disable vsync universally. Well, if that's what they want, then it won't work here either).

• DOS-level tearing might still be happening if the game writes to the video RAM as fast as possible, like Hexen does. So vsync = on will simple draw these pre-torn frames as they would have been torn on a real DOS machine.

• DOOM, on the other hand, runs at 35 Hz and draws on vblank. @GranMinigun has a handy suggestion to detect if your host is tearing: get close to the pillars on the first level and rotate side-to-side and look for tearing along the verical column edge. With vsync = on, there should be none.

How about automatically setting 'vsync = adaptive' on macOS if 'vsync = on' is used?

This PR lets users set vsync = adaptive for OpenGL (on all platforms), but I'd rather not move the chairs under the hood. If a user sets vsync = on, then that's what they get - and same with vsync = adaptive.

@Burrito78 , thanks for all the testing and showing that this new game-mode feature is actually no worse than baseline.

Also, both you and I confirmed on macOS that:

[sdl]
vsync = on
presentation_mode = auto

Comes with a large performance penalty because of excessive vsync block times if frames aren't provided at the host-rate.

So this PR has auto presentation mode select CFR on macOS when vsync is on. It's a tiny refinement to avoid this pitfall. Without it, things are a lot worse.

Based on this, I'll go ahead and merge.