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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
