[Intel-gfx] [RFC] drm/i915: Engine discovery query

[Bloomfield, Jon]

> -----Original Message-----
> From: Tvrtko Ursulin [mailto:tursulin at ursulin.net]
> Sent: Wednesday, March 14, 2018 7:06 AM
> To: Intel-gfx at lists.freedesktop.org
> Cc: tursulin at ursulin.net; Ursulin, Tvrtko <tvrtko.ursulin at intel.com>; Chris
> Wilson <chris at chris-wilson.co.uk>; Bloomfield, Jon
> <jon.bloomfield at intel.com>; Rogozhkin, Dmitry V
> <dmitry.v.rogozhkin at intel.com>; Landwerlin, Lionel G
> <lionel.g.landwerlin at intel.com>; Joonas Lahtinen
> <joonas.lahtinen at linux.intel.com>
> Subject: [RFC] drm/i915: Engine discovery query
> 
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> Engine discovery query allows userspace to enumerate engines, probe their
> configuration features, all without needing to maintain the internal PCI
> ID based database.
> 
> A new query for the generic i915 query ioctl is added named
> DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
> drm_i915_query_engine_info. The address of latter should be passed to the
> kernel in the query.data_ptr field, and should be large enough for the
> kernel to fill out all known engines as struct drm_i915_engine_info
> elements trailing the query.
> 
> As with other queries, setting the item query length to zero allows
> userspace to query minimum required buffer size.
> 
> Enumerated engines have common type mask which can be used to query all
> hardware engines, versus engines userspace can submit to using the execbuf
> uAPI.
> 
> Engines also have capabilities which are per engine class namespace of
> bits describing features not present on all engine instances.
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Jon Bloomfield <jon.bloomfield at intel.com>
> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin at intel.com>
> Cc: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> ---
> This is RFC for now since it is not very usable before the new execbuf API
> or virtual engine queue submission gets closer.
> 
> In this version I have added capability of distinguishing between hardware
> engines and ABI engines. This is to account for probable future use cases
> like virtualization, where guest might only see one engine instance, but
> will want to know overall hardware capabilities in order to tune its
> behaviour.

The patch looks good, but...

I can't see any use for exposing the unreachable engines. Can you elaborate on why a umd running
in a VM would need to know about the engines assigned to other VM's ? Is it even desirable to
leak the physical capabilities to VM's ?

In general a VM would have a very limited view of the underlying hardware. It's unlikely to even
be capable of discovering true h/w engine counts.