From: Simon Ser <contact@emersion.fr>
To: amd-gfx list <amd-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
wayland <wayland-devel@lists.freedesktop.org>,
Daniel Vetter <daniel@ffwll.ch>,
Alex Deucher <alexander.deucher@amd.com>,
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>,
Harry Wentland <Harry.Wentland@amd.com>,
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>,
Sean Paul <seanpaul@chromium.org>
Subject: amdgpu: atomic API and cursor/overlay planes
Date: Tue, 07 Sep 2021 14:03:18 +0000 [thread overview]
Message-ID: <JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr> (raw)
Hi all,
Recently I've been discussing with various people [1] [2] 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 [3],
but some changes in the amdgpu driver [1] 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
underneath.
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
implementation.
After discussion with Daniel Vetter [2], 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?
Thanks,
Simon
[1]: https://lore.kernel.org/amd-gfx/SrcUnUUGJquVgjp9P79uV8sv6s-kMHG4wp0S3b4Nh9ksi29EIOye5edofuXkDLRvGfvkkRpQZ9JM7MNqew2B3kFUhaxsonDRXprkAYXaQUo=@emersion.fr/
[2]: https://oftc.irclog.whitequark.org/dri-devel/2021-08-27#1630077257-1630078046;
[3]: https://github.com/Plagman/gamescope
next reply other threads:[~2021-09-07 14:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-07 14:03 Simon Ser [this message]
2021-09-14 16:42 ` amdgpu: atomic API and cursor/overlay planes Harry Wentland
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='JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr' \
--to=contact@emersion.fr \
--cc=Harry.Wentland@amd.com \
--cc=Nicholas.Kazlauskas@amd.com \
--cc=Rodrigo.Siqueira@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=seanpaul@chromium.org \
--cc=wayland-devel@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).