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

[Tvrtko Ursulin]

On 20/05/2019 11:59, Chris Wilson wrote:
> 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.

Hm.. this is quite an appealing idea. I'll give it some thought to see 
how difficult or easy it would be to implement it. I however ask for 
dispensation to consider this follow up work since turning some 
implementation details on their head could be a bit time consuming.

Regards,

Tvrtko