Page MenuHome

Eevee: Procedural material very slow
Needs Developer to Reproduce, NormalPublicKNOWN ISSUE

Description

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.85

Blender Version
Broken: version: 2.83.3 / 2.90.0 Beta, branch: master, commit date: 2020-08-03 22:28, hash: rB9de5adc6a1a9
Worked: -

Short description of error
For some reason in eevee my procedural asphalt material works pretty slow.
I don't see any problems with Cycle and the same scene works as fine on a Radeon RX 480, so it seens to be a bug.

Exact steps for others to reproduce the error

  • Open attached file
  • go to material view
  • move around the plane (it's getting worse if you get closer)

Event Timeline

AiSatan (AiSatan) updated the task description. (Show Details)

When I switch to shader tab, viewport is much more responsive. I don't see any reason for lagging, but not sure if this is bug

I don't see any difference in shader tab, if you zoom camera to the object, in the same distance lags stay the same for me.

I made some tests, so it's laggy with:

Noise texture, 4D, Details: 16 (starts from 7+)
or
Voronoi texture, 4D, Smooth F1

One of them connected to bump -> Viewer node - >Material output.

I guess it's 4D performance(maybe it's ok)? but why only on Eevee?

When I change all textures from 4d to 3d it's much better.

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.67

Yes, if you "play animation", by this I mean just press "space" even if no animation in this project, it'll show fps on the corner and it's enouth to see the difference, so, with 4D - 3 fps, with 3D - 8 fps, with 3D and details: 5 - 15 fps. So, I guess this should be as bad with bumb node, 'cause if I connect the same noises to the base color (without bump) I get 10 fps, with bump 3 fps

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Needs Information from User.Aug 5 2020, 5:15 PM

At first this doesn't look like a bug. Since the material is very complex and therefore slow on any GPU.
But the video however shows a very simple node setup and it is to be expected that performing it on a GeForce RTX 2070 is better than that.
Can you check if the problem is also seen with the material in this file?

Here the result with a Radeon RX 480 (4.5.13596 Core Profile Context 20.10.19.02 27.20.1019.2002)

sure,

it's just doesn't feel right, this is why I'm here, it's make work with procedural textures unpleasant, I have to use cycle now, cause it's not make unresponsive/laggy ui

this material seems fine, even in close it's get 15 fps min.
but "zommed-in view" it's not a problem for me, usually I don't want to zoom-in so close, if it's not laggy on the distance from that I can see the result of my node changes on this plane

I tried (not in the video) to change to 16 details and get 9 fps min.

Germano Cavalcante (mano-wii) changed the task status from Needs Information from User to Needs Developer to Reproduce.Aug 5 2020, 5:55 PM
Germano Cavalcante (mano-wii) updated the task description. (Show Details)

I am not able to reproduce the slow down on my system, but that is AMD based (I get 160 FPS on a debug build)

.

Also try blender 2.91 Alpha we refactored the EEVEE materials in that version.
Looking at the generated code it isn't clear what slows down the GLSL at max it does 3 * 16 inner loops (3 calls to fractal_noise from node_noise_texture_4d, fractal_noise clamps to max 16 loops)..

@AiSatan (AiSatan) when you compare to Cycles, how have you configured you GPU? Have you enabled denoising/optix if that is the case it might not be a fair comparison.
Doing calculations in higher dimensions will add a slow down factor. Bump will make it more visible as bump will call the rest of the shader tree multiple times. The material is also slow in cycles-CPU (bump + 4d noise is just very time consuming). Denoising and Optix might be able to hide that from you as it utilizes more of your hardware capabilities and post filters that would otherwise be sleeping.

Looking at you images, it seems like you are running on 4K? Note that mine figures are on 2K. So on 4k the 160fps might be 40fps.

I expect that the issue might be that the NVIDIA driver creates not performing GLSL output. Can you check if other drivers have the same limitation? I will check here in the studio if anyone is able to reproduce it.

Just tested the scene on my machine:

NVIDIA Quadro RTX 6000 on Ubuntu, Driver Version: 440.100

I'm getting 160+ fps on a FHD monitor
500+ fps when setting the dimension to 3D

Hi,

I tried the latest alpha, the video below has been recorded with blender-2.91.0-b522e834ec30-windows64 and I installed latest studio drivers 451.77 (I attached my sys-info from blender menu just in case)

I don't really compare-compare them, cycle just not create any input lag issues at any point of the render, and this just feels wrong to me, so I can't tell, should it be like this or it is an issue.
It's just really easier to use cycle even if you need to wait to see your node changes result, it's still better than mouse lagging, so you can't connect nodes at all

I use 2k screen, but I tried and both my FHD screens behavior the same way too.

I attached two videos, one of them just eevee (and I tried to change size of the viewport and at ~128x128 I get usable fps), not sure if it's help
And the second one with cycle and eevee not like compare but just showcase of input lag.

Also, for some reason it max at my refresh rate (in all monitors, 144/60), I disable all g-sync and reset nvidia control panel, but it's still does, but I don't need high fps anyway, it's just a note.

Clément Foucault (fclem) changed the subtype of this task from "Report" to "Known Issue".Wed, Sep 16, 7:21 PM
Clément Foucault (fclem) moved this task from Backlog to Known Issues on the EEVEE & Viewport board.

You are comparing apples and oranges. The noise texture node is maybe the node that generate the most instructions and the Bump node is just multiplying that by 3.

The slowdown is expected and I can reproduce it on my system. The issue is that this is entirely dependent on how the drivers optimize the shader and this is out of our control.
I really don't know what we can do except to trying to please some blackbox shader compilers by trial and error. We already had drivers not wanting to even compile such a shader.

Cycles is different because it runs async and does not prevent UI from refreshing and has a whole different architecture. For various reasons we cannot do this for EEVEE.

To me it's not something I will prioritize but anyone is free to tackle this.