[Intel-gfx] [PATCH] drm/i915: Allow set context SSEU on platforms after gen 11

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Mon Sep 23 10:34:19 UTC 2019


Replying with some more information for benefit of archives.

On 20/09/2019 22:29, Chris Wilson wrote:
> Quoting Summers, Stuart (2019-09-20 22:09:46)
>> On Thu, 2019-09-19 at 08:00 +0100, Tvrtko Ursulin wrote:
>>> On 18/09/2019 18:31, Stuart Summers wrote:
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559
>>>
>>> Unless there was some discussion I missed we can't just turn it on
>>> to
>>> work around a SKIP in IGT. Feature was deliberately limited to
>>> Icelake
>>> and even there just to a sub-set of possible configurations.
>>
>> No conversation was missed, or at least none I was a part of. Is there
>> a reason we don't allow this on future platforms?
>>
>> We do claim powergate support on TGL, so I assumed it would be good to
>> take this path on that platform. Maybe I'm misunderstanding something
>> here though.
> 
> The current interface is purely to work around a silicon issue on icl.
> It was not developed into a fully reconfigurable sseu interface mostly
> due to a lack of demonstrable need and a lack of appreciation of the
> tradeoffs between different system users (along with the claim that this
> is all meant to be handled by instructions in the command stream...).

For the record and from my memory, the demonstrated need pre-gen11 was 
from the media transcoding side where it benefited performance for some 
workload types. What wasn't clear was the best strategy of striking a 
balance between increased cost of context switching (between contexts 
with different sseu configs) and performance benefit of going with 
reduced sseu. Again from memory, the best option looked to be a hybrid 
solution of not re-configuring SSEU on every context switch, but done 
periodically from an external entity, based on workload types input. As 
such it did not align completely with the per-context controls.

> Another team did try to autoadjust sseu but also did not produce the
> rationale nor attempt to integrate with the existing code.

I forgot about this one, wonder what happened there. This was also for 
pre-gen11 but with demonstrated performance-per-Watt benefit for some 3d 
workloads on Android. This was known as "Dynamic SSEU".

Regards,

Tvrtko


More information about the Intel-gfx mailing list