Slower Cycles GPU in Blender 2.8 Beta


#1

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: https://blenderartists.org/t/slower-cycles-gpu-in-blender-2-8-beta/1138261


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


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


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