On 21/06/2017 10:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-21 10:13:57)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
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@xxxxxxxxx>
Cc: Ben Widawsky <ben@xxxxxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Daniel Vetter <daniel.vetter@xxxxxxxxx>
Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Cc: Jon Bloomfield <jon.bloomfield@xxxxxxxxx>
Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@xxxxxxxxx>
Cc: Oscar Mateo <oscar.mateo@xxxxxxxxx>
Cc: "Gong, Zhipeng" <zhipeng.gong@xxxxxxxxx>
Cc: intel-vaapi-media@xxxxxxxxxxxx
--
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
