On 09/02/18 20:47, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2018-02-09 18:56:36)
On 09/02/18 02:22, Chris Wilson wrote:
Future gen reduce the number of bits we will have available to
differentiate between contexts, so reduce the lifetime of the ID
assignment from that of the context to its current active cycle (i.e.
only while it is pinned for use by the HW, will it have a constant ID).
This means that instead of a max of 2k allocated contexts (worst case
before fun with bit twiddling), we instead have a limit of 2k in flight
contexts (minus a few that have been pinned by the kernel or by perf).
Since we're moving to dynamic assignment would it be reasonable to move
the ID to intel_context with an ida per engine class instead of keeping
it at the i915_gem_context level? This would allow us to use more
contexts as long as they use different classes and it'd take us closer
to the way the HW thinks (lrcs on different classes are independent even
if they have the same ID). It could also make it easier to use the
sw_counter field to expand the maximum number of supported lrcs.
Just a thought, we can always do it as a follow up step.
Certainly doable, leads to lots of refinement about focusing on engines
rather than global requests (*shivers* every time I think about
struct_mutex around requests). Afaict, even perf userspace will not care
if the HW ID vary between engines for the same context; certainly that's
the only thing that might notice.
-Chris
Would it make sense to dedicate part of the HW ID bits to indicate the
engine and the rest a rolling integer that increments each time
something's submitted to the execlist ports?
-
Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
