Very Slow Workbench/Eevee Performance #70463

Closed
opened 2019-10-02 20:17:54 +02:00 by Tibor Horvath · 46 comments

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: AMD Radeon VII ATI Technologies Inc. 4.5.13558 Core Profile Context 26.20.11015.5009

Blender Version
Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-10-01 19:51, hash: 3b23685c7d
Worked: 2.8

Short description of error
Scenes with many objects have very bad performance / fps, compared to Blender 2.8!
My attached example scene is an Import from SketchUP and has around 1500 mesh objects and 250k faces. With regular 2.8 Version I get around 110fps in workbench and 33fps in eevee. With the newest 2.81 alpha build I get 53fps in workbench and 9fps!! in eevee!

Exact steps for others to reproduce the error
Open attached file and press play in workbench and eevee mode. Make sure, that overlays are on, to see the fps. And compare the file and fps with the regular 2.8 version
fps-performance.blend

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: AMD Radeon VII ATI Technologies Inc. 4.5.13558 Core Profile Context 26.20.11015.5009 **Blender Version** Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-10-01 19:51, hash: `3b23685c7d` Worked: 2.8 **Short description of error** Scenes with many objects have very bad performance / fps, compared to Blender 2.8! My attached example scene is an Import from SketchUP and has around 1500 mesh objects and 250k faces. With regular 2.8 Version I get around 110fps in workbench and 33fps in eevee. With the newest 2.81 alpha build I get 53fps in workbench and 9fps!! in eevee! **Exact steps for others to reproduce the error** Open attached file and press play in workbench and eevee mode. Make sure, that overlays are on, to see the fps. And compare the file and fps with the regular 2.8 version [fps-performance.blend](https://archive.blender.org/developer/F7786116/fps-performance.blend)
Author

Added subscriber: @tibor81

Added subscriber: @tibor81

Added subscribers: @fclem, @Jeroen-Bakker, @brecht

Added subscribers: @fclem, @Jeroen-Bakker, @brecht

@fclem @Jeroen-Bakker can either of you reproduce?

@fclem @Jeroen-Bakker can either of you reproduce?
Member

Added subscriber: @LazyDodo

Added subscriber: @LazyDodo
Member

I can confirm, the difference between 2.80 and latest master (measured with fraps cause blender's counter was waaaaaaaaaay to jumpy)

2.80 master
solid 120 fps 88 fps
eevee 73 fps 57 fps
workbench 118 fps 87 fps
wireframe 99 fps 63 fps
I can confirm, the difference between 2.80 and latest master (measured with fraps cause blender's counter was waaaaaaaaaay to jumpy) ||2.80|master| | -- | -- | -- | |solid|120 fps|88 fps| |eevee|73 fps|57 fps| |workbench|118 fps|87 fps| |wireframe|99 fps|63 fps|

Added subscriber: @JacobMerrill-1

Added subscriber: @JacobMerrill-1

one thing that may kill multiple birds with 1 stone is ATAA
we have artifacts and it's slow using current TAA.

after anything slowing the render down is taken care of this may be another step to get it faster.
scales much better than FXAA, and does not have the drawbacks of TAA.

https://thisistian.github.io/post/adaptive-temporal-antialiasing-without-rtx/

one thing that may kill multiple birds with 1 stone is ATAA we have artifacts and it's slow using current TAA. after anything slowing the render down is taken care of this may be another step to get it faster. scales much better than FXAA, and does not have the drawbacks of TAA. https://thisistian.github.io/post/adaptive-temporal-antialiasing-without-rtx/

Added subscriber: @kosblend

Added subscriber: @kosblend

Added subscriber: @pedroreis.ad

Added subscriber: @pedroreis.ad

Ok so there is some overhead of the MultiDrawIndirect system (more noticeable on certain drivers) that can easily be avoided to fix this particular issue.

But investigating this I found out that current performance is not the one initially reported when committing ce34a6b0d7. This means something has slow down the rendering after this commit. Going to bisect.

Ok so there is some overhead of the MultiDrawIndirect system (more noticeable on certain drivers) that can easily be avoided to fix this particular issue. But investigating this I found out that current performance is not the one initially reported when committing ce34a6b0d7. This means something has slow down the rendering after this commit. Going to bisect.

This issue was referenced by 663d23dd9d

This issue was referenced by 663d23dd9dc4801a679b00e5d8ac80483d9b36a8

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Clément Foucault self-assigned this 2019-10-04 16:30:04 +02:00
Member

Changed status from 'Resolved' to: 'Open'

Changed status from 'Resolved' to: 'Open'
Member

Added subscriber: @Sergey

Added subscriber: @Sergey
Member

Retested this ticket, no measurable improvement with the fix committed by @fclem

2.80 oct 2 oct5 4707f1982d
solid 120 fps 88 fps 90 fps
eevee 73 fps 57 fps 55 fps
workbench 118 fps 87 fps 88 fps
wireframe 99 fps 63 fps 62 fps

spend a few hours bisecting and tracked it down to 1693a5efe9

@Sergey mind taking a peek here and see if anything can be done?

Retested this ticket, no measurable improvement with the fix committed by @fclem ||2.80|oct 2| oct5 4707f1982ddb | | -- | -- | -- | -- | |solid|120 fps|88 fps|90 fps| |eevee|73 fps|57 fps|55 fps| |workbench|118 fps|87 fps|88 fps| |wireframe|99 fps|63 fps|62 fps| spend a few hours bisecting and tracked it down to 1693a5efe9 @Sergey mind taking a peek here and see if anything can be done?

@LazyDodo, mind checking D6002 ?

@LazyDodo, mind checking [D6002](https://archive.blender.org/developer/D6002) ?
Author

For me is already a big improvement with the fix from Clément, whit almost identical framerates in comparison to the stable 2.8.
And it depends on the scene: In one case with 20000 scattered plant instances the 2.81 alpha from oct 5 is near double the framerate in eevee. And in another test with 40000 scattered (with Jacques Lucke's scatter objects) subdivided suzanne's, 2.8 is a bit faster then 2.81

For me is already a big improvement with the fix from Clément, whit almost identical framerates in comparison to the stable 2.8. And it depends on the scene: In one case with 20000 scattered plant instances the 2.81 alpha from oct 5 is near double the framerate in eevee. And in another test with 40000 scattered (with Jacques Lucke's scatter objects) subdivided suzanne's, 2.8 is a bit faster then 2.81
Member
2.80 oct 2 oct5 4707f1982d D6002
solid 120 fps 88 fps 90 fps 92 fps
eevee 73 fps 57 fps 55 fps 57 fps
workbench 118 fps 87 fps 88 fps 94 fps
wireframe 99 fps 63 fps 62 fps 64 fps

D6002 is without a doubt an improvement, but nowhere near 2.80 numbers still, not sure how much time we should put into this though @brecht / @Sergey can probably better decide there. I have to admit I was mostly curious on why it slowed down, now that i know i'm perfectly happy with 'this is as good as it is gonna get without breaking other stuff'

||2.80|oct 2| oct5 4707f1982ddb |[D6002](https://archive.blender.org/developer/D6002)| | -- | -- | -- | -- | -- | |solid|120 fps|88 fps|90 fps|92 fps| |eevee|73 fps|57 fps|55 fps|57 fps| |workbench|118 fps|87 fps|88 fps|94 fps| |wireframe|99 fps|63 fps|62 fps|64 fps| [D6002](https://archive.blender.org/developer/D6002) is without a doubt an improvement, but nowhere near 2.80 numbers still, not sure how much time we should put into this though @brecht / @Sergey can probably better decide there. I have to admit I was mostly curious on why it slowed down, now that i know i'm perfectly happy with 'this is as good as it is gonna get without breaking other stuff'

@LazyDodo, This is barely measurable difference. I've seen better improvement in my test, but we might be having different bottlenecks.

How do you measure? I've got environment variable __GL_SYNC_TO_VBLANK =0, opening fps-performance.blend file, switching to rendered viewport and hitting playback. For me the patch gave about 10%-20% improvement.

Might also be that it's not the only source of slowdown. What if you revert my changes in depsgraph by applying P1129?

Not sure how much time we should put into this though.

Depends on where the root of the slowdown is. If this is something what affects any scene even with real animation (my initial patch was solving speed regression happening in a fully static scene) we should solve that.

@LazyDodo, This is barely measurable difference. I've seen better improvement in my test, but we might be having different bottlenecks. How do you measure? I've got environment variable `__GL_SYNC_TO_VBLANK =0`, opening `fps-performance.blend` file, switching to rendered viewport and hitting playback. For me the patch gave about 10%-20% improvement. Might also be that it's not the only source of slowdown. What if you revert my changes in depsgraph by applying [P1129](https://archive.blender.org/developer/P1129.txt)? > Not sure how much time we should put into this though. Depends on where the root of the slowdown is. If this is something what affects any scene even with real animation (my initial patch was solving speed regression happening in a fully static scene) we should solve that.

Added subscriber: @YAFU

Added subscriber: @YAFU

@Sergey wrote:

SYNC_TO_VBLANK =0`

Hi. How does it influence Blender? Is it advisable to have it enabled or disabled from nvidia settings?.

I have Sync to VBlank activated in nvidia settings (Linux - GTX 960), and with default scene and custom frame rate=1000 I get a maximum of 60 fps in text overlay indication in viewport in Blender 2.79 and 2.8x. It is weird for me that it is almost fixed at 60 fps at 2.79 and 2.8x (red text anyway).
If I disable Sync to VBlank in nvidia settings and open Blender, I can get values of up to 450 fps in workbench (no more 60 fps limitation).
So if all this depends on GPU driver settings, then possibly we users are measuring fps erroneously in some cases.

EDIT:
Ok, I read that apparently Sync to VBlank is related to the frequency of the monitor, that's why 60 fps. I'm still not sure which is the best configuration in this regard for blender.

@Sergey wrote: >SYNC_TO_VBLANK =0` Hi. How does it influence Blender? Is it advisable to have it enabled or disabled from nvidia settings?. I have Sync to VBlank activated in nvidia settings (Linux - GTX 960), and with default scene and custom frame rate=1000 I get a maximum of 60 fps in text overlay indication in viewport in Blender 2.79 and 2.8x. It is weird for me that it is almost fixed at 60 fps at 2.79 and 2.8x (red text anyway). If I disable Sync to VBlank in nvidia settings and open Blender, I can get values of up to 450 fps in workbench (no more 60 fps limitation). So if all this depends on GPU driver settings, then possibly we users are measuring fps erroneously in some cases. EDIT: Ok, I read that apparently Sync to VBlank is related to the frequency of the monitor, that's why 60 fps. I'm still not sure which is the best configuration in this regard for blender.

With Sync to VBlank off in nvidia settings and fps-performance.blend scene (but custom frame rate=1000) I get:

*Workbench
Master: ~140 fps
Master Sergey patch: ~170fps
2.80 official release: ~190fps

*Eevee Rendered View
Master: ~70 fps
Master Sergey patch: ~70 fps
2.80 official release: ~62 fps

With Sync to VBlank off in nvidia settings and fps-performance.blend scene (but custom frame rate=1000) I get: *Workbench Master: ~140 fps Master Sergey patch: ~170fps 2.80 official release: ~190fps *Eevee Rendered View Master: ~70 fps Master Sergey patch: ~70 fps 2.80 official release: ~62 fps

@YAFU for users Sync to VBlank is fine. There is no point redrawing the viewport more often than the monitor can display. Just for benchmarking it's something to be aware of.

@YAFU for users Sync to VBlank is fine. There is no point redrawing the viewport more often than the monitor can display. Just for benchmarking it's something to be aware of.

Ok, thanks for the explanation Brecht.

Ok, thanks for the explanation Brecht.
Member

my measurements were with vsync off, taken with fraps with a blender release build on windows, picked the highest number that stayed long enough on screen for me to actually read it.

2.80 oct 2 oct5 4707f1982d D6002 P1129
solid 120 fps 88 fps 90 fps 92 fps 102 fps
eevee 73 fps 57 fps 55 fps 57 fps 60 fps
workbench 118 fps 87 fps 88 fps 94 fps 103 fps
wireframe 99 fps 63 fps 62 fps 64 fps 68 fps

With P1129 applied, it does seem to suggest there may be a second commit involved causing the slowdown.

my measurements were with vsync off, taken with fraps with a blender release build on windows, picked the highest number that stayed long enough on screen for me to actually read it. ||2.80|oct 2| oct5 4707f1982ddb |[D6002](https://archive.blender.org/developer/D6002)|[P1129](https://archive.blender.org/developer/P1129.txt)| | -- | -- | -- | -- | -- | -- | |solid|120 fps|88 fps|90 fps|92 fps|102 fps| |eevee|73 fps|57 fps|55 fps|57 fps|60 fps| |workbench|118 fps|87 fps|88 fps|94 fps|103 fps| |wireframe|99 fps|63 fps|62 fps|64 fps|68 fps| With [P1129](https://archive.blender.org/developer/P1129.txt) applied, it does seem to suggest there may be a second commit involved causing the slowdown.
Member

Started bisecting with a lite build rather than a full build hoping it would could down the time required, and the numbers didn't seem to line up at all. here's something interesting:

both builds are on the same commit a clean 4707f1982d (no diffs or patches)

full lite
solid 88 fps 111 fps
eevee 59 fps 66 fps
workbench 93 fps 109 fps
wireframe 62fps 66 fps
Started bisecting with a lite build rather than a full build hoping it would could down the time required, and the numbers didn't seem to line up at all. here's something interesting: both builds are on the same commit a clean 4707f1982ddb (no diffs or patches) ||full|lite| | -- | -- | -- | |solid|88 fps|111 fps| |eevee|59 fps|66 fps| |workbench|93 fps|109 fps| |wireframe|62fps|66 fps|

Might be due to missing subdivision surface modifier in the lite build.

Might be due to missing subdivision surface modifier in the lite build.

With P1129 applied, it does seem to suggest there may be a second commit involved causing the slowdown.

Indeed. However, i don't quite understand yet what is the difference between D6002 and P1129 for playback. Nothing obviously wrong is striking me from reading the code and stepping in a debugger. Second pair of eyes? Anyone? :)

> With [P1129](https://archive.blender.org/developer/P1129.txt) applied, it does seem to suggest there may be a second commit involved causing the slowdown. Indeed. However, i don't quite understand yet what is the difference between [D6002](https://archive.blender.org/developer/D6002) and [P1129](https://archive.blender.org/developer/P1129.txt) for playback. Nothing obviously wrong is striking me from reading the code and stepping in a debugger. Second pair of eyes? Anyone? :)

@LazyDodo, mind doing one more test? :) Apply P1130 on top of D6002 and see the numbers.
For me it showed extra speedup and profiler looks nicer as well.

master master_bottom_up.png master_caller_callee.png
D6002 D6002_bottom_up.png D6002_caller_callee.png
D6002 + P1130 D6002_P1130_bottom_up.png D6002_P1130_caller_callee.png

From dependency graph point of view, i think D6002 is definitely something we should have in (after reviewing by extra eyes).
P1130 gives nice results here, but is more platform and file specific. But kind of makes sense to NOT use threading to re-set single field of every element in an array.

Can't speak for other possible sources of slowdown though.

@LazyDodo, mind doing one more test? :) Apply [P1130](https://archive.blender.org/developer/P1130.txt) on top of [D6002](https://archive.blender.org/developer/D6002) and see the numbers. For me it showed extra speedup and profiler looks nicer as well. | master | ![master_bottom_up.png](https://archive.blender.org/developer/F7794548/master_bottom_up.png) | ![master_caller_callee.png](https://archive.blender.org/developer/F7794550/master_caller_callee.png) | -- | -- | -- | | [D6002](https://archive.blender.org/developer/D6002) | ![D6002_bottom_up.png](https://archive.blender.org/developer/F7794552/D6002_bottom_up.png) | ![D6002_caller_callee.png](https://archive.blender.org/developer/F7794554/D6002_caller_callee.png) | [D6002](https://archive.blender.org/developer/D6002) + [P1130](https://archive.blender.org/developer/P1130.txt) | ![D6002_P1130_bottom_up.png](https://archive.blender.org/developer/F7794557/D6002_P1130_bottom_up.png) | ![D6002_P1130_caller_callee.png](https://archive.blender.org/developer/F7794560/D6002_P1130_caller_callee.png) From dependency graph point of view, i think [D6002](https://archive.blender.org/developer/D6002) is definitely something we should have in (after reviewing by extra eyes). [P1130](https://archive.blender.org/developer/P1130.txt) gives nice results here, but is more platform and file specific. But kind of makes sense to NOT use threading to re-set single field of every element in an array. Can't speak for other possible sources of slowdown though.

Removed subscriber: @pedroreis.ad

Removed subscriber: @pedroreis.ad

I've committed tweaks to the early output. So in theory after that the depsgraph performance should be same as 2.80.

If performance is still not the same for some setups there is another source of slowdown.

P.S. On top of the committed speedup i've created another patch D6017 to bring performance even higher from depsgraph/threading point of view, but that is a separate story.

I've committed tweaks to the early output. So in theory after that the depsgraph performance should be same as 2.80. If performance is still not the same for some setups there is another source of slowdown. P.S. On top of the committed speedup i've created another patch [D6017](https://archive.blender.org/developer/D6017) to bring performance even higher from depsgraph/threading point of view, but that is a separate story.

Added subscriber: @StanislavOvcharov

Added subscriber: @StanislavOvcharov

@LazyDodo is there still a problem here, or can we close this now?

@LazyDodo is there still a problem here, or can we close this now?
Member

I don't think i'm the most qualified to make the call here, It's a 20% drop across the board (on this particular scene) if that's acceptable or not should be up to to the module owners.

2.80 master oct2 master oct 24
solid 120 fps 88 fps 92 fps (-23% from 2.80)
eevee 73 fps 57 fps 57 fps (-21% from 2.80)
workbench 118 fps 87 fps 92 fps (-22% from 2.80)
wireframe 99 fps 63 fps 66 fps (-33% from 2.80)

Personally i'm ok with this, it's not like it's chugging along at 0.5 fps, and i think once we get serious about VR we'll get some further optimizations to hit the VR perf targets required for a smooth experience.

I don't think i'm the most qualified to make the call here, It's a 20% drop across the board (on this particular scene) if that's acceptable or not should be up to to the module owners. ||2.80|master oct2|master oct 24 | -- | -- | -- | -- | |solid|120 fps|88 fps|92 fps (-23% from 2.80) | |eevee|73 fps|57 fps|57 fps (-21% from 2.80) |workbench|118 fps|87 fps|92 fps (-22% from 2.80)| |wireframe|99 fps|63 fps|66 fps (-33% from 2.80)| Personally i'm ok with this, it's not like it's chugging along at 0.5 fps, and i think once we get serious about VR we'll get some further optimizations to hit the VR perf targets required for a smooth experience.

@LazyDodo do you have a way to profile this? I can not reproduce slowdown on linux, but it could all be threading/video driver related.

The fact that there is 20% slowdown burried is quite worrying. If it comes from drawing then it means the "real" animation playback is also slower.
If it's something in the dependency graph, then it's even more weird because i wouldn't expect any slowdown in the changes since 2.80.

Are you testing same exact .blend file? Maybe defaults got changed?

@LazyDodo do you have a way to profile this? I can not reproduce slowdown on linux, but it could all be threading/video driver related. The fact that there is 20% slowdown burried is quite worrying. If it comes from drawing then it means the "real" animation playback is also slower. If it's something in the dependency graph, then it's even more weird because i wouldn't expect any slowdown in the changes since 2.80. Are you testing same exact .blend file? Maybe defaults got changed?
Member

I'm an idiot:

[insert bart writing on the black board here]

I should not be comparing RelWithDebInfo performance to Release Performance
I should not be comparing RelWithDebInfo performance to Release Performance
I should not be comparing RelWithDebInfo performance to Release Performance
I should not be comparing RelWithDebInfo performance to Release Performance

I knew this, and i should have known better...

2.80(Release) master oct2(RelWithDebInfo) master oct 24 (RelWithDebInfo) master Oct 28 (Release)
solid 120 fps 88 fps 92 fps (-23% from 2.80) 120 fps
eevee 73 fps 57 fps 57 fps (-21% from 2.80) 72 fps
workbench 118 fps 87 fps 92 fps (-22% from 2.80) 121 fps
wireframe 99 fps 63 fps 66 fps (-33% from 2.80) 85 fps

So yeah, you can close this.

I'm an idiot: [insert bart writing on the black board here] I should not be comparing RelWithDebInfo performance to Release Performance I should not be comparing RelWithDebInfo performance to Release Performance I should not be comparing RelWithDebInfo performance to Release Performance I should not be comparing RelWithDebInfo performance to Release Performance I knew this, and i should have known better... ||2.80(Release)|master oct2(RelWithDebInfo)|master oct 24 (RelWithDebInfo)|master Oct 28 (Release) | -- | -- | -- | -- | -- | |solid|120 fps|88 fps|92 fps (-23% from 2.80) |120 fps| |eevee|73 fps|57 fps|57 fps (-21% from 2.80)|72 fps| |workbench|118 fps|87 fps|92 fps (-22% from 2.80)|121 fps| |wireframe|99 fps|63 fps|66 fps (-33% from 2.80)|85 fps| So yeah, you can close this.

I have a scene with simple rigged character (rigify+physics) and I get about 20 fps in material preview shading mode in 2.80, and get about only 9 fps in 2.81 in the same file (there is no such difference in a solid mode, 2.80 and 2.81 almost equal). Win 8.1 gtx 970m. last drivers. But in scene with Vincent (blenrig) there is no such a huge difference in material preview mode, 2.81 even a bit faster for a couple of fps. some kind of a mystery..

I have a scene with simple rigged character (rigify+physics) and I get about 20 fps in material preview shading mode in 2.80, and get about only 9 fps in 2.81 in the same file (there is no such difference in a solid mode, 2.80 and 2.81 almost equal). Win 8.1 gtx 970m. last drivers. But in scene with Vincent (blenrig) there is no such a huge difference in material preview mode, 2.81 even a bit faster for a couple of fps. some kind of a mystery..

@LazyDodo, hah!

@fclem, what do you think about performance loss in wireframe mode?

@StanislavOvcharov, without demo .blend file we can not even investigate.

@LazyDodo, hah! @fclem, what do you think about performance loss in wireframe mode? @StanislavOvcharov, without demo .blend file we can not even investigate.

In #70463#802746, @Sergey wrote:

@StanislavOvcharov, without demo .blend file we can not even investigate.

I understand it, but unfortunately can't share it because of NDA

> In #70463#802746, @Sergey wrote: > > @StanislavOvcharov, without demo .blend file we can not even investigate. I understand it, but unfortunately can't share it because of NDA

@StanislavOvcharov, there is always a way top simplify the scene or make it shareable (delete everything what is not relevant for the bug, replace materials, replace meshes and so on),

@StanislavOvcharov, there is always a way top simplify the scene or make it shareable (delete everything what is not relevant for the bug, replace materials, replace meshes and so on),

@Sergey the slight loss of fps in wireframe may be due to the wireframe mesh not being as tight as it used to be (using loop indexing instead of vertex indexing).
This leads to less coherent GPU cache usage during vertex processing (and potentially more vertex shaders invocation).
But this was a design decision to simplify a lot of complexity on the mesh extract backend and VRAM usage.

So I would say that everything is fine for me.

@Sergey the slight loss of fps in wireframe may be due to the wireframe mesh not being as tight as it used to be (using loop indexing instead of vertex indexing). This leads to less coherent GPU cache usage during vertex processing (and potentially more vertex shaders invocation). But this was a design decision to simplify a lot of complexity on the mesh extract backend and VRAM usage. So I would say that everything is fine for me.

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

I think this can be closed then.

I think this can be closed then.

Added subscriber: @cheteron

Added subscriber: @cheteron

left: Blender 2.81
right: Blender 2.79
where is optimizations? Why the topic closes if performance is not increased!!! Where to write to finally fix the performance of the blender?
test.blend
2019-11-10_19-13-02.mp4

left: Blender 2.81 right: Blender 2.79 where is optimizations? Why the topic closes if performance is not increased!!! Where to write to finally fix the performance of the blender? [test.blend](https://archive.blender.org/developer/F8020084/test.blend) [2019-11-10_19-13-02.mp4](https://archive.blender.org/developer/F8020074/2019-11-10_19-13-02.mp4)

In #70463#802760, @Sergey wrote:
@StanislavOvcharov, there is always a way top simplify the scene or make it shareable (delete everything what is not relevant for the bug, replace materials, replace meshes and so

@Sergey Here is that file - robot_fps_bug.blend Just start animation playback. So in Solid shading mode I get about 50 fps in 2.80 and about 60 fps in 2.81. But in the Material preview (Lookdev) or Rendered mode I get about 27 fps in 2.80 and about 9 fps in 2.81 . Seems this problem described here - https://developer.blender.org/T71214

> In #70463#802760, @Sergey wrote: > @StanislavOvcharov, there is always a way top simplify the scene or make it shareable (delete everything what is not relevant for the bug, replace materials, replace meshes and so @Sergey Here is that file - [robot_fps_bug.blend](https://archive.blender.org/developer/F8047542/robot_fps_bug.blend) Just start animation playback. So in Solid shading mode I get about 50 fps in 2.80 and about 60 fps in 2.81. But in the Material preview (Lookdev) or Rendered mode I get about 27 fps in 2.80 and about 9 fps in 2.81 . Seems this problem described here - https://developer.blender.org/T71214
Thomas Dinges added this to the 2.81 milestone 2023-02-08 16:46: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
Interest: X11
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
12 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#70463
No description provided.