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

[Tvrtko Ursulin]

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.

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?

Regards,

Tvrtko