Regression: Eevee render takes 3x longer in 3.4 than 3.1.2 - shading related? #103903

New Issue

Sander de Regt · 2023-01-15T18:15:05+01:00

Sander de Regt commented

2023-01-15 18:15:05 +01:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.02

Blender Version
Broken: version: 3.4.1, branch: blender-v3.4-release, commit date: 2022-12-19 17:00, hash: 55485cb379
Broken 3.5
Broken 3.2
Worked: (3.1.2)

It started with 80859a6cb2
This caused the heavy regression which was then tracked in #98989 (Regression: Eevee bad performance when using procedural bump map.) and marked as resolved with a84c92fc73

Short description of error
I installed 3.4 and opened up a file that rendered in about 30-40 seconds per frame in 3.1.2 which now took 100-150 seconds per frame (this is in Eevee)
I turned off everything that I thought might make a difference geometry wise, but in the end giving the ground plane a different material made the difference.
I appended the ground plane with its material (I think it came from Blenderkit) into a clean scene and sure enough in 3.1.2 it renders 3-5 times faster than in 3.41

Exact steps for others to reproduce the error
In this case open up the file and press render. Notice the difference. Since I didn't create the material myself I didn't know how to troubleshoot it myself. I just noticed that the exact same file renders drastically different time wise between 3.1.2 and 3.41. Visually they're very similar.

Planetest.blend

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.02 **Blender Version** Broken: version: 3.4.1, branch: blender-v3.4-release, commit date: 2022-12-19 17:00, hash: `55485cb379` Broken 3.5 Broken 3.2 Worked: (3.1.2) It started with 80859a6cb2 This caused the heavy regression which was then tracked in #98989 (Regression: Eevee bad performance when using procedural bump map.) and marked as resolved with a84c92fc73 **Short description of error** I installed 3.4 and opened up a file that rendered in about 30-40 seconds per frame in 3.1.2 which now took 100-150 seconds per frame (this is in Eevee) I turned off everything that I thought might make a difference geometry wise, but in the end giving the ground plane a different material made the difference. I appended the ground plane with its material (I think it came from Blenderkit) into a clean scene and sure enough in 3.1.2 it renders 3-5 times faster than in 3.41 **Exact steps for others to reproduce the error** In this case open up the file and press render. Notice the difference. Since I didn't create the material myself I didn't know how to troubleshoot it myself. I just noticed that the exact same file renders drastically different time wise between 3.1.2 and 3.41. Visually they're very similar. [Planetest.blend](https://archive.blender.org/developer/F14151153/Planetest.blend)

Sander de Regt commented

2023-01-15 18:15:05 +01:00

Added subscriber: @SanderdeRegt

Iliya Katushenock commented

2023-01-15 21:24:10 +01:00

Added subscriber: @mod_moder

Iliya Katushenock commented

2023-01-15 21:24:10 +01:00

For me, the render took:
in 3.2: 2 minutes 21 seconds
in 3.5: 1 minute 40 seconds
3.4 did not check, but it seems, but it seems that it has some kind of complex specifics.

For me, the render took: in 3.2: 2 minutes 21 seconds in 3.5: 1 minute 40 seconds 3.4 did not check, but it seems, but it seems that it has some kind of complex specifics.

Sander de Regt commented

2023-01-15 22:38:49 +01:00

@mod_moder My apologies. I messed up the version number. I was using 3.1.2 instead of 3.2.1
I ran the file again. In 3.1.2 it was 14 seconds. In 3.4 it was 1 minute 19, in 3.5 it was 1 minute 18
Just to make sure I installed 3.2.0 and there I got 2 minutes and 9 seconds.
So my guess is that somewhere between 3.1.2 and 3.2.0 something has changed that makes this specific file render way way slower than it used to.
I'll update the description to make the version numbers correct again.

@mod_moder My apologies. I messed up the version number. I was using 3.1.2 instead of 3.2.1 I ran the file again. In 3.1.2 it was 14 seconds. In 3.4 it was 1 minute 19, in 3.5 it was 1 minute 18 Just to make sure I installed 3.2.0 and there I got 2 minutes and 9 seconds. So my guess is that somewhere between 3.1.2 and 3.2.0 something has changed that makes this specific file render way way slower than it used to. I'll update the description to make the version numbers correct again.

Sander de Regt changed title from ~~Render takes 3x longer in 3.4 than 3.21 - shading related?~~ to Render takes 3x longer in 3.4 than 3.1.2 - shading related?

2023-01-15 22:39:47 +01:00

Iliya Katushenock commented

2023-01-15 22:49:53 +01:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Iliya Katushenock commented

2023-01-15 22:49:53 +01:00

Really. I see a speed drop of almost 4 times.
But also, I see that the images have a difference. Perhaps there was some kind of effect that increased the render time.

