On 20/04/2018 15:19, Bloomfield, Jon wrote:
-----Original Message-----
From: Tvrtko Ursulin <tursulin@xxxxxxxxxxx>
Sent: Wednesday, April 18, 2018 2:34 AM
To: Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
Cc: tursulin@xxxxxxxxxxx; Ursulin, Tvrtko <tvrtko.ursulin@xxxxxxxxx>; Chris
Wilson <chris@xxxxxxxxxxxxxxxxxx>; Bloomfield, Jon
<jon.bloomfield@xxxxxxxxx>; Ye, Tony <tony.ye@xxxxxxxxx>
Subject: [PATCH] drm/i915/icl: Adjust BSD2 semantics to mean any second
VCS instance
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Currently our driver assumes BSD2 means hardware engine instance number
two. This does not work for Icelake parts with two VCS engines, but which
are hardware instances 0 and 2, and not 0 and 1 as with previous parts.
This makes the second engine not discoverable via HAS_BSD2 get param, nor
it can be targetted by execbuf.
While we are working on the next generation execbuf put in a hack which
allows discovery and access to this second VCS engine using legacy ABI.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Jon Bloomfield <jon.bloomfield@xxxxxxxxx>
Cc: Tony Ye <tony.ye@xxxxxxxxx>
I would advocate this patch being merged while the new execbuf API is being
developed. Currently there is no way to submit to 2 engine skus with non-sequential
engine id's. This doesn't introduce a new ABI, and there is no reason that I can see
that the new execbuf solution couldn't be made backward compatible with this.
It is a bit of a awkward period to commit to this permanently because it
only solves a subset of problem space and that makes it a hard sell in
that context.
If there was legacy userspace which ran on 2 VCS Gen11 then maybe, but
otherwise I think best is just wait for the new execbuf API. Or in fact
would there be _any_ upstream userspace using this before the new
execbuf API happens?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
