Project

General

Profile

Actions

Emulator Issues #11796

closed

(MacOS/Vulkan) When a window covers the game window, the emulation slows to a crawl.

Added by jpapetti0713 almost 5 years ago. Updated over 1 year ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
OS X
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

ANY

Game ID? (right click the game in the game list, Properties, Info tab)

ANY

MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)

NA

What's the problem? Describe what went wrong.

When a game is being played, and another window covers the emulator, it results in an 1 FPS emulation.

What steps will reproduce the problem?

  1. Use Vulkan
  2. Run a game in windowed mode
  3. Cover the game screen with another window.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

10607

Is the issue present in the latest stable version?

NA - No Vulkan

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

Not sure of the exact build, but it was before 10200.
(I am working on finding the exact one)

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

NA

What are your PC specifications? (CPU, GPU, Operating System, more)

  1. MacBook Pro (Retina, 13-inch, Mid 2014), 2.6 GHz Intel Core i5, RAM: 16 GB 1600 MHz DDR3, Video: Intel Iris 1536 MB, running MacOS Mojave 10.14.5 (18F132).
  2. MacBook Pro (Retina, 13-inch, 2017, Four Thunderbolt 3 Ports), 3.1 GHz Intel Core i5, RAM: 8 GB 2133 MHz DDR3, Video: Intel Iris Plus Graphics 650 1536 MB, running MacOS Mojave 10.14.6 Beta (18G59b).

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

Changing Dual Core does not solve the problem.

YT video (running Mario Party 6 on 2017 MBP)
https://youtu.be/HsgNdO4r9yk

Actions #1

Updated by jpapetti0713 almost 5 years ago

Bisect: ~5.0-9178

Actions #2

Updated by JMC4789 almost 5 years ago

As far as I can tell this is due to a macOS power saving behavior, and our attempts to circumvent it have failed. It started happening in High Sierra iirc.

Actions #3

Updated by jpapetti0713 almost 5 years ago

I ran Dolphin in Xcode Debugging mode, and noticed when covering the emulation, all the threads (with the exception of libsystem_c and Apple Audio Thread) drop to 0 in usage.

Maybe it is just some power function, but I can't reproduce this effect in OpenGL... Maybe Vulkan/Metal is related as well?

Actions #4

Updated by Pizuz almost 5 years ago

This is definitely a Metal issue. Stenzek‘s experimental Metal build exhibits the same issue.

https://bugs.dolphin-emu.org/issues/11617

Actions #5

Updated by JMC4789 almost 5 years ago

Yeah, unfortunately, we don't know what's happening with it.

Actions #6

Updated by jpapetti0713 almost 5 years ago

Great News! I figured out the problem!

It turns out that there is no power saving function causing this after all... it is caused by BlockingLoop.h - Line 54 - void wait().

By removing the line "s_gpu_mainloop.Wait();" in VideoCommon/FIFO.cpp, the emulation will run without any trouble, even when Google Chrome is covering the window.

I have a suspicion that "IsDone()" might be the culprit, since everything else in the Wait() seemed to be working fine.

Actions #7

Updated by jpapetti0713 almost 5 years ago

Well... a new problem showed up.

By removing that line of code (obviously not a permanent solution), it causes the audio and video to desync (in Mario Party 6, it is the opening cutscene, however, after pressing a button to skip the cut scene will resync. No idea why...) and the FPS counter will plummet to 1. But, the audio will be fine, it is the video that would lag behind.

I will investigate further.

Actions #8

Updated by Pizuz over 4 years ago

I just updated to macOS Catalina which also got a Metal update. The issue seems to be fixed there. I even got some small performance boost, as it seems.

Actions #9

Updated by Billiard26 over 1 year ago

  • Operating system OS X added
  • Operating system deleted (N/A)
Actions #10

Updated by JMC4789 over 1 year ago

  • Status changed from New to Invalid

Issue is reported fixed on newer macOS versions.

Actions

Also available in: Atom PDF