Cycles: CPU+GPU renders slower than GPU only?

I’ve always under the impression that using both CPU and GPU to render is faster the GPU alone. To my surprise it isn’t, maybe my setting is incorrect?

GPU only: 43.90 seconds
GPU+CPU: 57.49 seconds

Not exactly small difference to be ignored.

Windows 10 Pro 64
48GB RAM
Xeon 6 cores 3.33Ghz
GTX 1080 Ti
GTX 1070
Blender 2.83

If your cpu is much slower than gpu it will hang the render. Basically integration of hybrid rendering in cycles works like that, each bucket gets one core and gpu being one of them. If there is one super slow core then the gpu(s) alone would buzz through that before it even starts rendering. Effectively making your cpu + gpu slower than gpu(s) alone.

2 Likes

CPU’s work best at lower tiles 16x16 or 32x32.

Also depending on the scene and low sample size (you ahve 128) the CPU will hold back the overall process.

Try same scene with 500 samples and lower tile setting and see if that works as expected.

1 Like

Hi.
What is the exact model of that Xeon CPU?
What is the CPU only render time?

Beyond that CPU+GPU use one CPU thread per GPU (you have two less CPU threads available for rendering), it sounds strange that you have worse times using small tile sizes.

CPU only render is “too damn long” lol, I gave up after 7 minutes.

I guess that’s what @staughost has said.
You have an old slow CPU vs two powerful GPUs. You don’t expect magic there.
The best advantage with CPU+GPU render is when you have a CPU and a GPU with similar render times when they work alone.

1 Like

I’ve rendered it with smaller tiles 32x32, 16x16 and 8x8. Results are about the same in terms of the difference between CPU render & CPU+GPU render. I didn’t use 500 samples because I use denoise, higher sample is not needed in my case.

1 Like

That’s good to know, thanks for the inputs.

The GPU rendering actually needs some CPU power to work right. If you CPU is way slower then the GPU there can be a stall between CPU GPU communication when CPU is rendering. This stall can lead to the GPU not being fed fast enough to render at 100% speed. This causes the GPUs to slow down making the render time longer than GPU only. At least this is what Cycles seems to do. Octane seems to be very all on the GPU rendering not taxing the CPU at all when rendering.

When using a fast GPU(s) I rarely find a use case where the CPU+GPU hybrid mode is faster. GPUs love large tiles and have super fast memory. CPUs do better with small tile sizes. System RAM is much slower than on card VRAM, so Cycles is trying to manage memory across this heterogeneous group and buses but it ends up being quite unoptimized. Often you’ll have GPUs done with their tiles and idle while the GPU is finishing its work. If you could perfectly optimize, you would theoretically get faster rendering, but because of significant wait states and additional overhead, it’s rarely worth it. In most cases you’re best just using GPU rendering (Nvidia RTX cards with Optix is currently the fastest way to go in general) unless you don’t have enough VRAM and have to render on the CPU.

I have a Threadripper 1950x and it renders faster than my 980ti (I will replace it with something eventually), which is actually a surprise. This is since the release of 2.83 and adaptive sampling; 2.82 the GPU just had the edge.
I’m seeing well over 25% advantage for CPU at least in normal use and with testing via the various MikePan Scenes - with the exception of the classroom
32 or 64 tile size seems to be best for CPU - depends on scene.
for GPU, 512 tile size is no longer the best for me, when using GPU only I mean; It seems to be 256 or even 128 in the tests I’ve done for GPU.

It might be that computers vary, and that scenes vary between computers, so check imo.

CPU 1950x
BMW 1:09.75
Classroom 5:28.33
Fishy Cat 2:32.07
Koro 2:08.20
Barcelone 5:45.21

GPU 980ti
BMW 1:45.67
Classroom 4:08.92
Fishy Cat 4: 36.89
Koro 5:42.79
Barcelone 9:58.10

CPU + GPU render fast than GPU, when both fast. If one of this faster than other, then will create bottleneck and render will be slow.

And tile sizes too important. Example, for NVIDIA 32x32, for AMD 64x64 tile sizes are good for hybrid render.

I realize that this suggestion is better sent to the developers but it might be a relevant perspective for here too.

Currently each GPU is assigned one tile and each CPU thread is assigned one tile. Very few people will have a CPU so powerful that one thread is equal to an entire GPU if such a CPU even exists.

I propose for GPU + CPU that the entire CPU should be assigned to one tile. Perhaps that tile would be subdivided into one piece per core or thread. This allows a CPU tile to finish faster and create less of a bottle neck. The CPU would probably finish some tiles during the render giving a benefit to GPU + CPU and then lag less on the last tile.