Fix T60145: Cycles resets manually set affinity

This change brings back old original logic which was checking
whether worker threads do fit into an active CPU group. But
it does it a bit smarter now and is also checking affinity
within that group. This way Cycles will use all threads on a
Threadripper2 CPU if it's set to automatic number of threads,
but on another hand will not change affinity if user requested
16 threads and changed Blender affinity.

1 files changed, 15 insertions, 3 deletions

diff --git a/intern/cycles/util/util_task.cpp b/intern/cycles/util/util_task.cpp
index 7e9f7313fba..4241c4aa8cc 100644
--- a/intern/cycles/util/util_task.cpp
+++ b/intern/cycles/util/util_task.cpp
@@ -228,9 +228,21 @@ int get_num_total_processors(const vector<int>& num_per_node_processors)
 void distribute_threads_on_nodes(const vector<thread*>& threads)
 {
 	const int num_threads = threads.size();
-	/* TODO(sergey): Skip overriding affinity if threads fits into the current
-	 * nodes/CPU group. This will allow user to tweak affinity for weird and
-	 * wonderful reasons. */
+	const int num_active_group_processors =
+	        system_cpu_num_active_group_processors();
+	VLOG(1) << "Detected " << num_active_group_processors << " processors "
+	        << "in active group.";
+	if(num_active_group_processors >= num_threads) {
+		/* If the current thread is set up in a way that its affinity allows to
+		 * use at least requested number of threads we do not explicitly set
+		 * affinity to the worker therads.
+		 * This way we allow users to manually edit affinity of the parent
+		 * thread, and here we follow that affinity. This way it's possible to
+		 * have two Cycles/Blender instances running manually set to a different
+		 * dies on a CPU. */
+		VLOG(1) << "Not setting thread group affinity.";
+		return;
+	}
 	vector<int> num_per_node_processors;
 	get_per_node_num_processors(&num_per_node_processors);
 	if(num_per_node_processors.size() == 0) {