> -----Original Message----- > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> > Sent: Friday, April 20, 2018 9:56 AM > To: Bloomfield, Jon <jon.bloomfield@xxxxxxxxx>; Tvrtko Ursulin > <tursulin@xxxxxxxxxxx>; Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [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@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? > 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. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
