[Mesa-dev] [RFC 1/2] drm/i915: Engine discovery uAPI

[Chris Wilson]

On Tue, Apr 18, 2017 at 05:56:14PM +0100, Tvrtko Ursulin wrote:
> +enum drm_i915_gem_engine_class {
> +	DRM_I915_ENGINE_CLASS_OTHER = 0,
> +	DRM_I915_ENGINE_CLASS_RENDER = 1,
> +	DRM_I915_ENGINE_CLASS_COPY = 2,
> +	DRM_I915_ENGINE_CLASS_VIDEO_DECODE = 3,
> +	DRM_I915_ENGINE_CLASS_VIDEO_ENHANCE = 4,
> +	DRM_I915_ENGINE_CLASS_MAX /* non-ABI */
> +};
> +
> +struct drm_i915_engine_info {
> +	/** Engine instance number. */
> +	__u32	instance;
> +	__u32	rsvd;
> +
> +	/** Engine specific info. */
> +#define DRM_I915_ENGINE_HAS_HEVC	BIT(0)
> +	__u64 info;
> +};

So the main question is how can we extend this in future, keeping
forwards/backwards compat?

I think if we put a query version into info and then the kernel supplies
an array matching that version (or reports the most recent version
supported if the request is too modern.)

The kernel has to keep all the old struct variants and exporters
indefinitely.

Another alternative would get an ENGINE_GETPARAM where we just have a
switch of all possibily questions. Maybe better as a CONTEXT_GETPARAM if
we start thinking about allowing CONTEXT_SETPARAM to fine tune
individual clients.

> +struct drm_i915_gem_engine_info {
> +	/** in: Engine class to probe (enum drm_i915_gem_engine_class). */
> +	__u32 engine_class;

__u32 [in/out] version ? (see above)

> +
> +	/** out: Actual number of hardware engines. */
> +	__u32 num_engines;
> +
> +	/**
> +	 * in: Number of struct drm_i915_engine_ifo entries in the provided
> +	 * info array.
> +	 */
> +	__u32 info_size;

This is superfluous with num_engines. The standard 2 pass, discovery of
size, followed by allocation and final query.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre