Very slow Eevee performance on Mac with AMD Radeon #70445

Closed
opened 2019-10-02 14:25:32 +02:00 by Maciej Sobolewski · 68 comments

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

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

Added subscriber: @MaciejSobolewski

#66467 was marked as duplicate of this issue

#66467 was marked as duplicate of this issue

#75475 was marked as duplicate of this issue

#75475 was marked as duplicate of this issue

Added subscribers: @fclem, @mano-wii

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

Added subscriber: @onedev

Added subscriber: @onedev

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

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?

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?
Member

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke
Member

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

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

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.

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

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

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

Added subscriber: @ideasman42

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

@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)
Member

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

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

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

@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.
Germano Cavalcante changed title from Very slow Eevee performance. Not possible to work. to Very slow Eevee performance on Mac with AMD Radeon 2020-04-07 21:07:45 +02:00

Added subscriber: @Mambes

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

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

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

Added subscriber: @DanielGrauer

Added subscriber: @DanielGrauer

Added subscriber: @JulianEisel

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?

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

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.

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:
Screenshot 2020-05-15 at 20.01.57.png

before the commit:
Screenshot 2020-05-15 at 20.11.09.png

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

Added subscriber: @robbott

Probably the same bug as #71398 .

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.

@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

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.

Screenshot 2020-05-22 at 17.42.33.png

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.

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

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

Added subscriber: @bblanimation

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

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'

Changed status from 'Confirmed' to: 'Resolved'
Clément Foucault self-assigned this 2020-06-03 20:53:58 +02:00

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.

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.

@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](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?

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

Screenshot 2020-06-03 at 23.27.53.png

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

![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

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
Thomas Dinges added this to the 2.90 milestone 2023-02-08 16:27:56 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
16 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#70445
No description provided.