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

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	"Summers, Stuart" <stuart.summers@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Allow set context SSEU on platforms after gen 11
Date: Mon, 23 Sep 2019 11:34:19 +0100	[thread overview]
Message-ID: <6675fc29-9763-da0c-b8be-5624d92a856b@linux.intel.com> (raw)
In-Reply-To: <156901497277.11001.11723215496577918349@skylake-alporthouse-com>

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx