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

[Tvrtko Ursulin]

On 11/04/2018 11:27, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-04-11 10:46:31)
>> +/**
>> + * struct drm_i915_engine_info
>> + *
>> + * Describes one engine known to the driver, whether or not is physical engine
>> + * only, or it can also be targetted from userspace, and what are its
>> + * capabilities where applicable.
>> + */
>> +struct drm_i915_engine_info {
>> +       /** Engine flags. */
>> +       __u64 flags;
>> +#define I915_ENGINE_FLAG_PHYSICAL      (1 << 0)
>> +#define I915_ENGINE_FLAG_ABI           (1 << 1)
>> +
>> +       /** Engine class as in enum drm_i915_gem_engine_class. */
>> +       __u16 class;
>> +
>> +       /** Engine instance number. */
>> +       __u16 instance;
>> +
>> +       __u32 rsvd0;
>> +
>> +       /** Capabilities of this engine. */
>> +       __u64 capabilities;
>> +#define I915_VCS_CLASS_CAPABILITY_HEVC (1 << 0)
>> +
>> +       __u64 rsvd1[2];
>> +};
>> +
>> +/**
>> + * struct drm_i915_query_engine_info
>> + *
>> + * Engine info query enumerates all the engines known to the driver returning
>> + * the array of struct drm_i915_engine_info structures.
>> + */
>> +struct drm_i915_query_engine_info {
>> +       /** Number of struct drm_i915_engine_info structs following. */
>> +       __u32 num_engines;
>> +
>> +       /** MBZ */
>> +       __u32 rsvd[3];
> 
> Ok, I can understand having some reserved fields before the [], but
> within struct drm_i915_engine_info isn't the size and layout determined
> by flags? (Thinking about the tight protocol packing of the 80s and
> slightly less tight packing for the 90s ;) Trade-off between ease of
> decoder and running out of space?

How did that old saying go, was it "When in doubt, pad it out."? :)

But I think it is good to have some reserved fields rather than rely on 
flags to extend the size of the structure. In any case I don't see a 
significant downside to reserved fields.

Regards,

Tvrtko