# Poor performance with OpenGL Renderer on Apple M1 machines **URL:** \ **Category:** MacOSX and iOS\ **Created:** [November 11, 2021, 3:18am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725 "2021-11-11T03:18:26Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [November 11, 2021, 3:18am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/1 "2021-11-11T03:18:26Z")
We’re in the process of testing our ARM plugin builds on the latest Apple M1 MBP’s and have seen very poor performance for OpenGL rendering. Testing with the JUCE GraphicsDemo shows an Actual FPS of around 14 when the renderer is set to OpenGL. Activity Monitor shows ~80% GPU utilization. Loading the DemoRunner app in Rosetta 2 shows similarly bad performance. Tested with the tip of JUCE on master and develop on macOS 12.0.1. Obviously, this could just be an issue with the OS or the new graphics processors in these machines, but other non-JUCE OpenGL apps seem to do better on M1. ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [November 11, 2021, 11:54pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/2 "2021-11-11T23:54:31Z")
Looking into this more, it seems to specifically be JUCE 2D rendering with OpenGL that is particularly slow on M1 (both ARM and Rosetta 2). Here’s an example showing this behavior with the OpenGLDemo. The framerate is high (\>100) before 2D graphics are turned on, after which the GPU pins at 90% and the framerate drops to 40. [![](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/3/364191921a33e64eb8415ebf40e6a717457b9fa4.jpeg "JUCE OpenGL 2D Drawing Issues on Apple M1") ](https://www.youtube.com/watch?v=qRLSteHsQTU) ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [November 12, 2021, 9:50am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/4 "2021-11-12T09:50:52Z")
Are you on M1 or M1 pro/max? ( I just tested on (old) Apple M1 Air and the performance is quite okay) ---
**Author:** ![jellebakker](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jellebakker/32/17053_2.png) [@jellebakker](https://forum.juce.com/u/jellebakker)\ **Post date:** [November 12, 2021, 6:09pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/5 "2021-11-12T18:09:50Z")
I’m experiencing a massive performance drop on my M1 macbook air from JUCE 6.1.0. It worked all smooth on JUCE 6.0.8 ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [November 12, 2021, 6:11pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/6 "2021-11-12T18:11:18Z")
What OS is your Apple M1 Air on? We’ve tested three machines: an M1 Max (24-core GPU), M1 Max (32-core GPU), and an M1 Mac Mini. All of them exhibit similarly poor performance for 2D graphics when the OpenGL Renderer is selected. - M1 Max (32-core GPU) - GraphicsDemo, Actual FPS 15.8, 85% GPU usage (in Activity Monitor) - M1 Max (24-core GPU) - GraphicsDemo, Actual FPS 15.6, 91% GPU usage (in Activity Monitor) - M1 Mac Mini - GraphicsDemo, Actual FPS 48, 89% GPU usage (in Activity Monitor) I think the Mac Mini just does better here because it was hooked up to a 1080p display and thus is drawing a lot less pixels. Still can’t hit 60fps for even the simplest of 2D drawings though. ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [November 12, 2021, 6:11pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/7 "2021-11-12T18:11:54Z")
With the OpenGL Renderer in particular or just generally? ---
**Author:** ![jellebakker](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jellebakker/32/17053_2.png) [@jellebakker](https://forum.juce.com/u/jellebakker)\ **Post date:** [November 12, 2021, 6:15pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/8 "2021-11-12T18:15:31Z")
The OpenGL renderer in an app that I’m working on has become extremely slow since JUCE 6.1.0. The demo runner runs fine. ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [November 12, 2021, 6:17pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/9 "2021-11-12T18:17:56Z")
Got it. Will test with JUCE 6.0.8 to see if it makes any difference for us. ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [November 12, 2021, 11:51pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/10 "2021-11-12T23:51:28Z")
Okay, I can confirm that there has been a significant worsening of OpenGL performance between JUCE 6.0.8 (545e9f353) and 6.1.2 (d49d20397). Thanks for the tip @jellebakker! Across 4 different M1 machines, on average, the framerates went down by 54% while CPU usage went up 58% for two different tests in the DemoRunner. Full results [here](https://docs.google.com/spreadsheets/d/1AqH8zdl_pd0REeWUZDdwOUQG5iHRWucs3jRfoXAHMog). For JUCE 6.1.2, none of the M1 machines could achieve 60 fps for the GraphicsDemo using the OpenGL Renderer. Even before JUCE 6.1.2, the framerates on M1 were not great, but now they are essentially unworkable for anything close to “smooth” animations, all while basically saturating the CPU & GPU. ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [November 17, 2021, 6:35pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/11 "2021-11-17T18:35:59Z")
Looks like one of the offending commits is: > See our comment here: [Thread: Avoid setting realtime priority on Thread instances by defau… · juce-framework/JUCE@802f33b · GitHub](https://github.com/juce-framework/JUCE/commit/802f33b0e865011aca07058fe5644cae27a46b8f#commitcomment-60378487) Setting the priority of the OpenGL ThreadPool to something high seems to improve things. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [November 30, 2021, 11:34am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/12 "2021-11-30T11:34:49Z")
Thanks for reporting. I’ve added a commit bumping the priority of the OpenGL thread here, which seems to improve performance on my machine: > ---
**Author:** ![dxp](https://avatars.discourse-cdn.com/v4/letter/d/e9a140/32.png) [@dxp](https://forum.juce.com/u/dxp)\ **Post date:** [December 7, 2021, 11:30pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/13 "2021-12-07T23:30:04Z")
Hello. Even with the last commit, I’m having trouble with our plugin dropping frames on M1 Max and macOS 12.0.1. Using Instruments profiler, under Rosetta (and my last Intel Mac), the OpenGL render thread executes with high priority and at 60 fps. With native M1, it appears that the render thread spends time on both efficiency and performance cores. While on an E core it’s often preempted by higher priority tasks such as hardware events and the render thread may not complete in time. I tried setting the render thread to priority 10 (instead of 9 as in the above commit) but this didn’t help much. In Rosetta mode, it’s always running on a performance core and isn’t interrupted by anything significant. Apple recommends assigning QoS classes to threads instead of setting priorities ([Apple Developer Documentation](https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon)). I attempted to do this on creation of the render thread but it didn’t appear to be any different than running it with a high priority. ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [December 8, 2021, 4:33am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/14 "2021-12-08T04:33:11Z")
We’re seeing the same type of performance issues even with the priority improvement. I also wondered about QoS — our plugins always seem to mostly run on the E cores which seems very strange to me. Could it be because JUCE doesn’t directly use a CVDisplayLink? ---
**Author:** ![dxp](https://avatars.discourse-cdn.com/v4/letter/d/e9a140/32.png) [@dxp](https://forum.juce.com/u/dxp)\ **Post date:** [December 9, 2021, 10:22pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/15 "2021-12-09T22:22:51Z")
I’m certainly no expert but it seems like JUCE is using CVDisplayLink sensibly: The CVDisplayLink callback signals the render thread for work to be done. For what it’s worth, calling renderFrame() directly from the CVDisplayLink callback (as it used to be done) doesn’t make any difference in terms of spending time on both E and P cores. ---
**Author:** ![aaronleese1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/aaronleese1/32/19725_2.png) [@aaronleese1](https://forum.juce.com/u/aaronleese1)\ **Post date:** [January 1, 2022, 3:00pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/16 "2022-01-01T15:00:59Z")
Still testing here, but it seems like something changed with 6.14. M1 2D performance now pretty good, but MBP intel non-openGL seems to have slowed way down. Anyone else seeing this? ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [January 17, 2022, 3:04pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/18 "2022-01-17T15:04:44Z")
Just a little update, there were two more changes after the November fix (above) to fix potential performance issues. 15 Dec 2021 OpenGL: Avoid querying the native view hierarchy from a background… 15 Dec 2021 Thread: Update macOS thread priority calculation The current state is that the teapot demo (latest tip) still doesn’t run smoothly on Apple M1 Max at all (MacBook Pro 14 M1 Max) Maybe the patch from here should be generally build into the Demo, so it is more easy to create comparable measurings. > [@Apple M1 - few OpenGL hiccups](https://forum.juce.com/t/apple-m1-few-opengl-hiccups/47561): > > On the whole I am satisfied with the OpenGL performance, especially on my intel machines (Win/Mac) But I noticed small hiccups (maybe one or two in a second) on my MacBook Air1 M1 with an external monitor. (Also in my standalone app, native ARM) The hiccups (I guess a ca. 1/10 second long) i also see in the teapot-demo from the DemoRunner (Release mode / ARM /profiling) During profiling I couldn’t find a particular hotspot, but I noticed that other OpenGL applications can run smoothly on cur… ---
**Author:** ![jakemumu](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jakemumu/32/13038_2.png) [@jakemumu](https://forum.juce.com/u/jakemumu)\ **Post date:** [February 3, 2022, 12:12am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/19 "2022-02-03T00:12:11Z")
Experiencing this as well ---
**Author:** ![goodhertz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/goodhertz/32/74_2.png) [@goodhertz](https://forum.juce.com/u/goodhertz)\ **Post date:** [February 3, 2022, 12:20am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/20 "2022-02-03T00:20:55Z")
@reuk why was the OpenGL priority change (which helped a good deal) reverted for the renderThread here? > > > The Apple threading documentation \[^1\] says the following: > > \> The second argumen…t to pthread\_setschedparam is the desired policy, > which can currently be one of SCHED\_FIFO (first in, first out), > SCHED\_RR (round-robin), or SCHED\_OTHER. The SCHED\_OTHER policy is > generally used for extra policies that are specific to a given > operating system, and should thus be avoided when writing portable > code. > > This appears to differ from the policy semantics on Linux and BSD, where > FIFO and RR are both explicitly real-time policies. > > Therefore, on Linux/BSD we only enable the RR policy if the requested > priority is 8 or higher. Meanwhile, on macOS, we map all thread > priorities (0 - 10) onto the RR policy with an appropriate priority. > > \[^1\]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html ---
**Author:** ![wavesequencer](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/wavesequencer/32/11659_2.png) [@wavesequencer](https://forum.juce.com/u/wavesequencer)\ **Post date:** [February 3, 2022, 4:06am UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/21 "2022-02-03T04:06:11Z")
Just a quick note - I am wondering if these thread priority related changes had anything to do with the audio performance drop I saw on Mac M1 (but not in Intel Mac, which seems weird) - as mentioned in: > [@M1 based Mac audio load worse (nearly 2X higher) after move from JUCE 6.07 to 6.14 (but not a problem on Intel Mac)](https://forum.juce.com/t/m1-based-mac-audio-load-worse-nearly-2x-higher-after-move-from-juce-6-07-to-6-14-but-not-a-problem-on-intel-mac/49968): > > I observed it before (and was reported by a customer), but building with the same version of Xcode (12.5) I found the audio load of my M1 native plugin & standalone build is much higher (nearly 2X audio load) after moving from JUCE 6.07 to 6.14 (also seen since 6.11) - this previously forced me to drop back to 6.07 as I didn’t have the time to investigate, was hoping this was going to go away now that I’m on 6.14 vs 6.11. I’m running BigSur 11.6.1 on a M1 Mac Air, will try to upgrade to Montere… I won’t speculate any further. I am going to test different versions until I can figure out which commit is causing my issue. But just thought I’d mention it here in case anybody has an opinion on that. EDIT: I tracked my M1 performance issue down to a fairly old commit right after JUCE 6.0.7 - related to something specific about Mac OS drawing - see original thread for the details. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [February 3, 2022, 5:47pm UTC](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725/22 "2022-02-03T17:47:25Z")
If memory serves, the OpenGL performance got worse in this commit: > Given that the commit you linked essentially reverts the above change on macOS, it seemed reasonable to revert the OpenGL “workaround” too. I’m sure I tested and verified this, but I just had another go and I’m not seeing massive differences in performance before and after either of those changes… Are you seeing an actual performance regression on develop currently, or are you asking out of interest about the change? If you are seeing a performance regression, is there a JUCE demo that demonstrates the issue reliably? [Next page](https://forum.juce.com/t/poor-performance-with-opengl-renderer-on-apple-m1-machines/48725.md?page=2)