Page MenuHome

Blender changes processor affinity unauthorized
Closed, ResolvedPublic


The current Blender version binds all CPUs of a system on its own authority to the Blender process, even after changed by user, and this is happening for each rendered frame repeatedly (see screenshot). This was never the case before 2.78 and I have never seen a program changing its own CPU bindings on Windows ever before.

Blender's compositor is also ignoring the threads count setting in the render panel and always attempts to take over all the power of the machine. This is probably not directly related to the first point, so that this might be worth creating a second task.

These behaviors make it difficult to use Blender in a more professional environment such as a render farm, because you have no control over what the Blender instances do anymore, if each one tries to hijack the entire system all the time. This can't be a good design in my opinion.

System: Windows 7 x64
Worked last: Blender 2.77

Event Timeline

This was an intentional change to work around Windows stupidness when running on more than 64 logical processors.

Not sure why API will successfully change affinity when it's restricted externally, usually this is not supposed to happen.

There might be some work around for that.

An intentional change that ignores previous affinity settings just to overwrite it, is not really better than "Windows stupidness".

I would suggest to take these previous affinity settings into account within the 64 CPUs hack so that it becomes invisible again.

Not saying it's great to override manually specified affinity, just annoying that the whole 64+ threads on Windows is such a PITA :S

From a quick look around didn't find a reliable way of checking whether current CPU group is set by OS or by parent process which wants Blender to stick to a specific group only. So what about such policy:

  • Do not force any group/affinity if there's only one CPU group.
  • If there's more than one CPU groups, do not force group/affinity if the requested number of threads (in Preferences panel) is <= than number of threads in the current CPU group.

This way we will solve all regressions on a systems with single CPU group and will behave ok-ish on a systems with more than one CPU group.

Assigning to self, adding @Brecht Van Lommel (brecht) to check whether he have strong opinion here.

Sergey Sharybin (sergey) lowered the priority of this task from Needs Triage by Developer to Normal.Nov 15 2016, 5:30 PM

Appears good to me.

What about the compositor ignoring threads, should I create a separate report on this?

Yes, think it's better to create separate report about compositor. I'm not fully sure yet why it happens tho, so would have a closer look tomorrow.

Feel free to assign that report to me.

I couldn't reproduce the compositor issue, so I assume a mistake from my side. It works correctly, don't bother.

@Sergey Sharybin (sergey), the heuristic looks ok, I can't find anything in the Windows API docs to solve this completely.