Slower Cycles GPU in Blender 2.8 Beta

Archive User Feedback
1

1317×636 115 KB

I have a simple scene for testing. For some reason Cycles GPU in Blender 2.8 performs much worse. Any idea why? Mostly the first reviews said Cycles should performs a little better.

Render times

Blender 2.79: 4:30
Blender 2.80 Beta: 5:28
OS: Windows 10 1803
GPU: Geforce GTX 1060 6GB

Scene download: https://ufile.io/dc829

Original post: Slower Cycles GPU in Blender 2.8 Beta - Blender Development Discussion - Blender Artists Community

2

You can investigate more closely where the difference is:

  • Try 2.79b vs. 2.79 latest daily build vs. 2.80.
  • Try without progressive refine.
  • Try without experimental features.
  • Compare CPU render times.
  • Verify if the noise levels are similar.
  • Try hiding everything in the UI except the render itself.
3

The latest 2.79 version is even worse with above 10 minutes render time. Without progressive refine there is no problem. Noise levels are the same in all situations and every test made with supported features turned on.

4

Trying it here, Windows 10 current, Nvidia 1060, GPU-only, some numbers:

2.79a: 4:45
2.80 beta (current, self-built): 5:59.

Both showed virtually identical CPU and GPU utilization. I messed around with a bunch of things without finding any smoking gun that would explain it being so different.

I next tried fishy_cat (30 samples progressive GPU only, post-processing disabled) and got 0:34 in 2.79 and 1:34 in 2.80 which also looks pretty bad.

For these scenes progressive render appears to be substantially slower in current Cycles than 2.79a, and maybe that’s worth investigating more.

I know progressive render can be a nice way to preview a scene, but you can also have this (below) in 30 seconds with tiled rendering and denoise, or even real-time with Eevee depending on what you’re doing.

image
image956×534 67.2 KB

5

On a related note, Progressive GPU+CPU rendering seems broken as it’s half the speed of GPU only.

Maybe this is an argument for making the rendering choice of GPU+CPU explicit in the Device selection in Render Properties along with GPU only and CPU only? If there are going to be cases where you want one vs. the other it would be nice to be able to set this at the .blend level rather than having to go in and out of Preferences all the time.

6

Can we expect to fix this in the near future?

7

We’ll try to fix it for the release, it’s not very high priority for me. Progressive refine never had great performance.

1 Like
8

Thank you. But no offense of course, let me disagree about the importance thing.

Here is why:

  • Based on my benchmarks with progressive refine Cycles (2.79b) is only slightly slower than without it.
  • Cycles (2.79b) is faster than V-Ray Next GPU (At least the first release, haven’t been watching since the new update. I think it is faster even now.)
  • For look dev progressive refine is matter the most and Cycles done well so far.
9

Back in the BA thread, myclay pointed out that setting the tile size >= the render size eliminates a lot of the performance issues. In doing some more testing with this, one thing it seems to do is is to limit rendering to the GPU only even when you have a CPU also selected under CUDA devices, thus solving the issue where slow CPU threads cause problems.

Using a single tile this way solves the problem I was having with the fishy_cat scene, and 2.80 is slightly faster than 2.79a with these settings. Trying the same settings in the classroom benchmark scene, 2.80 is also taster than 2.79a. It does not seem to make the sample scene in this post run faster, but so far I have not found a real-world example that is slower in 2.80 once the tile size / CPU+GPU issue is taken into account.

So now I’m not sure that this problem report reflects a general problem with Progressive refinement (apart from poor handling of GPU+CPU and a need to consider tile size) other than for this specific scene.

10

I figured out what was causing the slowdown in rendered preview. After turning off Reflective Caustics every currently available Blender versions render time will be the same.

Versions affected:

  • 2.79.7
  • 2.80 Beta

In this case is it expected to fix this in the very near future? Thanks.

1 Like
11

Blender 2.79 much much much more better scenes Cycles render and quick than in Blender 2.8 Cycles render engine i dont know what its improved in Blender 2.8 as Cycles Render , for Eevee i cant use as serious production render engine as product or industrial design render engine because Eevee not have reflaction for diamonds Cycles is best ! but in Blender 2.7 only .

12

For Blender Developers ! Devs ! dont try to make new features before you still not fixed the Main Blender engines like Cycles Render in Blender 2.8 and else …

13

This is exactly what they are doing since we entered beta :slight_smile:

Right now Cycles may be a bit slower than 2.79 because there are several things that lack optimization, I’m not sure about the status of Open SubDiv and displacement, but this was causing major slowdowns and memory drain in my scenes when I compared it against 2.79, and there are much more things that are being worked out day after day.

No new features are being added, we are in beta, and right now it’s our turn (users) to post bug reports or problem findings (like this one) and their turn to make Cycles in Blende 2.80 stable and as fast, if not more, as it is in Blender 2.79 daily builds (because right now is already faster than 2.79b release).

So don’t worry :slight_smile: They are working on it!

Cheers.

2 Likes
14

Thank you Juan .
Yes for sure as Start up Blender 2.8 Beta generally more better than 2.79 (modeling and etc…) but for sure when be Cycles also quick render and better quality resolution than 2.79 … even Eevee hope so have same quality render or similar as Cycles like for diamonds , gems reflections and else … for future soon .
At last Cycles Render is a like other profession render engines high quality .
Thank you Juan for your support and thanks other Devs for hard working .
Regards.
Pierre
Cheers .

1 Like