Quoting Lionel Landwerlin (2018-02-21 01:12:46)
> 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?
Hmm. At present, I guess only OA requires a known hw-id. I thought we
would need it to service PASID faults (but I guess that isn't really our
problem). Can we go completely hw-id less and just using a rolling id?
Intel-gfx mailing list