9:58 p.m.
On 21/06/2017 10:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-21 10:13:57)
> From: Tvrtko Ursulin <tvrtko.ursulin(a)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(a)intel.com>
> Cc: Ben Widawsky <ben(a)bwidawsk.net>
> Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter(a)intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com>
> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin(a)intel.com>
> Cc: Oscar Mateo <oscar.mateo(a)intel.com>
> Cc: "Gong, Zhipeng" <zhipeng.gong(a)intel.com>
> Cc: intel-vaapi-media(a)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?
Regards,
Tvrtko
1913
days inactive
1913
days old
intel-vaapi-media@lists.01.org
0 comments
1 participants
participants (1)
-
Tvrtko Ursulin