Very Slow Workbench/Eevee Performance #70463
Labels
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#70463
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Added subscriber: @tibor81
Added subscribers: @fclem, @Jeroen-Bakker, @brecht
@fclem @Jeroen-Bakker can either of you reproduce?
Added subscriber: @LazyDodo
I can confirm, the difference between 2.80 and latest master (measured with fraps cause blender's counter was waaaaaaaaaay to jumpy)
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/
Added subscriber: @kosblend
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.This issue was referenced by
663d23dd9d
Changed status from 'Open' to: 'Resolved'
Changed status from 'Resolved' to: 'Open'
Added subscriber: @Sergey
Retested this ticket, no measurable improvement with the fix committed by @fclem
4707f1982d
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 ?
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
4707f1982d
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
, openingfps-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?
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
@Sergey wrote:
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
@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.
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.
4707f1982d
With P1129 applied, it does seem to suggest there may be a second commit involved causing the slowdown.
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)Might be due to missing subdivision surface modifier in the lite build.
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? :)
@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.
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.
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.
Added subscriber: @StanislavOvcharov
@LazyDodo is there still a problem here, or can we close this now?
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.
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?
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...
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..
@LazyDodo, hah!
@fclem, what do you think about performance loss in wireframe mode?
@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),
@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'
I think this can be closed then.
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
@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