Re: [PATCH] drm/radeon: restore hardware polling in fence_is_signaled to fix performance regression

On Wed, 2026-08-05 at 10:34 +0200, Christian König wrote:
> On 7/29/26 12:26, [email protected] wrote:
> > From: Wang Jiang <[email protected]>
> > 
> > Commit 9eb00b5f5697b ("drm/radeon: delete radeon_fence_process in
> > is_signaled, no deadlock") removed the hardware polling from
> > radeon_fence_is_signaled() to fix a self-deadlock caused by
> > wake_up_all(&rdev->fence_queue) being called with the fence queue
> > lock held.
> > 
> > However, removing the polling entirely causes significant performance
> > regression (e.g. glxgears FPS drop) because the fence signaled check
> > becomes purely passive — it only reads the cached last_seq without
> > probing the GPU, so completed GPU work is not detected in time,
> > causing unnecessary CPU stalls in sync-heavy workloads.
> > 
> > Fix this by calling radeon_fence_activity() directly instead of
> > radeon_fence_process(). radeon_fence_activity() reads the hardware
> > fence counter and updates last_seq via atomic ops without calling
> > wake_up_all(), thus avoiding the deadlock while restoring timely
> > fence detection.
> 
> Yeah I already feared that removing this in commit 9eb00b5f5697b
> could cause issues.
> 
> Adding Philip and Danilo since we recently had a discussion about the
> necessity of this.

necessity of avoiding deadlocks with the callbacks somehow, or the
necessity for opportunistic signaling?


What we were wondering about was

a) who can even reach the hardware_fence when the gpu scheduler's fence
is in between and

b) why it might be a problem if we lock in dma_fence_is_signaled(),
because it would mean that someone (e.g. in userspace) is busy-looping
on the fence.


Since radeon does not use drm_sched, it seems to be one example for a),
I can see that.


Regards
P.