From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 445EEC77B7F for ; Mon, 23 Jun 2025 13:38:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0D70D10E1F5; Mon, 23 Jun 2025 13:38:13 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kode54.net header.i=@kode54.net header.b="DuuONj0B"; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="hrCRETXJ"; dkim-atps=neutral Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3A74E10E1E4; Mon, 23 Jun 2025 13:38:03 +0000 (UTC) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id A5DF01140149; Mon, 23 Jun 2025 09:38:02 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Mon, 23 Jun 2025 09:38:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kode54.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1750685882; x=1750772282; bh=XpttN5YtY4FHtv18lG5NubUylo/SyAsV2hjhDiGab2A=; b= DuuONj0B3Br30/klyNNSGbPBsDvQ7XQHysdLv9+gq6nTgVNXdv9ARO8724JYd1dH H0RjRb8mnSHFCgJiMJaO82jwbccEJYROPn/TnGmTTJtXSRF85SaBxOlU+C/hIHSG NetJWLCDYJtxYAj2w/5rlx0DCa0bbMhxk5GFTfPjwMdZwAe1SS7Y2hmV+xy3+Mzj iDTj7D/YlFnIlhW8H1ipvDIn8YfTE36W66sD7SW4KFAucpDC2Kj2XrRAkxXCEecF nEUOSF+bUaE+0DWv43Ra+fv6YV7QSgnenYe5QSDfcTgiBOI45w07i7B5ZAQti7ZB Dkj2c88zogmp+pLhiJXJPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1750685882; x= 1750772282; bh=XpttN5YtY4FHtv18lG5NubUylo/SyAsV2hjhDiGab2A=; b=h rCRETXJMnpYy0Wli41JZPZhAIvM6NRnoDyUGYAflG2k4AHvr/Nle8OAq0BI/80vv VGLzBysn0HSskYcRu83Ge8nR99d9iEscxzE8v2kvKStbWZQeN+4TIv/fTIh2Cse3 dHSFkaUBU45tQWEp6xAefANHqeu5ZDR1M3BYB5jG8QpT7BJ3+Obw1TqEmfpWIKsH Jm50crdWxr8S7d+bluMzW7cnRMsxodcfXs90iOSCfvk0vwm46rpEfXarYYt5iujz DJJMyCoMO82Ku0VZrl+3JUmuRU0CTcD+MJkUAhLeXiV5qKwqGEFLEbLXdnc0EVNs bPkCjveNz93kZU6WVyduA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujeduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpegggfgtfffkvefuhffvofhfjgesthhqredtredtjeenucfhrhhomhepfdevhhhrihhs thhophhhvghrucfunhhofihhihhllhdfuceotghhrhhisheskhhouggvheegrdhnvghtqe enucggtffrrghtthgvrhhnpeeileetudejffegjeegfffhhffhkeefjefgtddujeehheev leevjeejffekieekveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegthhhrihhssehkohguvgehgedrnhgvthdpnhgspghrtghpthhtohepuddu pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehkohguvgehgeesghhmrghilhdrtg homhdprhgtphhtthhopegrmhguqdhgfhigsehlihhsthhsrdhfrhgvvgguvghskhhtohhp rdhorhhgpdhrtghpthhtoheprghlvgigrghnuggvrhdruggvuhgthhgvrhesrghmugdrtg homhdprhgtphhtthhopegthhhrihhsthhirghnrdhkohgvnhhighesrghmugdrtghomhdp rhgtphhtthhopehmrggrrhhtvghnrdhlrghnkhhhohhrshhtsehlihhnuhigrdhinhhtvg hlrdgtohhmpdhrtghpthhtohepmhhrihhprghrugeskhgvrhhnvghlrdhorhhgpdhrtghp thhtohepthiiihhmmhgvrhhmrghnnhesshhushgvrdguvgdprhgtphhtthhopegrihhrlh hivggusehgmhgrihhlrdgtohhmpdhrtghpthhtohepughrihdquggvvhgvlheslhhishht shdrfhhrvggvuggvshhkthhophdrohhrgh X-ME-Proxy: Feedback-ID: i9ec6488d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 23 Jun 2025 09:38:01 -0400 (EDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 23 Jun 2025 06:38:01 -0700 Message-Id: Cc: "Alex Deucher" , =?utf-8?q?Christian_K=C3=B6nig?= , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "David Airlie" , "David Airlie" , , Subject: Re: [RFC PATCH] drm/amdgpu: Enable async flip for cursor planes From: "Christopher Snowhill" To: "Christopher Snowhill" , X-Mailer: aerc 0.20.1-0-g2ecb8770224a-dirty References: <20250619125507.54384-1-kode54@gmail.com> In-Reply-To: X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Mon Jun 23, 2025 at 4:06 AM PDT, Christopher Snowhill wrote: > On Mon Jun 23, 2025 at 3:46 AM PDT, Christopher Snowhill wrote: >> On Fri Jun 20, 2025 at 3:10 AM PDT, Christopher Snowhill wrote: >>> Here's another alternative change, which may be more thorough. It does >>> seem to fix the issue, at least. The issue does indeed appear to be >>> no-op plane changes sent to the cursor plane. >>> >>> If anyone wants to propose style changes, and suggest a proper commit >>> message, if this is indeed a welcome fix for the problem, please let me >>> know. >>> >>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_at= omic_uapi.c >>> index c2726af6698e..b741939698e8 100644 >>> --- a/drivers/gpu/drm/drm_atomic_uapi.c >>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c >>> @@ -1087,17 +1087,22 @@ int drm_atomic_set_property(struct drm_atomic_s= tate *state, >>> } >>> >>> /* ask the driver if this non-primary plane is supported */ >>> - if (plane->type !=3D DRM_PLANE_TYPE_PRIMARY) { >>> - ret =3D -EINVAL; >>> + else if (plane->type !=3D DRM_PLANE_TYPE_PRIMARY) { >>> + ret =3D drm_atomic_plane_get_property(plane, plane_state, >>> + prop, &old_val); >>> + >>> + if (ret || old_val !=3D prop_value) { >>> + ret =3D -EINVAL; >>> >>> - if (plane_funcs && plane_funcs->atomic_async_check) >>> - ret =3D plane_funcs->atomic_async_check(plane, state, true); >>> + if (plane_funcs && plane_funcs->atomic_async_check) >>> + ret =3D plane_funcs->atomic_async_check(plane, state, true); >>> >>> - if (ret) { >>> - drm_dbg_atomic(prop->dev, >>> - "[PLANE:%d:%s] does not support async flips\n", >>> - obj->id, plane->name); >>> - break; >>> + if (ret) { >>> + drm_dbg_atomic(prop->dev, >>> + "[PLANE:%d:%s] does not support async flips\n", >>> + obj->id, plane->name); >>> + break; >>> + } >>> } >>> } >>> } >> >> Upon further testing and reflection, I have come to the conclusion that >> this is indeed best handled by a kernel fix, rather than breaking user >> space. >> >> I attempted to work around this in wlroots, adjusting 0.18, 0.19, and >> 0.20 git with similar patches. First I attempted to stash all the >> written properties for the atomic code, storing an initial value of all >> 0xFE so it was always likely to write the first time, and only setting a >> property if it changed from the last commit. >> >> This resulted in whole commits breaking for one or both framebuffers >> until I ctrl-alt-fx switched to a tty and back again, and this would >> work again temporarily. >> >> So I went back to the drawing board and only withheld seemingly >> duplicate plane properties. This "worked", until I attempted to play a >> game, and then it started glitching spectacularly, and not updating at >> all if the game was doing direct scanout and vrr. >> >> Clearly this is wrong. >> >> The wlroots library queues up properties for each commit. On every >> commit where the cursor is disabled, it queues up both fb_id=3D0 and >> crtc_id=3D0. Every commit. Is this wrong? Should it only be queueing up >> the disablement properties once? It also queues up the full plane and >> hotspot properties when enabled, even if the cursor doesn't change >> position or appearance. > > Probably should have CC'd the drm misc maintainers when I started poking > drm misc instead of amdgpu. Pity there isn't a list for that... I am a dumbass, I didn't notice get_maintainer.pl. Added more people, and the correct list. Not sure if I should remove amd-gfx, since this affects them, somewhat... However, the intention of this thread was to seek commentary on the situation as it is.