Cycles resets manually set affinity #60145

New Issue

Kalvis · 2019-01-04T09:19:38+01:00

Kalvis commented

2019-01-04 09:19:38 +01:00

System Information
Operating system: Windows 10 Pro
Processor: Intel i7-7800X 3,5GHz
Graphics card: Quadro 4000

Blender Version
Broken: blender-2.80-c97c76c01c1d-win64
Worked: 2.79 (it also worked in older 2.8 beta releases, but i cannot find them to test)

Short description of error
Cycles rendering changes manually set processor affinity

Exact steps for others to reproduce the error
Turn on blender. Manually set processor affinity to use only some of the processors. Press render. Wait until it start rendering tiles. After start of tile rendering affinity is reset to use all processors.
Eevee and Workbench do not have this issue. Only Cycles.

**System Information** Operating system: Windows 10 Pro Processor: Intel i7-7800X 3,5GHz Graphics card: Quadro 4000 **Blender Version** Broken: blender-2.80-c97c76c01c1d-win64 Worked: 2.79 (it also worked in older 2.8 beta releases, but i cannot find them to test) **Short description of error** Cycles rendering changes manually set processor affinity **Exact steps for others to reproduce the error** Turn on blender. Manually set processor affinity to use only some of the processors. Press render. Wait until it start rendering tiles. After start of tile rendering affinity is reset to use all processors. Eevee and Workbench do not have this issue. Only Cycles.

Kalvis commented

2019-01-04 09:19:38 +01:00

Added subscriber: @likimokalvis

Philipp Oeser commented

2019-01-04 09:49:09 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-01-04 09:49:09 +01:00

Cannot reproduce here.

Are you using the Threads setting in the Performance tab?
(that is working fine here)

If this is using some kind of OS setting, I'm afraid there is not much we can do here.

Marking as incomplete until we have more information

Cannot reproduce here. Are you using the `Threads` setting in the Performance tab? (that is working fine here) ![#60145.png](https://archive.blender.org/developer/F6170035/T60145.png) If this is using some kind of OS setting, I'm afraid there is not much we can do here. Marking as incomplete until we have more information

Brecht Van Lommel commented

2019-01-04 11:23:13 +01:00

Added subscribers: @Sergey, @brecht

Sergey Sharybin was assigned by Brecht Van Lommel

2019-01-04 11:23:13 +01:00

Brecht Van Lommel commented

2019-01-04 11:23:13 +01:00

We do change the affinity, it's important for Cycles to use all available CPU cores efficiently. Eevee and workbench are not CPU renderers.

@Sergey, maybe there is a way to detect if the user made changes manually and then do nothing. If not I'm not sure we'd consider this a bug.

We do change the affinity, it's important for Cycles to use all available CPU cores efficiently. Eevee and workbench are not CPU renderers. @Sergey, maybe there is a way to detect if the user made changes manually and then do nothing. If not I'm not sure we'd consider this a bug.

Sergey Sharybin commented

2019-01-04 12:14:26 +01:00

Our current goal is to give best performance for artist on a machine with lots of cores (> 64) and on CPUs with non-trivial topology (i.e. Threadripper2 and certain configurations of EPYC computers). Currently this implies following aspects:

Making sure main Blender thread and Cycles synchronization thread are scheduled to a NUMA node with direct memory access.
When Cycles is configured to use all threads, we need to make sure render threads are using all NUMA nodes from all CPU groups (this is the only way we can scale to over 64 threads on Windows, i.e.).
When Cycles is configured to use few threads, we need to make sure those have direct memory access as well (there is still possible tweak logic, to allow occupying two fast NUMA nodes on Threadripper2 processors).

@likimokalvis, what is your usecase where you are manually controlling affinity?

@brecht, you can query current thread affinity, but you can not distinguish between it being set by an OS or tweaked by a user. This isn't really a bug, but there might be something we can do to support specific usecases better (but maybe we'd need to introduce some command line argument for that =/).

Our current goal is to give best performance for artist on a machine with lots of cores (> 64) and on CPUs with non-trivial topology (i.e. Threadripper2 and certain configurations of EPYC computers). Currently this implies following aspects: - Making sure main Blender thread and Cycles synchronization thread are scheduled to a NUMA node with direct memory access. - When Cycles is configured to use all threads, we need to make sure render threads are using all NUMA nodes from all CPU groups (this is the only way we can scale to over 64 threads on Windows, i.e.). - When Cycles is configured to use few threads, we need to make sure those have direct memory access as well (there is still possible tweak logic, to allow occupying two fast NUMA nodes on Threadripper2 processors). @likimokalvis, what is your usecase where you are manually controlling affinity? @brecht, you can query current thread affinity, but you can not distinguish between it being set by an OS or tweaked by a user. This isn't really a bug, but there might be something we can do to support specific usecases better (but maybe we'd need to introduce some command line argument for that =/).

