Viewport and Eevee performance issues on macOS
Closed, ArchivedPublic


Currently performance on macOS is quite bad.

The most immediately visible issue is that for the first 10s or so, both Clay and Eevee are very laggy. After that viewport navigation is much smoother, though still not great.


kevin zhow (kevinzhow) renamed this task from Eevee has very laggy performance in 3D View on macOS 10.12 to Eevee has very laggy performance in 3D View on macOS 10.13.1.Dec 7 2017, 7:20 AM
kevin zhow (kevinzhow) updated the task description. (Show Details)
Brecht Van Lommel (brecht) renamed this task from Eevee has very laggy performance in 3D View on macOS 10.13.1 to Viewport and Eevee performance issues on macOS.Apr 3 2018, 4:38 PM
Brecht Van Lommel (brecht) triaged this task as Normal priority.
Brecht Van Lommel (brecht) updated the task description. (Show Details)

The cause of the initial lagging is not clear. The profile shows most of the time is spent in the driver doing shader compilation.

It keeps doing that on every redraw, even when there are no new GLSL shaders being created and used as far as I can tell. Note that this issue also existed before lazy shader compilation was added, so it's not because of that.

When setting the viewport samples to 1 in Clay or Eevee it stops lagging much sooner, after 1s or so. My guess for what could be going on:

  • It is compiling a specialized shader for each viewport sample. If that is the case, we may be able to hint the driver not to do that.
  • Since there is still a lag for 1 viewport sample, there may also be some kind of multi-stage compilation going on where it first compiles a less optimized shader and then does deeper optimization later on, similar to how javascript is handled in browsers.

@Brecht Van Lommel (brecht) is shader cache working in OSX? (the OS/driver one)

In other words, does it make any difference to open a file for the first time or the second time (both cases after closing and reopening blender)?

Shader patching is a thing! Though it seems that MacOSX opengl implement is quite aggressive with it. Maybe some branches are statically optimized by the compiler.

So maybe we need to tag them to not be optimized. Is there a macos opengl specific flag for this?

@Brecht Van Lommel (brecht) It would be nice to know which shader is concerned!

You can try loading a blank scene (no objects) and see if there is still lag. If yes, this would mean it's a post process (TAA) problem.
But your screenshot suggest it comes from default passes. Which are geometry passes. In this case an empty scene should not lag.

I don't know if there is a shader cache on macOS, I couldn't find anything so far. There also does not appear to be a ARB_get_program_binary to cache shaders manually. I also did not find a way to tune optimization or shader patching on macOS yet.

There is no lag in an empty scene. Though of course the shaders are much simpler then so it may still be doing shader patching but fast enough not to notice.

My plan is to figure out which exact state changes are causing the shader patching.

I've committed a fix for the initial lagging, it was different texture slot assignments that caused shader patching.

Brecht Van Lommel (brecht) claimed this task.

Archiving this for now, can be handled as part of general stability and optimization on all platforms.