Blender changes processor affinity unauthorized #50034

New Issue

Kai Kostack · 2016-11-15T15:17:01+01:00

Kai Kostack commented

2016-11-15 15:17:01 +01:00

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

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 ![report.png](https://archive.blender.org/developer/F401154/report.png)

Kai Kostack commented

2016-11-15 15:17:01 +01:00

Changed status to: 'Open'

Kai Kostack commented

2016-11-15 15:17:01 +01:00

Added subscriber: @KaiKostack-3

Sergey Sharybin commented

2016-11-15 15:27:27 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2016-11-15 15:27:27 +01:00

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.

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.

Kai Kostack commented

2016-11-15 15:47:57 +01:00

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.

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.

Sergey Sharybin self-assigned this 2016-11-15 17:28:27 +01:00

Sergey Sharybin commented

2016-11-15 17:28:27 +01:00

Added subscriber: @brecht

Sergey Sharybin commented

2016-11-15 17:28:27 +01:00

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 to check whether he have strong opinion here.

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 to check whether he have strong opinion here.

Kai Kostack commented

2016-11-15 19:49:34 +01:00

Appears good to me.

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

Appears good to me. What about the compositor ignoring threads, should I create a separate report on this?

Sergey Sharybin commented

2016-11-15 22:27:19 +01:00

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.

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.

Kai Kostack commented

2016-11-16 16:09:09 +01:00

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