Ludvik Koutny commented

2019-01-04 22:16:02 +01:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2019-01-04 22:16:02 +01:00

Ability to manually control affinity is crucial if one needs to use the PC for other tasks while also waiting for some long render to finish. In some cases, setting CPU priority to low is not enough to free up enough resources, fast enough so that other software does not lag.

Defaulting to no affinity and full CPU usage is of course fine, but it should happen only once, at the Blender launch. It should not be reset on every single render. That's just disrespectful, as it ignores user's conscious choice.

Simply keep doing what you are doing, but do not set it on each render, just once when Blender session starts. Only those who go all the way to change the affinity manually in the task manager could ever encounter performance issues then.

Ability to manually control affinity is crucial if one needs to use the PC for other tasks while also waiting for some long render to finish. In some cases, setting CPU priority to low is not enough to free up enough resources, fast enough so that other software does not lag. Defaulting to no affinity and full CPU usage is of course fine, but it should happen only once, at the Blender launch. It should not be reset on every single render. That's just disrespectful, as it ignores user's conscious choice. Simply keep doing what you are doing, but do not set it on each render, just once when Blender session starts. Only those who go all the way to change the affinity manually in the task manager could ever encounter performance issues then.

Ray molenkamp commented

2019-01-04 22:26:04 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2019-01-04 22:26:04 +01:00

why not control it with the options in the performance section of blender? set it to use a single thread and off you go, leaving it on auto (which in your case is probably 12) and limiting affinity manually to a single core will lead to excessive context switches ruining performance.

blender-admin commented

2019-01-11 17:55:36 +01:00

This issue was referenced by blender/cycles@43cb63c531

This issue was referenced by blender/cycles@43cb63c531eeed3255cf836abaa8d978b6ef932e

blender-admin commented

2019-01-11 17:55:36 +01:00

This issue was referenced by 48506a3431

This issue was referenced by 48506a3431fb5b4396f7cf2d9c6a8a208b3c0df5

Sergey Sharybin commented

2019-01-11 18:09:07 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2019-01-11 18:09:07 +01:00

Jason commented

2019-01-22 10:41:41 +01:00

Added subscriber: @JustAPerson

Jason commented

2019-01-22 10:41:42 +01:00

Just a follow up. I contribute my Threadripper to a community renderfarm, but don't actually use Blender/Cycles myself. I found this issue on google because I noticed weird things on htop.

It appears some projects are submitted to the render farm set to use a specific number of threads (presumably under the Cycles performance tab). If this number is small, then it was triggering all threads to set their affinity to 0-15. Blender is launched with -t 64 so there were 64 threads all limited to cores 0-15. It seems the command line argument didn't interact ideally.

I see there's been a commit (and we run an outdated nightly so I will workaround this) but will the -t command line argument and the cycles settings in the .blend file work together correctly in the current version?

Just a follow up. I contribute my Threadripper to a community renderfarm, but don't actually use Blender/Cycles myself. I found this issue on google because I noticed weird things on htop. It appears some projects are submitted to the render farm set to use a specific number of threads (presumably under the Cycles performance tab). If this number is small, then it was triggering all threads to set their affinity to 0-15. Blender is launched with `-t 64` so there were 64 threads all limited to cores 0-15. It seems the command line argument didn't interact ideally. I see there's been a commit (and we run an outdated nightly so I will workaround this) but will the `-t` command line argument and the cycles settings in the .blend file work together correctly in the current version?

Sergey Sharybin commented

2019-01-22 11:54:44 +01:00

The only solution is to pass a python script (as a file or a python expression) to override those settings.

But such question is outside of the scope of the bug tracker.

The only solution is to pass a python script (as a file or a python expression) to override those settings. But such question is outside of the scope of the bug tracker.

RAM commented

2020-05-22 17:00:11 +02:00

Added subscriber: @CrossmindStudio

RAM commented

2020-05-22 17:00:11 +02:00

Hi,
Any further development on this task?
I am facing the same issue - When cycles is rendering, it resets to use all cores even if the affinity is set to not use all the cores.
When dealing with larger files, operating systems are rendered useless to use it for any other task, unless you can set the affinity of the blender to not use few cores.
It helps a lot, crucial for multitasking.

Hi, Any further development on this task? I am facing the same issue - When cycles is rendering, it resets to use all cores even if the affinity is set to not use all the cores. When dealing with larger files, operating systems are rendered useless to use it for any other task, unless you can set the affinity of the blender to not use few cores. It helps a lot, crucial for multitasking.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles resets manually set affinity #60145