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