Terrible color video performance with Metal on some Macs

[ryandesign]

On my 2012 MacBook Pro with 15" Retina Display running macOS Monterey 12.6.8, Clock Signal 2023-09-10 has terrible video performance when emulating an Apple IIe in color. It's fine in monochrome.

Sample program

1TEXT:HOME:VTAB24:FORA=65TO90:FORC=1TO40:?CHR$(A);:NEXT:NEXT

Monochrome

Color

[ryandesign]

I must confess that this problem may be unique to my machine, which is also experiencing other slowdowns that should not be happening. I do keep far too many windows and tabs open and maybe that is taxing for my video card. And I am using OpenCore Legacy Patcher to install Monterey on this machine, which is not ordinarily able to run that OS. Maybe video performance has suffered due to this unsupported OS upgrade. I don't see this slowdown on a different 15" MacBook Pro, a 2016 Touch Bar model running macOS Sonoma, also via OCLP.

And yet, maybe there is still a Clock Signal bug here. Other emulators like MAME, Virtual ][, OpenEmulator, and Mini vMac don't have any difficulties displaying fast graphics on this machine. And Clock Signal doesn't either when in monochrome mode. Maybe there is some inefficiency in the way that Clock Signal is displaying when in color that, if resolved, might improve performance or energy efficiency for all users.

[ryandesign]

The SDL/OpenGL version doesn't have this problem running on the same Mac. (However, having the macOS native version running in color mode does slow down the SDL/OpenGL version and everything else.)

[ryandesign]

Some more data points for you:

I updated this machine to OpenCore Legacy Patcher 1.1.0 and macOS Monterey 12.7.1. The issue remains, with no apps open except Finder and Clock Signal.

I also tested macOS Catalina 10.15.7 on the same machine with only the Finder and Clock Signal running and the issue is present there as well. Catalina is a supported OS version on this model.

I also tested macOS Mojave 10.14.6 on the same machine. The issue is not present.

I could not test macOS High Sierra 10.13.6 due to #1118.

[ryandesign]

After fixing Clock Signal for High Sierra (#1192) I can confirm this issue is not present on High Sierra on this Mac either.

[TomHarte]

I kind of wonder whether I'm doing something wrong in the handling of the external GPU so as to create a race condition, like failing to flush a buffer or similar, and getting away with it on my test machines because everything I still own has an integrated GPU. That's given that we already know that the cost of processing isn't the issue, and that things are fine under OpenGL where that sort of thing is not the developer's responsibility.

Possibly a reach, but the obvious simpler options seem to be ruled out.

[ryandesign]

I used gSwitch to force the use of integrated graphics, or discrete graphics, and verified that this had taken effect by looking in Activity Monitor's Energy tab. Clock Signal performance in color was bad with either setting on my 2012 MBP although I'm still not 100% certain the GPU switch happened based on reports in CodySchrank/gSwitch#85.

I wonder what changed in macOS 10.15, since that's when performance starts being bad for me.

[ryandesign]

Have you tried using the Metal Performance HUD? I tried enabling the Show Graphics Overview checkbox in the scheme settings (I had to update to Xcode 14 before that checkbox appeared) but the HUD did not appear. I have read elsewhere that it requires macOS Ventura or newer which I don't have on this machine yet.

[ryandesign]

It's not specific to the Apple II; I also saw the problem with Atari 2600 and Atari ST (in composite mode but not in RGB mode).

According to git bisect the problem was introduced in 3d392dd.

[ryandesign]

The documentation for preferredDevice makes it sound like a good thing to use, and yet…

Adding this logging:

--- a/OSBindings/Mac/Clock Signal/Views/CSScanTargetView.m      
+++ b/OSBindings/Mac/Clock Signal/Views/CSScanTargetView.m      
@@ -146,6 +146,8 @@ static CVReturn DisplayLinkCallback(__unused CVDisplayLinkRef displayLink, const
 
 - (void)awakeFromNib {
        self.device = MTLCreateSystemDefaultDevice();
+       fprintf(stderr, "default device name: %s\n", [self.device.name cStringUsingEncoding:NSUTF8StringEncoding]);
+       fprintf(stderr, "preferred device name: %s\n", [self.preferredDevice.name cStringUsingEncoding:NSUTF8StringEncoding]);
 
        // Configure for explicit drawing.
        self.paused = YES;

I see:

default device name: NVIDIA GeForce GT 650M
preferred device name: Intel HD Graphics 4000

So c74305b really only made Clock Signal always use the discrete GPU if available. While that fixed it for my 15" 2012 MBP, it's an unnecessary use of more energy on newer machines like my 15" 2016 MBP. And it won't help on machines that don't have a discrete GPU available, like the 13" 2012 MBP.

So I would still really like to understand the source of the performance problem and revert my change and go back to using the integrated GPU when it will work. What is it about the Clock Signal Metal code that is causing difficulty for the Intel HD Graphics 4000 GPU? Can it be remedied? If not, is it some GPU capability that Clock Signal requires that the Intel HD Graphics 4000 lacks that later integrated GPUs have? If so, can we check for that capability and only exclude those GPUs that don't have it?

Using macOS 14.2.1 on the 15" 2012 MBP I tried the aforementioned Metal Performance HUD and it shows these results:

NVIDIA GeForce GT 650M	Intel HD Graphics 4000

Instruments should be able to provide some information about the cause of the slowdown. (In Xcode, choose Profile from the Product menu and select the Game Performance template.) I don't have experience analyzing the results of instruments however.