> -----Original Message----- > From: Tvrtko Ursulin [mailto:tursu...@ursulin.net] > Sent: Wednesday, March 14, 2018 7:06 AM > To: Intel-gfx@lists.freedesktop.org > Cc: tursu...@ursulin.net; Ursulin, Tvrtko <tvrtko.ursu...@intel.com>; Chris > Wilson <ch...@chris-wilson.co.uk>; Bloomfield, Jon > <jon.bloomfi...@intel.com>; Rogozhkin, Dmitry V > <dmitry.v.rogozh...@intel.com>; Landwerlin, Lionel G > <lionel.g.landwer...@intel.com>; Joonas Lahtinen > <joonas.lahti...@linux.intel.com> > Subject: [RFC] drm/i915: Engine discovery query > > From: Tvrtko Ursulin <tvrtko.ursu...@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.ursu...@intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Jon Bloomfield <jon.bloomfi...@intel.com> > Cc: Dmitry Rogozhkin <dmitry.v.rogozh...@intel.com> > Cc: Lionel Landwerlin <lionel.g.landwer...@intel.com> > Cc: Joonas Lahtinen <joonas.lahti...@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. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
