Page MenuHome

Scene strips in the VSE are excessively slow to playback.
Closed, ResolvedPublic

Description

System Information
Operating system: Windows 8.1
Graphics card: Geforce 860m, Geforce 980

Blender Version
Broken: 2.80, 2019-03-10
Worked: 2.79

Short description of error
Scene strips in the vse will play back very slowly. This seems to happen regardless of render engine, or scene preview type in the vse preview settings, tho some settings and engines do provide better performance than others, even the best combination is still terribly slow.
For example: an eevee scene with only a camera and no special effects enabled will play back at 1-2fps in the vse, but animation playback in the 3d viewport will of course be over 30fps.
Note that this is not the same as the slow playback/rendering due to the color transforms, this still happens when the color is set to 'Default' transform and 'None' look.

Exact steps for others to reproduce the error
Create a second Scene
Add that scene to the vse of the first scene
start playback

I have attached a simple .blend file where I have tried to make the playback as efficient as possible... still only get about 2fps.

Details

Differential Revisions
D4738: Sequencer: Scene Strip Performance
Type
Bug

Event Timeline

Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.

Getting an assert when opening that file (might not be related but I'll report it just in case):
BLI_assert failed: /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_window.c:2332, WM_opengl_context_activate(), at 'GPU_framebuffer_active_get() == ((void *)0)'

Can confirm this (also can not open file).

May be outside of my current ability to fix this, as this will probably require modifications in rendering pipeline itself.

In any case shouldn't this have high priority?
Not sure if this is inconvenience or this actually prevents some work to be done at all.

I think we have reserved high priority tasks to severe crashes and widely reported issues ATM.

@Brecht Van Lommel (brecht) high prio or no?

The assert does not affect release builds end users, only debug builds, so would not consider that high priority.

The performance issue is not high priority either I think. There may be some hidden issue here, though I expect a big part is the new viewport and Eevee in particular doing a lot more setup work than the old viewport. For best performance that state could be cached somehow.

In T62517#639720, @Brecht Van Lommel (brecht) wrote:...I expect a big part is the new viewport and Eevee in particular doing a lot more setup work than the old viewport.

Its not just slower than the old viewport tho, its slower than the CURRENT viewport... and not just a bit slower, like a 50x speed decrease.
Also, its not just eevee, it is horribly slow even when in wireframe render mode, or when using workbench render engine.
As for priority, well, its up to you guys, but this effectively makes scene strips unusable in the vse.

@hudson barkley (snuq) Brecht probably meant that VSE code does not have setup of new viewport in place to allow fast rendering.

I will look into this as I should get familiar with that code.
What I am saying is that I can not promise to resolve this (promptly).

@hudson barkley (snuq) Brecht probably meant that VSE code does not have setup of new viewport in place to allow fast rendering.
I will look into this as I should get familiar with that code.
What I am saying is that I can not promise to resolve this (promptly).

Sure, sorry if I came off as demanding or rude, I just wanted to make sure the issue was understood fully. I greatly appreciate the massive work that is going into Blender, especially in maintaining and updating the features like the vse that occasionally get forgotten.

I'm also experiencing this, but I'm sure I had the same issue back when I first tried 2.8 (December 2018)

I've been using sequence strips in 2.8, and haven't noticed a difference in framerate between the sequence strip and the scene it came from. I do have a chunky processor though, and some patches applied.

@Olly Funkster (Funkster) this is problem with 3D scenes..

I looked into this quickly and it seemed to me that program spent most of the time getting data from GPU. This took about 1s per frame in my case.

I guess this can be done much faster.

Brecht Van Lommel (brecht) raised the priority of this task from Confirmed, Medium to Confirmed, High.Apr 1 2019, 2:06 PM
Jeroen Bakker (jbakker) closed this task as Resolved.Apr 30 2019, 2:16 PM

This seems to not be resolved yet, at least not completely (maybe remove the 'excessively' from the title now? heh).
The latest build is MUCH faster, and actually use-able now, but it is still a lot slower than the viewport.
Even with a very basic camera and cube only scene, lookdev (and solid) mode never gets above 20fps in the vse, and rendered mode about 2fps. viewport for both modes is over 30fps.

Using the 2019-04-30 18:56 build, i think that includes the fixes?

Interestingly enough, there seems to be some kind of overhead going on, not just a division of the performance... the lookdev mode never gets above 20fps even for a super basic scene, but when i load down that scene with enough geometry to actually slow down the viewport under 30fps, the vse view is only down to 10fps

@hudson barkley (snuq) When rendering in the viewport every pixels stays on the GPU. The sequencer needs the pixels on the CPU so it transfers everything back to the CPU to do additional sequencer, imaging and color management stuff. when done it transfers the pixels back to the GPU so you can view them. Until the sequencer will be fully migrated to the GPU there will be a slowdown and depends on the actual hardware it runs on.

As a reference machine I use (Ryzen1700 with WX7100), I get 24fps with ease in the VSE even when using wanderer.blend on a debug build in lookdev mode.

Upon further comparisons with blender 2.79, i have noticed similar speeds, with 2.8 only being a couple fps slower with the same setup (the 'material' mode in 2.79 playback being 27fps while the 'lookdev' mode in 2.8 being about 23fps). Similarly, the 'solid' mode is a bit slower in 2.8 as well.
If this smallish slowdown is a bug, or simply new features slowing blender down a bit, I don't know enough to say, I figured I could give some hard numbers just in case.

However, there still seems to be a problem with the 'rendered' mode - it is still VERY slow for no apparent reason. A camera-only scene with no special features turned on plays back at 2fps, while the viewport plays back at over 30 of course. This is less of an issue since lookdev mode should cover most use cases, but it seems there is still a bug in there somewhere.

this may be worth further investigation IMO.

Big issue is, that whole process is single-threaded. This can be resolved with prefetching hopefully to larger than lesser extent.

I can play movie clip(sure 8-bit...) with GLSL color transformation with barely any impact on performance.

I don't know, is the GPU-CPU bandwidth is symmetrical?
Or are 3D renders are significantly larger - 32bit?
Or perhaps reading algorithm from GPU mem is not optimal?

Then question is if it is worth squeezing every bit of performance in this day and age.

I don't know, is the GPU-CPU bandwidth is symmetrical?
Or are 3D renders are significantly larger - 32bit?
Or perhaps reading algorithm from GPU mem is not optimal?
Then question is if it is worth squeezing every bit of performance in this day and age.

I would think the process and speed of copying from the gpu to the vse is the same for rendered mode vs lookdev mode, so I wouldnt expect it to have any additional overhead there... or at least it shouldnt?

I was wondering if blender is doing the vse-rendered mode more as if it were doing a render-to-file mode, instead of viewport-render mode, since rendering to a file is much slower (for good reason tho, sure). If this is the case tho, im not sure WHAT it is doing that is slowing it down that much in a completely basic scene.

And I would definitely say its worth squeezing every bit of performance out of it when relating to the vse, Video pros are constantly pushing for higher resolutions still - 4k is common now, 8k is coming fast, and of course the cg will have to keep up with it...