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

[Lionel Landwerlin]

On 10/11/17 16:47, Chris Wilson wrote:
> 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
>
Heh, so one ioctl to get the string, another ioctl to get the data?
And a list of enum for all the properties you can list?

Unrelated question, have you considered ASN to describe the error state 
layout?

-
Lionel