From: "Christian König" <christian.koenig@amd.com>
To: Lucas Stach <l.stach@pengutronix.de>,
phasta@kernel.org, alexdeucher@gmail.com, simona.vetter@ffwll.ch,
faith@gfxstrand.net, sumit.semwal@linaro.org
Cc: linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/4] dma-buf/fence: give some reasonable maximum signaling timeout
Date: Fri, 5 Dec 2025 14:14:56 +0100 [thread overview]
Message-ID: <d425e9af-ee87-4495-b289-6533195f3ea1@amd.com> (raw)
In-Reply-To: <5267e8fbb93a8fe722f845331d17c61e29f1a705.camel@pengutronix.de>
On 11/26/25 17:11, Lucas Stach wrote:
> Am Mittwoch, dem 26.11.2025 um 16:44 +0100 schrieb Philipp Stanner:
>> On Wed, 2025-11-26 at 16:03 +0100, Christian König wrote:
>>
>>>>
> [...]
>>>> My hope would be that in the mid-term future we'd get firmware
>>>> rings
>>>> that can be preempted through a firmware call for all major
>>>> hardware.
>>>> Then a huge share of our problems would disappear.
>>>
>>> At least on AMD HW pre-emption is actually horrible unreliable as
>>> well.
>>
>> Do you mean new GPUs with firmware scheduling, or what is "HW pre-
>> emption"?
>>
>> With firmware interfaces, my hope would be that you could simply tell
>>
>> stop_running_ring(nr_of_ring)
>> // time slice for someone else
>> start_running_ring(nr_of_ring)
>>
>> Thereby getting real scheduling and all that. And eliminating many
>> other problems we know well from drm/sched.
>
> It doesn't really matter if you have firmware scheduling or not for
> preemption to be a hard problem on GPUs. CPUs have limited software
> visible state that needs to be saved/restored on a context switch and
> even there people start complaining now that they need to context
> switch the AVX512 register set.
Yeah, that has been discussed for the last 20 years or so when the first MMX extension came out.
> GPUs have megabytes of software visible state. Which needs to be
> saved/restored on the context switch if you want fine grained
> preemption with low preemption latency. There might be points in the
> command execution where you can ignore most of that state, but reaching
> those points can have basically unbounded latency. So either you can
> reliably save/restore lots of state or you are limited to very coarse
> grained preemption with all the usual issues of timeouts and DoS
> vectors.
> I'm not totally up to speed with the current state across all relevant
> GPUs, but until recently NVidia was the only vendor to have real
> reliable fine-grained preemption.
Completely agree. You won't believe how often that is a topic in discussions.
AMD has Compute Wave Save Restore now on newer HW, but both the reliability and performance are unfortunately questionable at best.
Regards,
Christian.
>
> Regards,
> Lucas
>
>
next prev parent reply other threads:[~2025-12-05 13:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 14:41 Reasonable maximum signaling timeout for dma_fences Christian König
2025-11-20 14:41 ` [PATCH 1/4] dma-buf/fence: give some reasonable maximum signaling timeout Christian König
2025-11-25 7:55 ` Philipp Stanner
2025-11-25 8:03 ` Christian König
2025-11-25 8:13 ` Philipp Stanner
2025-11-25 8:48 ` Christian König
2025-11-25 10:56 ` Philipp Stanner
2025-11-25 14:26 ` Christian König
2025-11-25 16:03 ` Philipp Stanner
2025-11-25 17:02 ` Lucas Stach
2025-11-26 12:31 ` Christian König
2025-11-26 12:37 ` Philipp Stanner
2025-11-26 15:03 ` Christian König
2025-11-26 15:44 ` Philipp Stanner
2025-11-26 15:59 ` Lucas Stach
2025-11-26 16:11 ` Lucas Stach
2025-12-05 13:14 ` Christian König [this message]
2025-11-20 14:41 ` [PATCH 2/4] dma-buf/sw-sync: always taint the kernel when sw-sync is used Christian König
2025-11-25 2:58 ` Sumit Semwal
2025-11-20 14:41 ` [PATCH 3/4] drm/vgem: use the reasonable maximum timeout defined by the dma_fence Christian König
2025-11-25 7:56 ` Philipp Stanner
2025-11-20 14:41 ` [PATCH 4/4] drm/sched: warn and taint the kernel when maximum timeout is exceeded Christian König
2025-11-25 8:08 ` Philipp Stanner
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=d425e9af-ee87-4495-b289-6533195f3ea1@amd.com \
--to=christian.koenig@amd.com \
--cc=alexdeucher@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith@gfxstrand.net \
--cc=l.stach@pengutronix.de \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=phasta@kernel.org \
--cc=simona.vetter@ffwll.ch \
--cc=sumit.semwal@linaro.org \
/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.