[Intel-gfx] [PATCH 5/8] drm/i915/perf: lock powergating configuration to default when active

[Lionel Landwerlin]

On 16/08/18 08:31, Tvrtko Ursulin wrote:
>
> On 15/08/2018 12:58, Tvrtko Ursulin wrote:
>>
>> On 14/08/2018 15:59, Lionel Landwerlin wrote:
>>> Hey Tvrtko,
>>>
>>> Thanks for taking over this series.
>>>
>>> I've been talking to developers using the i915/perf interface and 
>>> from their point of view, they expect the system to be in a stable 
>>> configuration when doing measurements.
>>>
>>> One issue with this patch on Gen11 is that it will lock the system 
>>> in a configuration that isn't workable for media workloads (all 
>>> subslices enabled).
>>> So I think we should set the value for the locked configuration per 
>>> generation (gen8-10: all slices/subslices, gen11: only subslices 
>>> that contain VME samplers) so that we always get a functional 
>>> configurations for all workloads.
>>> Could we want to select that configuration when opening perf?
>>
>> This would be via i915_perf.c/gen8_configure_all_contexts?
>>
>> Sounds like an unfortunate but workable compromise. As long as there 
>> doesn't appear another asymmetric slice feature in the future, which 
>> doesn't align with VME. Like one workloads wants slices 0 & 2, 
>> another wants 1 & 3, or whatever. If that happens then I don't know 
>> what we do apart from locking out perf/OA.
>>
>>> Another question is how do we expose the selected value to the user. 
>>> But that can be solved in a different series.
>>
>> SSEU get_param would cut it? Although it would be perhaps be 
>> unexpected to get different results depending on whether perf/OA is 
>> active or not.. Hm... export device and available bitmasks via get 
>> param? Device bitmask would be fixed and available would change 
>> depending on whether perf/OA is active or not.

I would avoid changing the get_param. This is supposed to report the 
physical device's properties.
Maybe add an ioctl entry to report that configuration onto the i915_perf fd?

>
> Big downside to this is that observing something via OA would cause 
> slow down of the whole system - since the SSEU config would be locked 
> to a subset of slices on Gen11. :( Regardless or not of the details.. 
> say even if we choose to lock only if there is one non-default SSEU 
> context, that still locks all whilst perf/OA is active.
>
> That's quite bad I think. But the alternative is to lock out perf/OA 
> while non-default SSEU contexts are present. Which is also very bad. :(
>
> Overall I don't see a solution. Latter is maybe better by being more 
> explicit? Who are the perf/OA users and what would they prefer?

The other solution I could think of would be to prevent schedule 
contexts that are not compatible with the OA configuration.
That doesn't sound great either...

>
> Regards,
>
> Tvrtko
>