Re: [igt-dev] [PATCH i-g-t 12/25] gem_wsim: Engine map support

Chris Wilson
2019-05-20T10:59:54Z

Quoting Tvrtko Ursulin (2019-05-20 11:49:13)
>
> On 17/05/2019 20:35, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-17 12:25:13)
> >> + /*
> >> + * Ensure VCS is not allowed with engine map contexts.
> >> + */
> >> + for (j = 0; j < wrk->nr_ctxs; j += 2) {
> >> + for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
> >> + if (w->context != (j / 2))
> >> + continue;
> >> +
> >> + if (w->type != BATCH)
> >> + continue;
> >> +
> >> + if (wrk->ctx_list[j].engine_map && w->engine == VCS) {
> >
> > But wouldn't VCS still be meaning use the balancer and not a specific
> > engine???
> >
> > I'm not understanding how you are using maps in the .wsim :(
>
> Batch sent to VCS means any VCS if not a context with a map, but VCS
> mentioned in the map now auto-expands to all present VCS instances.
>
> VCS as engine specifier at execbuf time could be allowed if code would
> then check if there is a load balancer built of vcs engines in this context.
>
> But what use case you think is not covered?
>
> We got legacy wsim files which implicitly create a map by doing:
>
> 1.VCS.1000.0.0 -> submit a batch to any vcs
>
> And then after this series you can also do:
>
> M.1.VCS
> B.1
> 1.DEFAULT.1000.0.0
>
> Which would have the same effect.
>
> You would seem want:
>
> M.1.VCS
> B.1
> 1.VCS.1000.0.0
>
> ?
>
> But I don't see what it gains?

I just have a picture of a map consisting of

[RCS] = rcs0,
[BCS] = 0,
[VCS] = (vcs0, vcs2),

Then the workload would be a single context, feeding batches to RCS and
VCS, which are then mapped to hardware and balanced as suitable. One
could go even further with RCS0, RCS1 for different logical state within
the same client context (different pipelines, same vm). That is how I
think I would decompose the media workloads given a fresh start on top
of the new api -- and then probably cursing the limits of that api.
-Chris