[Intel-gfx] [PATCH] drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance

[Bloomfield, Jon]

> -----Original Message-----
> From: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>
> Sent: Friday, April 20, 2018 9:56 AM
> To: Bloomfield, Jon <jon.bloomfield at intel.com>; Tvrtko Ursulin
> <tursulin at ursulin.net>; Intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Adjust BSD2 semantics to mean
> any second VCS instance
> 
> 
> On 20/04/2018 15:19, Bloomfield, Jon wrote:
> >> -----Original Message-----
> >> From: Tvrtko Ursulin <tursulin at ursulin.net>
> >> Sent: Wednesday, April 18, 2018 2:34 AM
> >> To: Intel-gfx at lists.freedesktop.org
> >> Cc: tursulin at ursulin.net; Ursulin, Tvrtko <tvrtko.ursulin at intel.com>; Chris
> >> Wilson <chris at chris-wilson.co.uk>; Bloomfield, Jon
> >> <jon.bloomfield at intel.com>; Ye, Tony <tony.ye at intel.com>
> >> Subject: [PATCH] drm/i915/icl: Adjust BSD2 semantics to mean any second
> >> VCS instance
> >>
> >> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>
> >> 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 at intel.com>
> >> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> >> Cc: Jon Bloomfield <jon.bloomfield at intel.com>
> >> Cc: Tony Ye <tony.ye at intel.com>
> > 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?
> 
Fair point. Will you be physically inhibiting this legacy ABI for gen11? If you
intend to allow it it's worth merging, because right now it simply doesn't
work.
If you will never allow the legacy ABI, and will forcibly prevent it (hardcode
HAS_BSD2==0, for gen11+), then I agree we may as well carry the patch as
a delta until the new execbuf lands.