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