Maniphest T93639

Cycles uses only one thread with CPU
Closed, Archived
Actions

Assigned To
None
Authored By
Alex (Elfak)
Dec 4 2021, 11:11 AM
Tags
  • BF Blender
Subscribers
Alaska (Alaska)
Alex (Elfak)

Description

System Information
Operating system: macOS-10.15.7-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 575 OpenGL Engine ATI Technologies Inc. 4.1 ATI-3.10.22

Blender Version
Broken: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: rBf1cca3055776
Worked: (newest version of Blender that worked as expected)

Short description of error
Cycles uses only one thread, even if Threads mode set to Fixed. For 4 core processor Cycles uses 300% of processor (instead of 400% for 2.9x), but render time way longer than for the same scene in 2.9x. For example 15 min in 2.9x vs 7 hours (!!!) in 3.0

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]

Event Timeline

Alex (Elfak) created this task.Dec 4 2021, 11:11 AM
Alex (Elfak) added a comment.Dec 4 2021, 3:42 PM

I made a test scene. 4k render, 3480x2160 px. Sampling - 128. 4 threads, fixed. No denoise. 3 linked models + shadow catcher + HDR.
Initially tile size was 8 and result was awful. 8min 55sec for 2.9x and 32min 56sec for 3.0. Blender 3.0 used 360% to 380% of the processor (260-280% for places with HDR only).
If we change tile size to 128 render time will be way shorter – 8min 25sec. Better than in 2.9x with 8px tile. One thread for render, but Cycles was using up to 400% of 4-core processor (not constantly, but the same way 2.9x does it), and 340-350% for squares with HDR only.
For 256 tile size in 3.0 it was 7min 48sec – faster than with 128 tile size. And for 512 tiles it was 7min 35sec – the fastest result.
Is this how it works now? In 2.9x and later versions 8px tiles were useful to split data into smaller chunks for faster rendering on CPU. For example, render for this test scene took 10min 52sec with 256 tile size vs 8min 55sec with 8 tile size. And large tile sizes were useful for GPU rendering.
And it can't be only about memory usage how it says in Blender Manual, I have 64Gb on-board and without tiles it took 9min 8sec to render test scene, minute and a half longer than using tiles.

Alaska (Alaska) added a subscriber: Alaska (Alaska).Dec 4 2021, 9:28 PM

In Blender 3.0 Tiles should be left at large values like 2048. This is because Cycles now automatically figures out how to schedule work across the selected device(s).
However, large tiles isn't always ideal. If the scene contains some areas that are really quick to render (E.G. The HDRI) and ones that are really slow to render (E.G. Shadow catcher), then work isn't always scheduled efficiently and in those cases it is ideal to reduce the tile size to something smaller (512) but not too small.

Alaska (Alaska) closed this task as Archived.Dec 4 2021, 9:29 PM

I will close this report and see if I can update the manual to better explain things.

Alex (Elfak) added a comment.Dec 4 2021, 9:44 PM
In T93639#1264953, @Alaska (Alaska) wrote:

I will close this report and see if I can update the manual to better explain things.

Thank you a lot for explanation! Update in Blender Manual would be a great thing, because of such a steep turn in render math. I thought such things should be mentioned in the first place in Features or Release notes.