From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
Alex Deucher <alexdeucher@gmail.com>
Cc: amd-gfx@lists.freedesktop.org, kernel-dev@igalia.com,
Mario Limonciello <mario.limonciello@amd.com>,
Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [RFC] drm/amdgpu/sdma5.2: Avoid latencies caused by the powergating workaround
Date: Wed, 16 Jul 2025 15:00:39 +0200 [thread overview]
Message-ID: <83463d64-b0dc-43e7-b098-b978c44756da@amd.com> (raw)
In-Reply-To: <a07c4db8-a775-4036-a30e-8266c02283df@igalia.com>
On 16.07.25 14:51, Tvrtko Ursulin wrote:
>>>>>> be disabled once GFX/SDMA is no longer active. In this particular
>>>>>> case there was a race condition somewhere in the internal handshaking
>>>>>> with SDMA which led to SDMA missing doorbells sometimes and not
>>>>>> executing the job even if there was work in the ring.
>>>>>
>>>>> Thank you, more or less than what I assumed.
>>>>>
>>>>> But in this case there should be no harm in holding GFXOFF disabled
>>>>> until the job completes (like this patch)? Only a win to avoid the SMU
>>>>> communication latencies while unit is powered on anyway.
>>>>
>>>> The extra latency is only on the CPU side, once the
>>>> amdgpu_ring_commit() is called the SDMA engine is already working.
>>>
>>> It is on the CPU side but can create bubbles in the pipeline, no? Is
>>> there no scope with AMD to have GFX and SDMA jobs depend on each other?
>>> Because, as said, I've seen some high latencies from the GFXOFF disable
>>> calls.
>>
>> The SDMA job is already executing at that point. The allow gfxoff
>> message to the firmware shouldn't come until later because it's
>> handled by a delayed work thread from end_use(). If you have multiple
>> submissions to SDMA within the delay window, the begin_use() and
>> end_use() will just be ref count handling and won't actually talk to
>> the firmware.
>
> I followed up with testing a bunch more games, and is it turns out, Cyberpunk 2077 is the only one which has this submission patterns where default GFX_OFF_DELAY_ENABLE is regularly defeated.
>
> There, around 1.2 times per second the SDMA submissions miss that 100ms hysteresis and cause a CPU latency over 100us (I only measured when >100us and ignored the rest). Average latency is ~400us and max is ~2ms. So IMHO quite bad.
What exactly does Cyberpunk do to hit that? Are those SDMA page table updates, clears or userspace submissions?
>
> And the vast majority of those latencies come from the SMU request. Only very rarely someone hits the mutex contention path.
>
> So that was the motivation for the RFC. I suppose I could have also proposed to increase the hysteresis, but holding the GFXOFF disabled for the duration of the job sounded preferable for power consmuption.
>
> Anyway, given I only found Cyberpunk 2077 suffers from this I guess it maybe isn't to interesting to upstream for you guys. Then again it is limited to specific old SKU so maybe it should not be that controversial either? Only that Christian NAKed tying it to job lifetime. So I don't know, AMDs call.
Well what you could do is to take a look if we couldn't simplify the SMU and/or adjust the GFX_OFF_DELAY_ENABLED.
On the other hand why does it help to keep GFXOFF disabled while running the SDMA job?
Regards,
Christian.
>
> Regards,
>
> Tvrtko
>
next prev parent reply other threads:[~2025-07-16 13:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 12:23 [RFC] drm/amdgpu/sdma5.2: Avoid latencies caused by the powergating workaround Tvrtko Ursulin
2025-07-11 12:45 ` Christian König
2025-07-11 13:22 ` Tvrtko Ursulin
2025-07-11 13:39 ` Alex Deucher
2025-07-11 13:58 ` Tvrtko Ursulin
2025-07-11 15:27 ` Christian König
2025-07-11 15:51 ` Alex Deucher
2025-07-11 16:07 ` Tvrtko Ursulin
2025-07-11 16:51 ` Alex Deucher
2025-07-16 12:51 ` Tvrtko Ursulin
2025-07-16 13:00 ` Christian König [this message]
2025-07-16 14:06 ` Tvrtko Ursulin
2025-07-16 14:58 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83463d64-b0dc-43e7-b098-b978c44756da@amd.com \
--to=christian.koenig@amd.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=mario.limonciello@amd.com \
--cc=tvrtko.ursulin@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.