Re: [Intel-gfx] [PATCH 09/20] drm/i915/gem: Assign context id for async work

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 09/20] drm/i915/gem: Assign context id for async work
Date: Thu, 09 Jul 2020 13:07:00 +0100	[thread overview]
Message-ID: <159429642039.22162.913189691410719231@build.alporthouse.com> (raw)
In-Reply-To: <0af3b19d-ea9e-9558-ca4a-853070f8662e@linux.intel.com>

Quoting Tvrtko Ursulin (2020-07-09 12:59:51)
> 
> On 09/07/2020 12:07, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-07-09 12:01:29)
> >>
> >> On 08/07/2020 16:36, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2020-07-08 15:24:20)
> >>>> And what is the effective behaviour you get with N contexts - emit N
> >>>> concurrent operations and for N + 1 block in execbuf?
> >>>
> >>> Each context defines a timeline. A task is not ready to run until the
> >>> task before it in its timeline is completed. So we don't block in
> >>> execbuf, the scheduler waits until the request is ready before putting
> >>> it into the HW queues -- i.e. the number chain of fences with everything
> >>> that entails about ensuring it runs to completion [whether successfully
> >>> or not, if not we then rely on the error propagation to limit the damage
> >>> and report it back to the user if they kept a fence around to inspect].
> >>
> >> Okay but what is the benefit of N contexts in this series, before the
> >> work is actually spread over ctx async width CPUs? Is there any? If not
> >> I would prefer this patch is delayed until the time some actual
> >> parallelism is ready to be added.
> > 
> > We currently submit an unbounded amount of work. This patch is added
> > along with its user to restrict the amount of work allowed to run in
> > parallel, and also is used to [crudely] serialise the multiple threads
> > attempting to allocate space in the vm when we completely exhaust that
> > address space. We need at least one fence-context id for each user, this
> > took the opportunity to generalise that to N ids for each user.
> 
> Right, this is what I asked at the beginning - restricting amount of 
> work run in parallel - does mean there is some "blocking"/serialisation 
> during execbuf? Or it is all async but then what is restricted?

It's all* async, so the number of workqueues we utilise is restricted,
and so limits the number of CPUs we allow the one context to spread
across with multiple execbufs.

*fsvo all.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx