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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
