amdgpu: atomic API and cursor/overlay planes
harry.wentland at amd.com
Tue Sep 14 16:42:47 UTC 2021
On 2021-09-07 10:03, Simon Ser wrote:
> Hi all,
> Recently I've been discussing with various people   about amdgpu's
> handling of KMS planes. AMD hardware is a bit special when it comes to
> the cursor plane, and it's not always 100% clear how that maps with the
> KMS API.
> Up until now we were using cursor and overlay planes in gamescope ,
> but some changes in the amdgpu driver  makes us unable to use planes
> (and makes us fallback to composition). Basically, now the overlay
> cannot be used at all unless it covers the whole CRTC.
> The root cause is the cursor plane. The cursor plane can only be
> enabled if there is an unscaled plane covering the whole CRTC right
A bit of background on why that is:
DRM thinks of cursor and plane blending like this:
│ Cursor ├───────┐
│ Plane 1 ├──────► CRTC │
│ Plane 2 ├───────┘
AMD HW is designed like this:
┌─────────┐ ┌─────────┐ ┌───────┐
│ Cursor ├───► Plane 1 ├──────► CRTC │
└─────────┘ └─────────┘ └▲──────┘
│ Plane 2 ├───────┘
It means that the cursor cannot be drawn outside it's associated
plane, is scaled with the plane, and treated as being in the same
color space as the plane.
> So one might assume that as long as the cursor plane isn't used, the
> overlay plane could be enabled even if it doesn't cover the whole CRTC.
> Unfortunately, ChromeOS uses the atomic API to setup primary/overlay
> planes together with the legacy API to setup the cursor plane. This
> means that at any time ChromeOS can toggle the cursor plane and will
> expect the cursor plane to work.
> For this reason, amdgpu now restricts the use of the overlay plane.
> However this penalizes all KMS users because of a single user-space
> After discussion with Daniel Vetter , it seemed reasonable to add
> a ChromeOS quirk in the kernel which retains the current behavior, but
> require everybody else to use the atomic API properly, ie. not mix
> atomic overlay plane usage with legacy cursor plane usage. This would
> allow fully atomic user-space to better take advantage of overlay
> planes with amdgpu.
> Does this seem like an accurate summary of the situation? Does this
> seem like a reasonable path forward?
I think it's a good summary.
Won't adding a ChromeOS quirk break old ChromeOS userspace with a new
Though it seems to me that the ChromeOS compositor is doing atomic
wrong when it comes to the cursor, so the proposed solution might be
a decent temporary path forward until ChromeOS teaches their compositor
to not crash when cursor enablement causes atomic_check to fail.
Sean, any thoughts?
> : https://lore.kernel.org/amd-gfx/SrcUnUUGJquVgjp9P79uV8sv6s-kMHG4wp0S3b4Nh9ksi29EIOye5edofuXkDLRvGfvkkRpQZ9JM7MNqew2B3kFUhaxsonDRXprkAYXaQUofirstname.lastname@example.org/>> : https://oftc.irclog.whitequark.org/dri-devel/2021-08-27#1630077257-1630078046>> : https://github.com/Plagman/gamescope>>
More information about the wayland-devel