[Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend
David Weinehall
david.weinehall at intel.com
Wed Apr 5 15:51:42 UTC 2017
On 2017-04-05 18:46, Kamble, Sagar A wrote:
> On 4/5/2017 6:32 PM, David Weinehall wrote:
>> On 2017-04-05 15:54, Joonas Lahtinen wrote:
>>> On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:
>>>> i915 is currently doing Full GPU reset at the end of suspend
>>>> followed by
>>>> GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
>>>> suspend before we do a direct intel_gpu_reset, Otherwise the gpu
>>>> state will
>>>> no longer match the GuC's expectations and its suspend will not be
>>>> successful. With this change, i915 suspends GuC after suspending
>>>> GEM and
>>>> before doing Full GPU reset.
>>> + David, Oscar and Michel
>>>
>>> My understanding is that reloading GuC firmware after each resume is a
>>> major bottleneck in resume time, and we instead should be telling GuC
>>> to suspend and not reset the GPU, at most only reset the engines.
>>>
>>> Regards, Joonas
>>
>> If this is possible, then yes, it'd definitely be preferable. If not,
>> then doing the GuC + HuC loading asynchronously on resume would be
>> preferable.
>> Anusha mentioned working on asynchronous loading, hence added to CC.
>>
>>
>> Kind regards, David
> Data points about GuC load times for reference that I collected today
> on SKL and APL.
> At Rpn(lowest frequency) it loads/becomes ready in 3-4 jiffies.
> Running at >=RPe it becomes ready in a jiffy.
> Are these times in tolerable limits?
> Another concern Daniele highlighted was rare chance of WOPCM
> persisting post suspend/resume and hence needing reload.
> I believe the fetch from disk must be time consuming during boot time
> load and for that asynchronous
> load can be pursued.
>
I've seen times on the order of 30-35ms. It should be noted though that
this included HuC (and HuC verifying the integrity of HuC or whatever it
does).
I can re-run the tests once I'm done with various other tests I'm doing
right now though;
my GuC-related tests are quite old, since it's not loaded by default
(which is probably a good
thing, considering the stability issues we're seeing with GuC).
Kind regards, David
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
More information about the Intel-gfx
mailing list