Extreme FPS loss (24x) between 2.79 and 2.8 with particle systems #58188

New Issue

Carlo Andreacchio · 2018-11-29T21:52:09+01:00

Carlo Andreacchio commented

2018-11-29 21:52:09 +01:00

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

Blender Version
Broken: blender2.8 23284e4dde
Worked: master 786870e26f

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

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

test (1).blend

**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. [test (1).blend](https://archive.blender.org/developer/F5759669/test__1_.blend)

Carlo Andreacchio commented

2018-11-29 21:52:09 +01:00

Added subscriber: @candreacchio

William Reynish commented

2018-11-29 22:32:51 +01:00

Added subscriber: @WilliamReynish

William Reynish commented

2018-11-29 22:32:51 +01:00

Changed status from 'Open' to: 'Resolved'

William Reynish closed this issue

2018-11-29 22:32:51 +01:00

William Reynish self-assigned this 2018-11-29 22:32:51 +01:00

William Reynish commented

2018-11-29 22:32:52 +01:00

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

Carlo Andreacchio commented

2018-11-29 22:35:49 +01:00

Changed status from 'Resolved' to: 'Open'

Carlo Andreacchio reopened this issue

2018-11-29 22:35:49 +01:00

Carlo Andreacchio commented

2018-11-29 22:35:49 +01:00

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

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

bastian salmela commented

2018-11-30 13:27:15 +01:00

Added subscriber: @bastiansalmela

bastian salmela commented

2018-11-30 13:27:15 +01:00

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

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

Sergey commented

2018-11-30 13:36:43 +01:00

Added subscriber: @SergeyIvanov

Sergey commented

2018-11-30 13:36:43 +01:00

gtx 1070 ti , the same fps, so slow

Sergey commented

2018-11-30 13:36:57 +01:00

Removed subscriber: @SergeyIvanov

Sergey commented

2018-11-30 13:37:01 +01:00

Added subscriber: @SergeyIvanov

Charlie Jolly commented

2018-11-30 13:58:31 +01:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2018-11-30 13:58:31 +01:00

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

Laurence Weedy commented

2018-12-01 11:42:49 +01:00

Added subscriber: @LaurenceWeedy

Laurence Weedy commented

2018-12-01 11:42:49 +01:00

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

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

William Reynish removed their assignment 2018-12-02 14:54:52 +01:00

rdnmnm commented

2018-12-02 15:23:15 +01:00

Added subscriber: @rdnmnm

rdnmnm commented

2018-12-02 15:23:15 +01:00

In #58188#564035, @LaurenceWeedy wrote:

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.

> In #58188#564035, @LaurenceWeedy wrote: > 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.

Carlo Andreacchio commented

2018-12-02 22:02:17 +01:00

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

Would someone be able to confirm this bug?

Just updated to 756df74fca7393e4f4dc6e50330f88df437e00ae and can confirm it is still here. Would someone be able to confirm this bug?

bastian salmela commented

2018-12-02 22:15:48 +01:00

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

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 commented

2018-12-02 22:45:53 +01:00

Added subscriber: @brecht

Clément Foucault was assigned by Brecht Van Lommel

2018-12-02 22:45:53 +01:00

Brecht Van Lommel commented

2018-12-02 22:45:53 +01:00

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.

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.

Sergey commented

2018-12-02 22:51:08 +01:00

Removed subscriber: @SergeyIvanov

Clément Foucault commented

2018-12-02 23:52:08 +01:00

@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.

@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.

Carlo Andreacchio commented

2018-12-03 01:49:32 +01:00

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

> 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

Carlo Andreacchio commented

2018-12-04 22:45:12 +01:00

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.

slowdown.blend

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

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. [slowdown.blend](https://archive.blender.org/developer/F5821296/slowdown.blend) If there is anything else I can provide to help with the the viewport performance please let me know Carlo

Laurence Weedy commented

2018-12-05 11:41:54 +01:00

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 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

Robi Pires commented

2018-12-19 15:18:08 +01:00

Added subscriber: @RobiTheReporter

Robi Pires commented

2018-12-19 15:18:08 +01:00

I tried building from a46290aaa8 (November 25) and 31e3b7790a (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.

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.

Carlo Andreacchio commented

2019-03-12 03:43:25 +01:00

Retesting after 89db684d82

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?

Retesting after 89db684d82 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?

Clément Foucault commented

2019-04-05 21:48:49 +02:00

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.

So after profiling this with `perf` it gives me this flamegraph. ![Capture d’écran du 2019-04-05 21-36-24.png](https://archive.blender.org/developer/F6914123/Capture_d_écran_du_2019-04-05_21-36-24.png) ![perf-kernel.svg](https://archive.blender.org/developer/F6914122/perf-kernel.svg) 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.

Simon G. commented

2019-04-05 22:06:58 +02:00

Added subscriber: @intrigus-3

Robin commented

2019-04-05 23:35:11 +02:00

Added subscriber: @Astiero

MartinR commented

2019-04-27 20:23:13 +02:00

Added subscriber: @mares-1

Carlo Andreacchio commented

2019-07-10 10:17:54 +02:00

Is this still targeted for blender 2.8?

Valou leloup commented

2019-08-16 23:46:37 +02:00

Added subscriber: @Valouptitloup

Carlo Andreacchio commented

2019-09-03 02:17:16 +02:00

Blender 2.8 has come and went. Is this a target for 2.81?

Clément Foucault commented

2019-09-03 02:24:33 +02:00

This case should be improved by D4997 which is a target for 2.81.

This case should be improved by [D4997](https://archive.blender.org/developer/D4997) which is a target for 2.81.

Clément Foucault commented

2019-09-13 18:30:11 +02:00

Changed status from 'Open' to: 'Resolved'

Clément Foucault closed this issue

2019-09-13 18:30:11 +02:00

Clément Foucault commented

2019-09-13 18:30:11 +02:00

With D4997 applied, the slowdown.blend file is ~32fps which is about the same performance as 2.79 [which is around 30fps (hard to tell because the fps is really not stable)].

So I will mark this as resolved.

With [D4997](https://archive.blender.org/developer/D4997) applied, the slowdown.blend file is ~32fps which is about the same performance as 2.79 [which is around 30fps (hard to tell because the fps is really not stable)]. So I will mark this as resolved.

Carlo Andreacchio commented

2019-09-16 00:43:29 +02:00

Changed status from 'Resolved' to: 'Open'

Carlo Andreacchio reopened this issue

2019-09-16 00:43:29 +02:00

Carlo Andreacchio commented

2019-09-16 00:43:29 +02:00

Just marking this as open as D4997 has been reverted.

Just marking this as open as [D4997](https://archive.blender.org/developer/D4997) has been reverted.

Carlo Andreacchio commented

2019-09-21 01:45:07 +02:00

Changed status from 'Open' to: 'Resolved'