On Thu Jun 19, 2025 at 5:55 AM PDT, Christopher Snowhill wrote:
> From: Christopher Snowhill <ch...@kode54.net>
>
> amdgpu apparently fudges atomic flips if some software is also tweaking
> the cursor planes during flips, which results in lovely fallback to non-
> atomic flips.
>
> Fixes: 41129e236f14 ("drm/amdgpu: Enable async flip on overlay planes")
> Signed-off-by: Christopher Snowhill <ch...@kode54.net>
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Is there some reason why this was decided to be this way? I see it
> hasn't changed much since 2018, until the addition of overlay
> plane checking.
>
> Re: https://gitlab.freedesktop.org/drm/amd/-/issues/4263
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index b7c6e8d13435..f0c98d67e1f3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -1268,7 +1268,8 @@ static int amdgpu_dm_plane_atomic_async_check(struct
> drm_plane *plane,
> struct dm_crtc_state *dm_new_crtc_state;
>
> if (flip) {
> - if (plane->type != DRM_PLANE_TYPE_OVERLAY)
> + if (plane->type != DRM_PLANE_TYPE_OVERLAY &&
> + plane->type != DRM_PLANE_TYPE_CURSOR)
> return -EINVAL;
> } else if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> return -EINVAL;
This is called from drm_atomic_set_property in
drivers/gpu/drm/drm_atomic_uapi.c, and clearly, that wants to perform an
async_check even if an above function call determines that the
properties being applied are a no-op according to check_prop_changes.
I do not know whether all of the tearing capable DEs or compositors are
in the wrong here, or whether the DRM subsystem is doing something wrong
for AMD, and possibly other GPU vendors if they support async cursor
changes. Clearly something is sending prop changes on the cursor plane,
whether they are allowed-for-primary fb_id, in_fence_fd, or
fb_damage_clips, or whether they are no-ops. The only thing stopping the
transaction is that a cursor plane check hits async_check, and it's
failing for AMD.
Perhaps I should be running full DRM debug logging against Plasma and
labwc to determine what they're writing during the game presentation?
Seems strange that there are atomic cursor plane updates, when KDE is
supposed to be disabling the cursor plane for tearing, and in this case,
the game itself is not presenting a moving cursor at the time, as it is
in the main game view, and even if the target reticle is a cursor, it is
neither moving from the center of the screen nor is its plane being
changed in a visible way.
Something screwy is going on, that's for sure.
