macOS: RetroArch does not set a QOS class

[AaronKelley]

Description

I noticed that RetroArch on macOS doesn't seem to be setting a QOS priority and is running with QOS/priority "unspecified". It also largely runs on the system's efficiency cores, not the performance cores. It might benefit from running with QOS/priority "user interactive" to make it more likely to run on the performance cores and provide maximum responsiveness. On macOS, raising the process QOS must be done from the app and can't be done using external tools. Also, QOS partly determines whether processes will be scheduled on the performance cores.

Expected behavior

RetroArch runs with the highest available process priority, or provides a user-selectable option to have it do so

Actual behavior

RetroArch runs with "unspecified" QOS

Steps to reproduce the bug

1. Launch RetroArch and run a game.
2. Determine the RetroArch process PID. Then run: sudo taskinfo (pid)
3. Observe that RetroArch is running with QOS class / clamp / ceiling THREAD_QOS_UNSPECIFIED.

Version/Commit

• RetroArch: 1.19.1

Environment information

• OS: macOS 14.5
  (on MacBook Pro with M2 Max)

Additional

It looks like QOS can be set at the thread level if the app is using pthreads. This is a bit out of my area.
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/PrioritizeWorkWithQoS.html

I've been looking at this because I have been seeing periodic one-frame drops that cause noticeable audio blips. I am hoping that increasing the process QOS will make macOS schedule RetroArch above everything else and make such blips less likely to happen.

See the tick up in the blue chart in the top right here, that is a one-frame drop:

And, all of the CPU activity seems to be focused on the E cores.

(@warmenhoven, I know you've been doing some work with RetroArch on Apple platforms specifically... is this something that you have poked at at all?)

[warmenhoven]

Main thread priority is automatically set based on the type of executable, and for a macOS app will always get User Interactive. CPU affinity is determined by the scheduler and can't be influenced by the application. The document you've linked is specifically about additional dispatch queues and threads that the application creates. It's true that retroarch doesn't set priority on the threads it creates, but those are for tasks that are not user interactive. Mainly retroarch itself is single threaded.

FWIW Xcode disagrees with taskinfo, it's showing that the priority is User Interactive: