[duped]

Developers aren't (yet) abusing audio workgroups for all their thread pools to get pcore scheduling and higher priority. So it would imply that if an audio workgroup is issuing commands to the GPU there should be some kind of timeout to the GPU downclocking based on the last time a workgroup sent data to it.

GPU audio is extremely niche these days, but with the company mentioned in TFA releasing their SDK recently it may become more popular. Although I don't buy it because if you're doing thing on GPU you're saying you don't care about latency, so bump your i/o buffer sizes.

[Archit3ch]

> if you're doing thing on GPU you're saying you don't care about latency

This does not follow. Evidently it is possible to have low-latency audio processing on the GPU today (per the SDK).

[krackers]

I'm not too familiar with audio workgroups but since the early days XNU had low-level APIs to set pthreads as pseudo-realtime

[xmodem]

This will definitely get you to run with a higher priority than the user's time machine backup, but it's not guaranteed to get your code onto a p-core if the machine is on battery and your app doesn't have focus.