Investigations for Dolphin fighting macOS compositor

[kemenaran]

In the November 2018 progress report, MayImilae wrote about the frame pacing being really bad on macOS.

I don't know if this has been investigated since – but I did some searches, and found some explanations, and a fix.

The problem

Describing the problem as Dolphin "Fighting the system compositor" seems a good intuition. If Dolphin is pushing frames without coordination with the system compositor, both bad pacing and tearing can be expected.

I don't know much about graphics rendering, but it seems there are two ways of doing V-Sync on macOS: requesting v-sync from OpenGL, or waiting for a compositor callback that notifies of a V-Sync (akin to `requestAnimationFrame` on the web).

Well, it seems that in macOS 10.14, and the OpenGL deprecation, Apple wants apps to use the compositor callback. But Apple can't deprecate the OpenGL V-Sync without breaking old apps. So, instead, they decided OpenGL Sync would stop working only for apps compiled against the 10.14 SDK. Apps compiled before are fine. And apps compiled against the newest 10.14 SDK should upgrade to the compositor callback, using CVDisplayLink.

Seems like a good lead. Indeed Dolphin is compiled using the 10.14 SDK. And the V-Sync method is handled by Qt, which uses the OpenGL V-Sync method – and has a long-standing issue about "We should use CVDisplayLink instead".

Indeed, the SDL folks bumped into the same issue – and fixed it by using CVDisplayLink on macOS. And the glfw people too ; their PR with the fix is brand new.

The fix

Good news: Qt transitionned to CVDisplayLink in Qt 5.12.0, released on December 6th 2018… a few days after November's Progress Report

For now Dolphin is using Qt 5.9.0 – but the upgrade to Qt 5.12.0 seems easy. I compiled locally a Dolphin using the newest version of Qt, and behold! the tearing is gone. I don't have the tools to measure the frame pacing, but it should be improved as well.

I'll try to submit a PR that bumps Qt in the next few days.

[MayImilae]

I only casually mentioned vsync not doing anything on macOS, it was all about the frametime problems. :/ And since we don't use Qt for video output, it is very unlikely that updating Qt would affect that issue.

[kemenaran]

Oh, ok – well, vsync may be a wrong lead then.

That said, Qt 5.12 definitely fixed vsync on my system (on macOS 10.14). I don't know how to measure the frame pacing though; which tools did you use to produce the graphs on the Progress Report?

Also, if you want to test by yourself and see if you notice any improvement, I uploaded a Dolphin binary that uses the latest Qt available: http://winosx.com/hosted_files/Dolphin-9335-qt5.12.0.app.zip

[DJBarry004]

Can you also share the source code? I mean, you -need- to share the source code of that build to comply with GPL.

[MayImilae]

Dolphin has a feature built in that will dump frame-times to a file. Its in the General Graphics settings, "Log Render Times to File".

So, if you want to investigate the frame time issue, there is a bit of a lead we have since the report. In a response tweet to the Progress Report, a macOS developer mentioned that Chrome had similar problems, and had to use a glFinish each frame to bring the frametimes under control. This explains why EFB to RAM (Store EFB Copies to Texture Only disabled) doesn't have the frametime issue - it always does a glFinish as part of its VRAM and system RAM syncing! The downside though is that EFB to Texture's performance is far better than EFB to RAM precisely because it doesn't have such hard syncs. So if we did that all the time, Dolphin's performance would be even worse on macOS! So um, while that's interesting, it doesn't really help us. ┐(￣ヘ￣)┌