• 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 … 13 14 15 16 17 … 117 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
Threaded Mode
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
Chronically Distracted
**********
Administrators
Posts: 4,656
Threads: 121
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]
AMD Threadripper Pro 5975WX PBO+200 | Asrock WRX80 Creator | NVIDIA GeForce RTX 4090 FE | 64GB DDR4-3600 Octo-Channel | Windows 11 23H1 | (details)
MacBook Pro 14in | M1 Max (32 GPU Cores) | 64GB LPDDR5 6400 | macOS 12
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-9....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
Chronically Distracted
**********
Administrators
Posts: 4,656
Threads: 121
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]
AMD Threadripper Pro 5975WX PBO+200 | Asrock WRX80 Creator | NVIDIA GeForce RTX 4090 FE | 64GB DDR4-3600 Octo-Channel | Windows 11 23H1 | (details)
MacBook Pro 14in | M1 Max (32 GPU Cores) | 64GB LPDDR5 6400 | macOS 12
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma