Very slow Eevee performance on Mac with AMD Radeon #70445

New Issue

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: 3b23685c7d
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:

Shading:
   psl -> material_pass 995.01ms 99

Blender 2.80:

Shading:
   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.

home_2.8.blend

**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: `3b23685c7d` 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: ``` Shading: psl -> material_pass 995.01ms 99 ``` Blender 2.80: ``` Shading: psl -> material_pass 171.42ms 99 ``` I also noticed that the GPU usage is much higher with **2.80**. ![GPU.png](https://archive.blender.org/developer/F8380344/GPU.png) **Exact steps for others to reproduce the error** - Open attached file in both Blender versions. [home_2.8.blend](https://archive.blender.org/developer/F8399910/home_2.8.blend)

Added subscriber: @MaciejSobolewski

#66467 was marked as duplicate of this issue

#75475 was marked as duplicate of this issue

Added subscribers: @fclem, @mano-wii

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.
@fclem, any idea why this is happening?

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. @fclem, any idea why this is happening?

Added subscriber: @jinschoi

Added subscriber: @onedev

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

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?

Added subscriber: @JacquesLucke

Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'

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.

Added subscriber: @VictorBonnet

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:

Shading:
   psl -> material_pass 995.01ms 99

Blender 2.80:

Shading:
   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.

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: ``` Shading: psl -> material_pass 995.01ms 99 ``` Blender 2.80: ``` Shading: psl -> material_pass 171.42ms 99 ``` I also noticed that the GPU usage is much higher with **2.80**. ![GPU.png](https://archive.blender.org/developer/F8380344/GPU.png) I can share a blender file if that could help.

Added subscriber: @ideasman42

@VictorBonnet, 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 #66231, since it is related to Mac + AMD and fails in the material_pass.

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

I am having the the same issue as #66231 . 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.
home_2.8.blend

I am having the the same issue as [#66231 ](https://developer.blender.org/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. [home_2.8.blend](https://archive.blender.org/developer/F8399910/home_2.8.blend)

Changed status from 'Needs User Info' to: 'Needs Triage'

@VictorBonnet, the textures are not packed in the file, will this affect the tests?

@VictorBonnet, the textures are not packed in the file, will this affect the tests? ![pink.png](https://archive.blender.org/developer/F8417840/pink.png)

Sorry about that.

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

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.

I manage to find which commit introduce the slowness on my computer. It starts to be slow after this [commit ](https://git.blender.org/gitweb/gitweb.cgi/blender.git/commitdiff/3a08153d7a842b7ab1e40a9048730e1a3ddab5f7) 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.

Added subscriber: @Mambes

Added subscribers: @jerrsoundripper, @2046411367, @william-70, @ZedDB, @WilliamReynish

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @DanielGrauer

Added subscriber: @JulianEisel

@JulianEisel Could you test if P1388 changes anything?

@JulianEisel Could you test if [P1388](https://archive.blender.org/developer/P1388.txt) changes anything?

@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

@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

@VictorBonnet 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

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:

after.trace.zip

I profiled the application before and after the [commit ](https://git.blender.org/gitweb/gitweb.cgi/blender.git/commitdiff/3a08153d7a842b7ab1e40a9048730e1a3ddab5f7) that cause the slowness. The CPU is at 100% constantly after the commit: ![Screenshot 2020-05-15 at 20.01.57.png](https://archive.blender.org/developer/F8537488/Screenshot_2020-05-15_at_20.01.57.png) before the commit: ![Screenshot 2020-05-15 at 20.11.09.png](https://archive.blender.org/developer/F8537490/Screenshot_2020-05-15_at_20.11.09.png) [after.trace.zip](https://archive.blender.org/developer/F8537492/after.trace.zip)

@VictorBonnet 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. #66231 is the same issue but from another state since D7642 does not fix it.

@VictorBonnet 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. #66231 is the same issue but from another state since [D7642](https://archive.blender.org/developer/D7642) does not fix it.

Added subscriber: @robbott

Probably the same bug as #71398 .

@VictorBonnet 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
ground.blend

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 [ground.blend](https://archive.blender.org/developer/F8542059/ground.blend)

Added subscriber: @dfelinto

@VictorBonnet 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.

@VictorBonnet 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.

test.blend

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. [test.blend](https://archive.blender.org/developer/F8547060/test.blend)

@VictorBonnet What if you use the same texture in both materials?

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

@VictorBonnet 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?

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?

In #70445#936867, @VictorBonnet wrote:
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).

> In #70445#936867, @VictorBonnet wrote: > 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.

Instruments.trace.zip

Ok, it seems so. I attached a screenshot and the trace file. ![Screenshot 2020-05-22 at 17.42.33.png](https://archive.blender.org/developer/F8548092/Screenshot_2020-05-22_at_17.42.33.png) [Instruments.trace.zip](https://archive.blender.org/developer/F8548090/Instruments.trace.zip)

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 https://html.developreference.com/article/22542374/Is+ordering+between+glUniformBlockBinding+and+glBindBufferBase+important%3F

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.

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. ![Capture d’écran du 2020-05-22 18-26-13.png](https://archive.blender.org/developer/F8548222/Capture_d_écran_du_2020-05-22_18-26-13.png) 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 https://html.developreference.com/article/22542374/Is+ordering+between+glUniformBlockBinding+and+glBindBufferBase+important%3F >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](https://archive.blender.org/developer/D4997) I can suggest [P1412](https://archive.blender.org/developer/P1412.txt) 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 ](https://developer.blender.org/T70445) but unfortunately it doesn't fix.

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

I tried [[P1412](https://archive.blender.org/developer/P1412.txt) ](https://developer.blender.org/T70445) but unfortunately it doesn't fix. I'll try to play with the APIs on my side.

Added subscriber: @MirekDusin

@fclem I noticed that the issue with the Texture Coordinate is only reproducible on tmp-eevee-material-refactorbranch but not onmaster.

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

@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.

This issue was referenced by cecda64e2e

This issue was referenced by cecda64e2ead502a052f9bea5ffde39e4a46bf90

Added subscriber: @bblanimation

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.

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.

Changed status from 'Confirmed' to: 'Resolved'

when I first switch to render mode it's slower

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

>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.

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

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

@fclem Yes the slowdown is caused by this commit.

@VictorBonnet 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.

@VictorBonnet 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.
cecda64e2ead.trace.zip

Here it is. [cecda64e2ead.trace.zip](https://archive.blender.org/developer/F8574952/cecda64e2ead.trace.zip)

@VictorBonnet 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?

Ah sorry about that.

Ah sorry about that. ![Screenshot 2020-06-03 at 23.27.53.png](https://archive.blender.org/developer/F8575067/Screenshot_2020-06-03_at_23.27.53.png)

@VictorBonnet and what is inside GPU_shaderinterface_create?

@VictorBonnet and what is inside `GPU_shaderinterface_create`?

![Screenshot 2020-06-04 at 08.18.18.png](https://archive.blender.org/developer/F8575807/Screenshot_2020-06-04_at_08.18.18.png)

Removed subscriber: @Mambes

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 fd061f61c7. Hopefully it fixes the issue. Else better open a new task for discussing this.

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 fd061f61c7. Hopefully it fixes the issue. Else better open a new task for discussing this.

@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:

Version	Animation fps	Shader compilation
2.80	~2.6	~27s
2.82	~0.3	~27s
master	~3.6	~1min 50s
`fd061f61c7`	~3.6	~22s

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

@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: | Version | Animation fps | Shader compilation | -- | -- | -- | | 2.80 | ~2.6 | ~27s | | 2.82 | ~0.3 | ~27s | | master | ~3.6 | ~1min 50s | | fd061f61c7 | ~3.6 | ~22s | That's quite impressive how faster things are now on my computer (at least with this blend file). Thanks @fclem

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Very slow Eevee performance on Mac with AMD Radeon #70445