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.
Intel-gfx mailing list