[Intel-gfx] [PATCH 4/4] drm/i915: expose rcs topology through discovery uAPI

[Chris Wilson]

Quoting Lionel Landwerlin (2017-11-10 16:37:33)
> On 09/11/17 17:34, Tvrtko Ursulin wrote:
> >
> > On 08/11/2017 16:22, Lionel Landwerlin wrote:
> > But in general would it be feasible to define and name the returned 
> > data more precisely? Like:
> >
> > struct drm_engine_rcs_engine_info {
> >     ...
> >     /existing_stuff/
> >     ...
> >
> > #define HAS_TOPOLOGY
> >     u32 flags;
> >
> >     struct {
> >         u32 this;
> >         u32 that;
> >         ...
> >         u8 mask[SOME_FUTURE_PROOF_NUMBER];
> >     } slice_topology;
> >
> >     struct {
> >         u32 this;
> >         u32 that;
> >         ...
> >         u8 mask[SOME_FUTURE_PROOF_NUMBER];
> >     } subslice_topology;
> >
> >     struct {
> >         u32 this;
> >         u32 that;
> >         ...
> >         u8 mask[SOME_FUTURE_PROOF_NUMBER];
> >     } eu_topology;
> > };
> 
> I'm pretty sure we'll need to expose more than these 3 properties here 
> (slice/subslice/eus) soon.
> Some of the components residing in the subslice could be of interest.
> So I'm reluctant to have all of this within a single struct which we 
> can't change the size of.

The struct size doesn't have to be fixed, just reported. The underlying
question is can we construct an interface that is flexible enough?

Something along the lines of perf (GL even) where the output format is
constructed by request from the user, then we only need to declare how
long each field will be, get to the user allocate the buffer, then fill
on the second pass.

Alternatively we output some ASN string?

I don't want to overengineer, but at the same time this looks to be the
perfect excuse to require enough flexibility to cater for future
complexity without going too meta. :)
-Chris