[Intel-gfx] [RFC 2/2] drm/i915: Engine capabilities uAPI
Chris Wilson
chris at chris-wilson.co.uk
Fri Jun 23 12:07:25 UTC 2017
Quoting Tvrtko Ursulin (2017-06-23 12:58:19)
>
> On 21/06/2017 10:45, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-06-21 10:13:57)
> >> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>
> >> This is a lighter-weight alternative to the previously posted
> >> RFC titled "drm/i915: Engine discovery uAPI" which still allows
> >> some engine configuration probing without depending on PCI ids.
> >>
> >> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >> Cc: Ben Widawsky <ben at bwidawsk.net>
> >> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> >> Cc: Daniel Vetter <daniel.vetter at intel.com>
> >> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> >> Cc: Jon Bloomfield <jon.bloomfield at intel.com>
> >> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin at intel.com>
> >> Cc: Oscar Mateo <oscar.mateo at intel.com>
> >> Cc: "Gong, Zhipeng" <zhipeng.gong at intel.com>
> >> Cc: intel-vaapi-media at lists.01.org
> >> --
> >> Floating as an alternative to the heavier engine discovery API
> >> sent previously which did not manage to gain much interest from
> >> userspace clients.
> >>
> >> With this one enumeration and feature discovery would be done by
> >> sending null batches to all engine instances. Downside is less
> >> extensibility if we are using a fixed and smaller number of eb
> >> flags.
> >
> > But we lose out on features? Just after you convinced me that features
> > was what we wanted! :-p
>
> We lose the features but get the capabilities :), if that was the joke!
>
> Or a concern that we might really want more data about stuff when
> probing? We could still add that later if we wanted since it is really a
> different thing altogether.
>
> This caps thing is actually 2nd part from another experiment I had,
> where the first part allowed userspace to tell us they do not care about
> the state, so we would be able to pick a VCS engine per-batch buffer,
> and not only statically per context.
>
> Maybe I add that one to this series as well and then it all becomes even
> more useful?
My minimum requirement for testing execbuf is to be able to explicitly
select an engine. So long as you do not exclude that possibility, I
don't mind. I was also happy if that requires us to query the set of engines
to figure out the mapping for the new interface.
-Chris
More information about the Intel-gfx
mailing list