Page MenuHome

Regression: Massive drops in Animation playback (fps) in the viewport
Needs Information from Developers, NormalPublicKNOWN ISSUE

Description

**System Information**
Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-fedora-36-Rawhide 64 Bits
Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44
versionVSYNCfps solidfps materialfps rendered
2.92off2308061
2.93.9 (regression caused by rB7f7e6830991b: EEVEE: Refactor closure_lit_lib.glsl)off2307655
2.93.9 (regression caused by rB64d96f68d6ef: EEVEE: Ambient Occlusion: Refactor)off2306946
2.93.9 (regression caused by rB267a9e14f5a7: EEVEE: ScreenSpaceReflections: Add back multi ray-hitpoint reuse)off2305741
3.0.1 (regression caused by rB03013d19d167: Eevee: support accessing custom mesh attributes)off2005741
3.1.2 (regression caused by rBd09b1d275986: Fix T94464: video texture is not refreshing)off1105741
3.2beta (regression caused by rB80859a6cb272: GPU: Make nodetree GLSL Codegen render engine agnostic)off1075437
**System Information**
Win 10
GTX 1070 - Studio Driver 462.59
versionVSYNCfps solidfps materialfps rendered
2.92off22314385
3.0 and Cycles-Xoff796650

Short description of error
Massive drops in Animation playback

Exact steps for others to reproduce the error
I have this test scene here from the forum (unfortunately I forgot the direct link).

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.May 12 2021, 12:42 PM

Can confirm, will bisect.

Philipp Oeser (lichtwerk) changed the task status from Confirmed to Needs Information from Developers.May 12 2021, 1:09 PM
Philipp Oeser (lichtwerk) triaged this task as High priority.

Apparently caused by rB267a9e14f5a7: EEVEE: ScreenSpaceReflections: Add back multi ray-hitpoint reuse (at least for Material and Rendered viewport shading - cannot speak for Solid)

This might all be expected behavior, will let @Clément Foucault (fclem) decide.

rB267a9e14f5a7 may have introduce a bit more overhead but not that much (would expect max 5% change). This seems to affect all modes.

I tried to reproduce but 2.92 & 2.93 & 3.0 release gives me almost exactly the same results (no regression) on a GTX 960M and an AMD Radeon Pro WX7100 on linux. Will try on windows.

Edit: I cannot reproduce the slowdown on windows either (GTX 960).

Sadly I can repro here:
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 466.27
High-DPI display (4k so there's lots of pixels to shade)

2.92
Solid: 61fps
Material Preview: 43fps
Rendered: 34fps

3.0 06e62adfb8f2
Solid: 59fps
Material Preview: 26fps
Rendered: 21fps

Hi Clément and Jesse,

to prevent the frequency of your monitor from limiting the playback speed,
switch the vertical sync to off.

Thanks for the hint, I edited my comment. I disabled vsync and then used a script to count how long it took to animate across the 250 frames and calculated fps from that. The numbers above should be pretty accurate now. (yeah, even at 4k the default cube scene maxes out at ~70fps for me on both versions so the 60fps numbers there seem right for solid view)

I have FHD on my GTX 1070 and in Solid 223 fps.
So about four times the fps at a quarter of the resolution, is about right.

I'm seeing the same issue, on two different machines (both win10, different NVidia cards). Viewport shows 18-25 fps in solid mode, drops to ~12 fps in shaded or rendered.
I have narrowed it down to a combination of armature and subdiv modifiers. Order of modifiers doesn't seem to matter, presumably if the the armature comes first it forces the subdiv to update every frame, or conversely if subdiv comes first it creates more work for the armature deform. The number of bones seems to affect it quite a bit.

Here's a simplified test file:

Can only reproduce on debug build. All release builds works fine here (2.92, 2.93.7, 3.2)
@Philipp Oeser (lichtwerk) , can you recheck?

Can only reproduce on debug build. All release builds works fine here (2.92, 2.93.7, 3.2)
@Philipp Oeser (lichtwerk) , can you recheck?

Getting this in release builds as well, noticable with VSYNC ON or OFF

Thanks, that is a strange one. The source points to a diff that is eevee internal. but the bug is also about workbench. I suspect that there is a different change happened, but the mentioned commit only exaggerate it. I'll build a similar configuration and see if I am able to point to a different cause.

**System Information**
Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-fedora-36-Rawhide 64 Bits
Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44

So to be precise, this is what I am getting (I will take some time bisecting things as performance seems to have taken various hits...):
Will update this table as bisecting progresses.
The culprit for the regression in material/rendered between 2.92 and 2.93 I think we have already found in rB267a9e14f5a7.

versionVSYNCfps solidfps materialfps rendered
2.92off2308061
2.93.9 (regression caused by rB267a9e14f5a7)off2305741
3.0.1 (regression caused by rB03013d19d167)off2005741
3.1.2 (regression caused by rBd09b1d275986)off1105741
3.2beta (regression caused by rB80859a6cb272)off1075437
Philipp Oeser (lichtwerk) renamed this task from 2.92 to 3.0 - Massive drops in Animation playback (fps) in the viewport to Massive drops in Animation playback (fps) in the viewport.Fri, May 13, 12:42 PM
Philipp Oeser (lichtwerk) updated the task description. (Show Details)
Philipp Oeser (lichtwerk) renamed this task from Massive drops in Animation playback (fps) in the viewport to Regression: Massive drops in Animation playback (fps) in the viewport.Fri, May 13, 3:20 PM
Philipp Oeser (lichtwerk) updated the task description. (Show Details)

Fleshing out something like T98100: Monitor FPS playback regressions in time for workbench and eevee and adding that to test should help prevent this in the future hopefully

Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Bug".Mon, May 16, 11:52 AM

On my system (Linux + GTX760 + 470 drivers) I got a different cause for the eevee regression.

rBba75ea801208: EEVEE: Use Fullscreen maxZBuffer instead of halfres
rB6842c549bb3f: EEVEE: SSRayTrace: Cleanup/Refactor

Looking at the code I would think rB6842c549bb3f: EEVEE: SSRayTrace: Cleanup/Refactor
is more likely to be the culprit.

Jeroen Bakker (jbakker) lowered the priority of this task from High to Normal.Mon, May 16, 1:38 PM
Jeroen Bakker (jbakker) changed the subtype of this task from "Bug" to "Known Issue".

Looking at the current results there isn't a single commit that can be pointed out as the root cause. There are multiple commits that reduced the performance. Some are more visible depending on the actual platform you're using.

Eevee is always optimized to the latest generation GPUs. What also leads to performance regressions to previous generations as GPU architectures can be totally different between generations.

With the upcoming eevee-next I would not spend to much time on getting the FPS back to what it was as it would require re-development and could impact the quality or performance in different ways.

Thing we should learn from this task is that monitoring is very important. Will check to set something up here that would create those kind of reports T98100: Monitor FPS playback regressions in time for workbench and eevee.

For now lowering this issue and set it to known issue.

A huge thanks to everyone involved!

Small question, is this only impacting the viewport, or is it affecting the rendering (to image files) as well?

During final rendering to images the slowdown isn't that noticeable as writing to file and color management would be much more of a performance bottleneck.