Really. I see a speed drop of almost 4 times. But also, I see that the images have a difference. Perhaps there was some kind of effect that increased the render time. ![image.png](https://archive.blender.org/developer/F14151379/image.png)

Philipp Oeser commented

2023-01-16 10:50:21 +01:00

Added subscribers: @pragma37, @fclem, @lichtwerk

Philipp Oeser commented

2023-01-16 10:50:21 +01:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Philipp Oeser commented

2023-01-16 10:50:21 +01:00

Well this has a bit of history.
It started with 80859a6cb2

This caused the heavy regression which was then tracked in #98989 (Regression: Eevee bad performance when using procedural bump map.) and marked as resolved with a84c92fc73

Compared to 3.1, this is still multiple times slower, would you really consider #98989 resolved, @pragma37, @fclem?

Well this has a bit of history. It started with 80859a6cb2 This caused the heavy regression which was then tracked in #98989 (Regression: Eevee bad performance when using procedural bump map.) and marked as resolved with a84c92fc73 Compared to 3.1, this is still multiple times slower, would you really consider #98989 resolved, @pragma37, @fclem?

Philipp Oeser changed title from ~~Render takes 3x longer in 3.4 than 3.1.2 - shading related?~~ to Regression: Eevee render takes 3x longer in 3.4 than 3.1.2 - shading related?

2023-01-16 10:51:36 +01:00

Miguel Pozo commented

2023-01-16 12:38:24 +01:00

The #98989 issue was related to chaining multiple bump nodes and it was, indeed, solved.

Here the performance is bad even with a single bump node so it must be a different problem.

The #98989 issue was related to chaining multiple bump nodes and it was, indeed, solved. Here the performance is bad even with a single bump node so it must be a different problem.

Sun Kim commented

2023-01-17 09:43:29 +01:00

Added subscriber: @persun

Evan Wilson commented

2023-01-17 11:43:56 +01:00

Added subscriber: @EAW

blendcmds commented

2023-01-18 16:20:43 +01:00

Added subscriber: @Ikyuv

Nicolas Ong commented

2023-01-22 14:39:50 +01:00

Added subscriber: @kholo

Nicolas Ong commented

2023-01-22 14:39:50 +01:00

We also referred to it in #98865 which was closed when marked as duplicate of #99163 (which in turn was also closed as duplicate of #98865).

Alex commented

2023-01-25 01:36:26 +01:00

Added subscriber: @Alex-Gorbunov

Miguel Pozo commented

2023-01-31 20:48:51 +01:00

I've been taking a look at this.
I've also simplified a bit the file so it only has one bump node.
#103903-cleanup.blend

This is the generated code for the material in Blender 3.1 and 3.4:
#103903-3-1.glsl #103903-3-4.glsl.

I don't see anything obviously wrong.

Something weird I've noticed is that if only the base color or the normal input are connected to the BSDF the performance is roughly on par on both Blender versions.
My only guess for now is that, maybe, since all the node function calls are part of the main function in 3.1, but the bump tree is a separate function in 3.4, the driver does a worse job at optimizing it.

Has anybody tested this on AMD?

I've been taking a look at this. I've also simplified a bit the file so it only has one bump node. [#103903-cleanup.blend](https://archive.blender.org/developer/F14223624/T103903-cleanup.blend) This is the generated code for the material in Blender 3.1 and 3.4: [#103903-3-1.glsl](https://archive.blender.org/developer/F14223626/T103903-3-1.glsl) [#103903-3-4.glsl](https://archive.blender.org/developer/F14223627/T103903-3-4.glsl). I don't see anything obviously wrong. Something weird I've noticed is that if only the `base color` or the `normal input` are connected to the BSDF the performance is roughly on par on both Blender versions. My only guess for now is that, maybe, since all the node function calls are part of the main function in 3.1, but the bump tree is a separate function in 3.4, the driver does a worse job at optimizing it. Has anybody tested this on AMD?

Iliya Katushenock commented

2023-01-31 20:55:42 +01:00

You meen AMD cpu render?

Miguel Pozo commented

2023-01-31 21:03:48 +01:00

On an AMD Radeon GPU.
The CPU shouldn't matter in this case.

On an AMD Radeon GPU. The CPU shouldn't matter in this case.

Miguel Pozo commented

2023-02-03 16:39:47 +01:00

I took another look at this one, and I think I found the main culprit.

For computing bump derivatives you need to compute everything before the bump node 3 times (at X offset, at Y offset, and at no offset).
In 3.1, the "no offset" computation is shared with regular (ie. not bump) nodes.
But after 80859a6cb2, it's computed once for regular nodes and 3 times for the bump.

However, the performance hit can be misleading.
While in some cases, we see a 33% performance decrease (unintended, but it makes sense), it can get much worse.

I've observed this kind of huge performance drop even without bump nodes, adding noise nodes decreases performance linearly until reaching a certain threshold, then performance can get several times slower by adding a single extra node.
I guess this is either the compiler throwing the towel, or maybe the shader processors running out of hardware resources (registers, cache).

I think we might have to revert to the previous way, where all nodes are "inlined" into the main function.
We could detect points where a separate function has been generated and compute the "no offset" result only once, but that wouldn't solve all cases.

I took another look at this one, and I think I found the main culprit. For computing bump derivatives you need to compute everything before the bump node 3 times (at X offset, at Y offset, and at no offset). In 3.1, the "no offset" computation is shared with regular (ie. not bump) nodes. But after 80859a6cb2, it's computed once for regular nodes and 3 times for the bump. However, the performance hit can be misleading. While in some cases, we see a 33% performance decrease (unintended, but it makes sense), it can get much worse. I've observed this kind of huge performance drop even without bump nodes, adding noise nodes decreases performance linearly until reaching a certain threshold, then performance can get several times slower by adding a single extra node. I guess this is either the compiler throwing the towel, or maybe the shader processors running out of hardware resources (registers, cache). I think we might have to revert to the previous way, where all nodes are "inlined" into the main function. We could detect points where a separate function has been generated and compute the "no offset" result only once, but that wouldn't solve all cases.

Miguel Pozo commented

2023-02-03 18:13:56 +01:00

Yep, that was it:
3.1

3.4

3.5 + fix

Yep, that was it: 3.1 ![imagen.png](https://archive.blender.org/developer/F14237436/imagen.png) 3.4 ![imagen.png](https://archive.blender.org/developer/F14237440/imagen.png) 3.5 + fix ![imagen.png](https://archive.blender.org/developer/F14237447/imagen.png)

Paul Larson commented

2023-02-07 03:59:34 +01:00

Added subscriber: @GeorgiaPacific

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: Eevee render takes 3x longer in 3.4 than 3.1.2 - shading related? #103903