• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 ... 12 13 14 15 16 ... 115 Next »

Investigations for Dolphin fighting macOS compositor
View New Posts | View Today's Posts

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Investigations for Dolphin fighting macOS compositor
01-15-2019, 08:25 AM
#1
kemenaran
Unregistered
 
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 Smile

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.
Reply
01-15-2019, 09:00 AM
#2
MayImilae Offline
Ambassador of Niche Platform Support
**********
Administrators
Posts: 4,464
Threads: 117
Joined: Mar 2011
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.
[Image: RPvlSEt.png]
Windows 10 x64 | Core i9-9900k | NVIDIA GeForce RTX 3090 EVGA FTW3 Ultra| 32GB DDR4-3000 | Asus Xonar Essence STX on Logitech Z-2300 | Logitech G903 Hero
MacBook Pro 14in | M1 Max (32 GPU Cores) | macOS 12 | 64GB LPDDR5 6400
Find
Reply
01-15-2019, 09:23 AM
#3
kemenaran
Unregistered
 
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
Reply
01-15-2019, 11:23 AM
#4
DJBarry004 Offline
Don't even bother...
*******
Posts: 2,456
Threads: 33
Joined: Sep 2013
Can you also share the source code? I mean, you -need- to share the source code of that build to comply with GPL.
Rig 1: Windows 10 Home | AMD A6-1450 @ 600/1000/1400 MHz | AMD Radeon HD Graphics 8250 | 4GB RAM | HP Pavilion TouchSmart 11.

Rig 2: Windows 10 Pro | Intel Core i7-2640M @ 780/2800/3500 MHz | Intel HD 3000 Mobile | 8GB RAM | Dell Latitude 6320.
Find
Reply
01-15-2019, 12:23 PM (This post was last modified: 01-15-2019, 12:26 PM by MayImilae.)
#5
MayImilae Offline
Ambassador of Niche Platform Support
**********
Administrators
Posts: 4,464
Threads: 117
Joined: Mar 2011
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. ┐( ̄ヘ ̄)┌
[Image: RPvlSEt.png]
Windows 10 x64 | Core i9-9900k | NVIDIA GeForce RTX 3090 EVGA FTW3 Ultra| 32GB DDR4-3000 | Asus Xonar Essence STX on Logitech Z-2300 | Logitech G903 Hero
MacBook Pro 14in | M1 Max (32 GPU Cores) | macOS 12 | 64GB LPDDR5 6400
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode