On 21/06/2017 10:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-21 10:13:57)
From: Tvrtko Ursulin <[email protected]>
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 <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Jon Bloomfield <[email protected]>
Cc: "Rogozhkin, Dmitry V" <[email protected]>
Cc: Oscar Mateo <[email protected]>
Cc: "Gong, Zhipeng" <[email protected]>
Cc: [email protected]
--
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
