Page MenuHome

Extreme FPS loss (24x) between 2.79 and 2.8 with particle systems
Open, Confirmed, MediumPublic

Description

System Information
Operating system: Ubuntu 17.10
Graphics card: GTX 1080

Blender Version
Broken: blender2.8 23284e4dde5
Worked: master 786870e26f8

Short description of error
Production scenes going between 2.79 and 2.8 have a heavy performance hit. I 'think' it is because of particle systems, and have created a scene which shows this slowdown. There may be other slow downs also but this is the first step

Exact steps for others to reproduce the error

  1. Open attached file in blender 2.79, notice how fast it opens up
  2. press play, notice a constant 24fps
  3. open attached file in blender 2.8, notice how long it takes to open up
  4. press play, notice a constant 0.1-0.3 fps.

Details

Type
Bug

Event Timeline

William Reynish (billreynish) closed this task as Resolved.

If this is broken in 2.78 but works in 2.79 then it's been resolved.

Carlo Andreacchio (candreacchio) reopened this task as Open.EditedNov 29 2018, 10:35 PM

How is this resolved? there is a massive performance hit with Blender 2.8 making it unusable for production based scenes.

OH... i typed the main comment incorrectly for the step by step part... the rest was accurate

well, I tried it out. my poor little compu couldn't really handle well the opening part in 2.8, took ages.. and couldn't really do anything in blender. 2.79 was fast, as you said, opening and animation running.

then in 2.79, I removed the particle planes and tried again in 2.8, same thing, extremely slow. so, it's not just particles.
I started selecting the cubes, and turning from "wire" mode to "solid". one by one blender got better, and after it was done, it's fast again.

so, I'm not saying that particles don't have say in this, but I think it's more the viewport and all getting slow on drawing all those wires. it's a crazy cube you have there, you have to admit :)

.b

gtx 1070 ti , the same fps, so slow

Confirm here, 2.8 is unworkable on my laptop but 2.79 works fine. Looks like a good test file!

I have been working with the daily builds for some time now.

My blend file has multiple rigged objects with a shared particle system. Its a long animation - 3500 frames

2.8 (64bit) was working fine until the release on 27th November ending 436 when scrolling through the timeline became very slow (unusable). I am still using the build made on 24th Nov ending 0af, though doing a test on other builds I have stored, 25th November ending 3d8, seems OK as well.

Hope this helps

Windows 10 Pro - Intel i7 6800K - MSI 1080 X Gaming - 16 GB Ram

rndmnm added a subscriber: rndmnm.Dec 2 2018, 3:23 PM

2.8 (64bit) was working fine until the release on 27th November ending 436 when scrolling through the timeline became very slow (unusable). I am still using the build made on 24th Nov ending 0af, though doing a test on other builds I have stored, 25th November ending 3d8, seems OK as well.

I started having performance issues with moving vertices in edit mode with subdivision modifier enabled after that exact release.

Just updated to 756df74fca7393e4f4dc6e50330f88df437e00ae and can confirm it is still here.

Would someone be able to confirm this bug?

hmm, what does the image empty rendering bug has to do with this?

but, I can confirm, that the slowness of your file is still there.. and I think it will be for some time, doesn't feel like the simplest thing to do, hunt down the specific reason behind what makes this slow.. is it the rendering, or is it the new depsgraph, or.. well, we will see. hope devs get a look at it..

.b

Brecht Van Lommel (brecht) triaged this task as Confirmed, Medium priority.

The cubes in this file are very high poly, but due to hiding of flat edges the effective number of edges that gets drawn is low in wireframe mode. In 2.7 this happens once for each original mesh, on the CPU. The result is that very few edges need to be drawn. In 2.8 the flat edge detection happens on the GPU for every instance, which is slow.

There's cases where doing on the GPU faster, if you're for example animating a single high poly character it's likely faster. If you've got many static instances, in wireframe mode, with mostly flat edges, then it's a problem.

We could consider doing it on the CPU again. This test scene is a bit of a weird artificial case, but part of why wireframe drawing can be fast in heavy scenes is because many of the edges can be skipped for drawing. Not sure how practical this would be to fit in with the new wireframe drawing.

@Brecht Van Lommel (brecht) it could be solved by only drawing the faces that have at least one edge above the wireframe threshold.
Doing this means sorting the faces but I think we can get away with just separating them into 2 blocks based on an arbitrary value (maybe just a bit higher than the default wireframe threshold). This has the advantage that it's really easier and fast to sort and it will fix most of the issue reported here as long as the threshold is below the chosen threshold.

Going further we could sort the entire buffer and have a lookuptable with how much primitive to draw given a wireframe threshold. But this is way more complex and I wouldn't do it for animated/deformed objects.

This test scene is a bit of a weird artificial case, but part of why wireframe drawing can be fast in heavy scenes is because many of the edges can be skipped for drawing.

I was trying to replicate a similar slowdown from our production scenes. They have very high poly trees on particle systems / duplicollections. I am unsure whether this slowdown will fix the problem we have but it was the most similar case i could create.

All of these particle systems / duplicollections are static instances aswell.

If any more information is needed, or if a more similar production scene is required please let me know and I will try to organise something that represents it better.

Thanks

Carlo

After this fix... I have noticed that it has helped the test scene i made, but has not impacted the production scenes all that much.

I have attached a new test file to this comment... Apologies for the fuzzying over the particle object... but it should give you a more realworld example of the slowdown.

If there is anything else I can provide to help with the the viewport performance please let me know

Carlo

I have just tried this mornings buld for Win 64 - 5/12/18 ending a3a. As with Carlo above there is an improvement but as I scroll the time line it is still about half the speed of the release 24/11/18 ending 0af (which is still quite slow - there's a lot going on). I see there are some more fixes by Clement since this build and will try them tomorrow when they're available to me.

Thanks for all your work

Windows 10 Pro - Intel i7 6800K - MSI 1080 X Gaming - 16 GB Ram

I tried building from a46290aaa87 (November 25) and 31e3b7790affbde212bb2ccc6d5195a684010928 (November 24), but both have had really low FPS for me which contradicts the posts above. Blender 2.79b on the same scene I tested easily gets 10 FPS with 28K particles. If there is a way to extract only specific objects from a scene to a separate .blend, I can upload a test case as well.

Retesting after rB89db684d82f77d41f24335a7e90a9db320d1dfe0

Seems like this didn't have much of an impact (i guess because it only effects edit mode). we are still running a significant slowdown, which is even more exacerbated by selecting the particle system.

Has there been any developments on this?

So after profiling this with perf it gives me this flamegraph.


So there seems to be a huge overhead in the iterator.

Concerning the draw manager, drw_batch_cache_generate_requested is taking a really long time for what should be a no-op. I'll work on this first.

Is this still targeted for blender 2.8?