The way we are organizing this code, the statically configured max_cs_threads
should always be the minimum value we actually support (ie. are aware of). As a
result, we can fall back to that if we get invalid numbers from the kernel (ie.
when the query succeeds, but the result is lower than expected).
I was originally planning to use an assert, but there is no reason to be so
mean.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com
screen->subslice_total > 0 && screen->eu_total > 0) {
/* Logical CS threads = EUs per subslice * 7 threads per EU */
brw->max_cs_threads = screen->eu_total / screen->subslice_total * 7;
+
+ /* Fuse configurations may give more threads than expected, never less. */
+ if (brw->max_cs_threads < devinfo->max_cs_threads)
+ brw->max_cs_threads = devinfo->max_cs_threads;
} else {
brw->max_cs_threads = devinfo->max_cs_threads;
}
/**
* Total number of slices present on the device whether or not they've been
* fused off.
+ *
+ * XXX: CS thread counts are limited by the inability to do cross subslice
+ * communication. It is the effectively the number of logical threads which
+ * can be executed in a subslice. Fuse configurations may cause this number
+ * to change, so we program @max_cs_threads as the lower maximum.
*/
unsigned num_slices;
unsigned max_vs_threads;