> -----Original Message----- > From: Tvrtko Ursulin [mailto:tursulin@xxxxxxxxxxx] > Sent: Wednesday, March 14, 2018 7:06 AM > To: Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Cc: tursulin@xxxxxxxxxxx; Ursulin, Tvrtko <tvrtko.ursulin@xxxxxxxxx>; Chris > Wilson <chris@xxxxxxxxxxxxxxxxxx>; Bloomfield, Jon > <jon.bloomfield@xxxxxxxxx>; Rogozhkin, Dmitry V > <dmitry.v.rogozhkin@xxxxxxxxx>; Landwerlin, Lionel G > <lionel.g.landwerlin@xxxxxxxxx>; Joonas Lahtinen > <joonas.lahtinen@xxxxxxxxxxxxxxx> > Subject: [RFC] drm/i915: Engine discovery query > > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > 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@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Jon Bloomfield <jon.bloomfield@xxxxxxxxx> > Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@xxxxxxxxx> > Cc: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > --- > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
