Page MenuHome

Cycles resets manually set affinity
Closed, ResolvedPublic

Description

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.

Event Timeline

Philipp Oeser (lichtwerk) triaged this task as Needs Information from User priority.Jan 4 2019, 9:49 AM

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

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 Sharybin (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.

Brecht Van Lommel (brecht) raised the priority of this task from Needs Information from User to Normal.Jan 4 2019, 11:23 AM

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

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

@Brecht Van Lommel (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 =/).

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.

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.

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?

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.