Poor performance with OpenGL Renderer on Apple M1 machines

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.

4 Likes

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.

Are you on M1 or M1 pro/max?
( I just tested on (old) Apple M1 Air and the performance is quite okay)

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

1 Like

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.

With the OpenGL Renderer in particular or just generally?

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.

Got it. Will test with JUCE 6.0.8 to see if it makes any difference for us.

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.

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.

1 Like

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

Setting the priority of the OpenGL ThreadPool to something high seems to improve things.

4 Likes

Thanks for reporting. I’ve added a commit bumping the priority of the OpenGL thread here, which seems to improve performance on my machine:

3 Likes