On 20/04/2018 15:19, Bloomfield, Jon wrote:
-----Original Message-----
From: Tvrtko Ursulin <[email protected]>
Sent: Wednesday, April 18, 2018 2:34 AM
To: [email protected]
Cc: [email protected]; Ursulin, Tvrtko <[email protected]>; Chris
Wilson <[email protected]>; Bloomfield, Jon
<[email protected]>; Ye, Tony <[email protected]>
Subject: [PATCH] drm/i915/icl: Adjust BSD2 semantics to mean any second
VCS instance
From: Tvrtko Ursulin <[email protected]>
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 <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Jon Bloomfield <[email protected]>
Cc: Tony Ye <[email protected]>
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
