Page MenuHome

Very slow Eevee performance on Mac with AMD Radeon
Closed, ResolvedPublicBUG


System Information
Operating system: Darwin-18.7.0-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 460 OpenGL Engine ATI Technologies Inc. 4.1 ATI-2.11.20
And macbook pro. (Radeon Pro 560)

Blender Version
Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-10-01 19:51, hash: rB3b23685c7dc1
Worked: 2.80rc1

Short description of error
Blender 2.82 has a very slow Eevee viewport performance. Even after turning off smooth shadows or AO or screen-space reflections. Not possible to work anymore.
In my model it seems that the slowest is the material_pass, but almost everything is the slowest.
Blender 2.82:

   psl -> material_pass 995.01ms 99

Blender 2.80:

   psl -> material_pass 171.42ms 99

I also noticed that the GPU usage is much higher with 2.80.

Exact steps for others to reproduce the error

  • Open attached file in both Blender versions.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

We are aware of many issues with MAC OS, but unfortunately we have no developers with this setup to investigate and reproduce the problem.
Changes are constantly being made to improve viewport peformanse, and it is quite possible that this regression will be resolved in the next builds.
@Clément Foucault (fclem), any idea why this is happening?

Can you try macOS Catalina? Blender 2.80.75 seems to work fine on my hardware on Catalina.

Germano Cavalcante (mano-wii) lowered the priority of this task from 90 to 30.Dec 3 2019, 4:22 PM

Blender 2.81 has still extremely low performance (not able to work) in comparison to the 2.80 where the scene with more than 2 million of polygons and 10 lights move smooth. I tested yesterday also 2.82 and performance is very slow too. Maybe I can recreate these conditions if it can help you somehow to fix that issue?

Germano Cavalcante (mano-wii) raised the priority of this task from 30 to 80.Dec 4 2019, 3:31 PM
Jacques Lucke (JacquesLucke) changed the task status from Needs Developer to Reproduce to Needs Information from User.Feb 26 2020, 2:51 PM

Please prepare a file that is significantly faster in 2.80 compared to 2.82. Otherwise, someone with the right hardware who wants to check this report has to do a lot of guess work.

I have the same problem with my macbook pro. (Radeon Pro 560)

According to the debug values, the Eevee Background is about 10x slower in 2.82 compare to 2.80.

In my model it seems that the slowest is the material_pass, but almost everything is the slowest.
Blender 2.82:

   psl -> material_pass 995.01ms 99

Blender 2.80:

   psl -> material_pass 171.42ms 99

I also noticed that the GPU usage is much higher with 2.80.

I can share a blender file if that could help.

@Victor Bonnet (vbonnet), yes, please post a blend file that can redo this error (keeping it as simple as possible)

It is probably the same problem described in T66231, since it is related to Mac + AMD and fails in the material_pass.

I am having the the same issue as T66231. But I can reproduce it in both versions of Blender (2.8 & 2.82).

While in my model the slowness appeared after the update of Blender 2.81. So I suppose it is a different issue.

Here is the blend file having the slowness issue on latest Blender versions.

Philipp Oeser (lichtwerk) changed the task status from Needs Information from User to Needs Triage.Mar 20 2020, 2:12 PM

@Victor Bonnet (vbonnet), the textures are not packed in the file, will this affect the tests?

Sorry about that.

I just checked and I have the same issue with the missing textures.

I manage to find which commit introduce the slowness on my computer.

It starts to be slow after this commit which was made in Sept 17th. This was between version 2.80 and 2.81.
This commit is pretty big, I am going to investigate a bit more what could cause this slowness in this change.

Germano Cavalcante (mano-wii) renamed this task from Very slow Eevee performance. Not possible to work. to Very slow Eevee performance on Mac with AMD Radeon.Apr 7 2020, 9:07 PM

@Clément Foucault (fclem) I have tested your patch on my computer. it doesn't fix the issue unfortunately.

When I run an animation in the view port:

  • Blender 2.8: ~2.7fps
  • Master + patch: ~0.38fps

@Victor Bonnet (vbonnet) is workbench also slowing down this much?

It's hard to say. With animation it's limited to 24fps, I don't know how I could properly test that?

You can set framerate to 60fps to test. You can try to make the scene heavier to make it so that the base fps is below 60 and it can be measured.

Ok it seems that the workbench is slower also but not this much.

  • Blender 2.8: ~30fps
  • master: ~23fps

I profiled the application before and after the commit that cause the slowness.

The CPU is at 100% constantly after the commit:

before the commit:

@Victor Bonnet (vbonnet) Thanks! that's very helpful. This means the slowdown comes from a state change that triggers shader recompilation.

Unfortunatelly I have yet to find what triggers this recompilation. T66231 is the same issue but from another state since D7642 does not fix it.

@Victor Bonnet (vbonnet) it would be nice if you could reduce the complexity of the file. Remove objects until the slowdown does not happen anymore.

