[Intel-gfx] [RFC 2/2] drm/i915: Engine capabilities uAPI

[Tvrtko Ursulin]

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?

Regards,

Tvrtko