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

[Joonas Lahtinen]

Quoting Chris Wilson (2018-10-05 12:21:12)
> Quoting Tvrtko Ursulin (2018-10-05 09:34:35)
> > 
> > On 04/10/2018 15:32, Joonas Lahtinen wrote:
> > > Some comments below, mostly related to trying to keep the uapi header
> > > nice and tidy.
> > > 
> > > Quoting Tvrtko Ursulin (2018-10-04 14:32:48)
> > >> @@ -1747,6 +1748,52 @@ struct drm_i915_query_topology_info {
> > >>          __u8 data[];
> > >>   };
> > >>   
> > >> +/**
> > >> + * struct drm_i915_engine_info
> > >> + *
> > >> + * Describes one engine known to the driver, whether or not it is an user-
> > >> + * accessible or hardware only engine, and what are it's capabilities where
> > >> + * applicable.
> > >> + */
> > >> +struct drm_i915_engine_info {
> > >> +       /** Engine class as in enum drm_i915_gem_engine_class. */
> > >> +       __u16 class;
> > >> +
> > >> +       /** Engine instance number. */
> > >> +       __u16 instance;
> > >> +
> > >> +       /** Reserved field must be cleared to zero. */
> > >> +       __u32 rsvd0;
> > > 
> > > u32 class, u32 instance just to put the padding to good use?
> > 
> > There is some attractiveness to lose the padding, but I think in general 
> > we trashed it out to be u16:u16. So it is a question of consistency vs 
> > elegance and I give preference to consistency.
> > 
> > Chris, is your recollection also that we said u16:u16 for class:instance 
> > in all uAPI?
> 
> Yes, that is the conclusion we came to. I've changed my uABI to u16:u16
> as well.
> 
> u8:u8 too tight, u32:u32 very unlikely. u16 is goldilocks.

u32:u32 nicely aligns with u64 which is required in all structs ;)

As mentioned in IRC, I'd try to keep the uAPI structs lean and simple as
possible, but it's not a blocker to sprinkle some rsvd if others think
they are beneficial/pessimism is required.

Regards, Joonas