I removed plenty of objects to keep only the wall and 1 windows frame.
I noticed that if I change the material of the window frame to metallic it's also much faster. I tried your patch with this simplified model, and it actually speeds it up by a lot.

I have found two others objects that cause the slowdown. It seems removing the Texture coordinate and the Mapping in the node material is reducing CPU usage.
I attach the blend file for this use case

@Victor Bonnet (vbonnet) this is still a too big/complex file. From the bug triaging playbook "Normally .blend files can be simplified by removing most objects and disabling settings, until the problem reveals itself more clearly."

Could you please remove EVERY object/material/texture that is not needed to reproduce the issue, remove EVERY modifier that is not needed to reproduce the issue. If possible I would even go as far as removing all the geometry parts that are stopping it from being reproduceable.

I simply copy the two objects into a new blender project and I am able to reproduce. Hopefully it's gonna help.

It really seems to be related to the materials of those objects. If I switch the output of Texture Coordinate node from UV to Generated in one of the two materials, the fps is much better.

@Victor Bonnet (vbonnet) What if you use the same texture in both materials?

Edit: Also are you sure the slowdown here is still caused by shader compilation?

If I use same texture in both materials then it's fine.

Also are you sure the slowdown here is still caused by shader compilation?
What can I do to ensure it?

What can I do to ensure it?

Well you just run instrument profiler again and see if the bottleneck is still the same driver function calls (mainly SCCompileShader).

Ok, it seems so.

I attached a screenshot and the trace file.

In renderdoc capture it shows that there is almost nothing happening between the 2 drawcalls. I did a capture of the 2.80 release and it is almost the same.

Using the same Texture in both shaders leads to the 2 drawcalls being merged inside the same shading group (for a reason I can't remember). So this just hide the issue.

After a bit of research I came across this

glUniformBlockBinding sets state in the program (which is why you shouldn't be calling it every frame). glBindBufferRange sets state in the OpenGL context.

Which seems to say that calling glUniformBlockBinding might be the trigger to the recompilation if it changes. But after double checking all bindings are the same, for both textures and UBOs.

Since the issue comes from D4997 I can suggest P1412 to see if just this extra bind is responsible for the slowdown but I highly doubt.

If I switch the output of Texture Coordinate node from UV to Generated in one of the two materials, the fps is much better.

I think this is because then the 2 materials don't use the same GPUShader and it does not need to be recompiled because the state of each drawcall is cached inside each shader.

I tried P1412 but unfortunately it doesn't fix.

I'll try to play with the APIs on my side.

@Clément Foucault (fclem) I noticed that the issue with the Texture Coordinate is only reproducible on tmp-eevee-material-refactor branch but not on master.

Concerning the home_2.8.blend file, there is still the slowness compared to v2.80. But this file might not be the best one for debugging.

Can anyone test with latest master and tell me if this is fixed?

I checked on my macbook. The animation is now even faster than in blender 2.80.

  • ~3.7fps on master
  • ~2.6fps on 2.80

The animation runs faster but when I first switch to render mode it's slower. ~1m50s on master, ~30s on blender 2.80.
This might be intended and I guess this is not in the scope of this issue.

Clément Foucault (fclem) closed this task as Resolved.Jun 3 2020, 8:53 PM
Clément Foucault (fclem) claimed this task.

when I first switch to render mode it's slower

What do you mean? what are thoses ~1m50s? Render time? Time for shader compilation?

I think that's shader compilation. When I switch from the workbench to eevee.

@Victor Bonnet (vbonnet) can you check if the compilation slowdown is caused by rBcecda64e2ead (checking before and after the commit, since you won't be able to revert it cleanly).

@Clément Foucault (fclem) Yes the slowdown is caused by this commit.

@Victor Bonnet (vbonnet) can you give me a detailled screenshot of instrument profiling this, like you did for the original issue?

I want to know if it is the interface creation itself or if it compiles the shader twice because of using it in another context.

Here it is.

@Victor Bonnet (vbonnet) I'm sorry I don't have a Mac nor instrument. Could you unfold the view and see where the hotspot is and just past a screenshot here?

@Victor Bonnet (vbonnet) and what is inside GPU_shaderinterface_create?

Huh, this seems to be caused by glGetActiveUniformsiv. I don't have a quick test to see if that really is the culprit; but, there is another way to exclude the UBO uniforms which is a bit more involved.

Preemptively, I just implemented this other solution in rBfd061f61c79e. Hopefully it fixes the issue. Else better open a new task for discussing this.

@Clément Foucault (fclem) Your commit fixes the slow shader compilation slowdown.

Basically shader compilation and animation is now faster than what it was in Blender 2.80.

To recap this is the numbers I have with this model on my macbook:

VersionAnimation fpsShader compilation
master~3.6~1min 50s

That's quite impressive how faster things are now on my computer (at least with this blend file).
Thanks @Clément Foucault (fclem)