[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