On 2021-08-24 9:59 a.m., Simon Ser wrote:
Hi Rodrigo!
Thanks a lot for your reply! Comments below, please bear with me: I'm
a bit familiar with the cursor issues, but my knowledge of AMD hw is
still severely lacking.
On Wednesday, August 18th, 2021 at 15:18, Rodrigo Siqueira <Rodrigo.Siqueira@xxxxxxx> wrote:
On 08/18, Simon Ser wrote:
Hm. This patch causes a regression for me. I was using primary + overlay
not covering the whole primary plane + cursor before. This patch breaks it.
Which branch are you using? Recently, I reverted part of that patch,
see:
Revert "drm/amd/display: Fix overlay validation by considering cursors"
Right. This revert actually makes things worse. Prior to the revert the
overlay could be enabled without the cursor. With the revert the overlay
cannot be enabled at all, even if the cursor is disabled.
This patch makes the overlay plane very useless for me, because the primary
plane is always under the overlay plane.
I'm curious about your use case with overlay planes. Could you help me
to understand it better? If possible, describe:
1. Context and scenario
2. Compositor
3. Kernel version
4. If you know which IGT test describe your test?
I'm investigating overlay issues in our driver, and a userspace
perspective might help me.
I'm working on gamescope [1], Valve's gaming compositor. Our use-cases include
displaying (from bottom to top) a game in the background, a notification popup
over it in the overlay plane, and a cursor in the cursor plane. All of the
planes might be rotated. The game's buffer might be scaled and might not cover
the whole CRTC.
libliftoff [2] is used to provide vendor-agnostic KMS plane offload. In other
words, I'd prefer to avoid relying too much on hardware specific details, e.g.
I'd prefer to avoid hole-punching via a underlay (it might work on AMD hw, but
will fail on many other drivers).
Hi Simon,
Siqueria explained a bit below, but the problem is that we don't have
dedicated cursor planes in hardware.
It's easiest to under the hardware cursor as being constrained within
the DRM plane specifications. Each DRM plane maps to 1 (or 2) hardware
pipes and the cursor has to be drawn along with it. The cursor will
inherit the scale, bounds, and color management associated with the
underlying pipes.
From the kernel display driver perspective that makes things quite
difficult with the existing DRM API - we can only really guarantee you
get HW cursor when the framebuffer covers the entire screen and it is
unscaled or matches the scaling expected by the user.
Hole punching generally satisfies both of these since it's a transparent
framebuffer that covers the entire screen.
The case that's slightly more complicated is when the overlay doesn't
cover the entire screen but the primary plane does. We can still enable
the cursor if the primary plane and overlay have a matching scale and
color management - our display hardware can draw the cursor on multiple
pipes. (Note: this statement only applies for DCN2.1+)
If the overlay plane does not cover the entire screen and the scale or
the color management differs then we cannot enable the HW cursor plane.
As you mouse over the bounds of the overlay you will see the cursor
drawn differently on the primary and overlay pipe.
If the overlay plane and primary plane do not cover the entire screen
then you will lose HW cursor outside of the union of their bounds.
Correct me if I'm wrong, but I think your usecase [1] falls under the
category where:
1. Primary plane covers entire screen
2. Overlay plane does not cover the entire screen
3. Overlay plane is scaled
This isn't a support configuration because HW cursor cannot be drawn in
the same position on both pipes.
I think you can see a similar usecase to [1] on Windows, but the
difference is that the cursor is drawn on the "primary plane" instead of
on top of the primary and overlay. I don't remember if DRM has a
requirement that the cursor plane must be topmost, but we can't enable
[1] as long as it is.
I don't know if you have more usecases in mind than [1], but just as
some general recommendations I think you should only really use overlays
when they fall under one of two categories:
1. You want to save power:
You will burn additional power for the overlay pipe.
But you will save power in use cases like video playback - where the
decoder produces the framebuffer and we can avoid a shader composited
copy with its associated GFX engine overhead and memory traffic.
2. You want more performance:
You will burn additional power for the overlay pipe.
On bandwidth constrained systems you can save significant memory
bandwidth by avoiding the shader composition by allowing for direct
scanout of game or other application buffers.
Your usecase [1] falls under this category, but as an aside I discourage
trying to design usecases where the compositor requires the overlay for
functional purposes.
Best regards,
Nicholas Kazlauskas
I'm usually using the latest kernel (at the time of writing, v5.13.10), but I
often test with drm-tip or agd5f's amd-staging-drm-next, especially when
working on amdgpu patches.
My primary hardware of interest is RDNA 2 based (the upcoming Steam Deck), but
of course it's better if gamescope can run on a wide range of hardware.
I don't know if there's an IGT covering my use-case.
[1]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPlagman%2Fgamescope&data=04%7C01%7CNicholas.Kazlauskas%40amd.com%7C0a5e1d2ce0874a87929e08d96707743a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637654104020179511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PCliYWadIaVDDnEQUOONNo%2FmC2ieIMjUw9Zr4XP3XDM%3D&reserved=0
[2]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femersion%2Flibliftoff&data=04%7C01%7CNicholas.Kazlauskas%40amd.com%7C0a5e1d2ce0874a87929e08d96707743a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637654104020179511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q4NCvqFpwdSXVnBcBSdxCYII44ekOiQBWTe9SUDhFUo%3D&reserved=0
Basically, we cannot draw the cursor at the same size and position on
two separated pipes since it uses extra bandwidth and DML only run
with one cursor.
I don't understand this limitation. Why would it be necessary to draw the
cursor on two separate pipes? Isn't it only necessary to draw it once on
the overlay pipe, and not draw it on the primary pipe?
I will try to provide some background. Harry and Nick, feel free to
correct me or add extra information.
In the amdgpu driver and from the DRM perspective, we expose cursors as
a plane, but we don't have a real plane dedicated to cursors from the
hardware perspective. We have part of our HUPB handling cursors (see
commit "drm/amd/display: Add DCN3.1 DCHHUB" for a hardware block
overview), which requires a different way to deal with the cursor plane
since they are not planes in the hardware.
What are DCHUBBUB and MMHUBBUB responsible for? Is one handling the primary
plane and the other handling the overlay plane? Or something else entirely?
As a result, we have some
limitations, such as not support multiple cursors with overlay; to
support this, we need to deal with these aspects:
Hm, but I don't want to draw multiple cursors. I want to draw a single
cursor. If all planes are enabled, can't we paint the cursor only on the
overlay plane and not paint the cursor on the primary plane?
Or maybe it's impossible to draw the cursor on the overlay plane outside
of the overlay plane bounds?
I'm also confused by the commit message in "drm/amd/display: Fix two cursor
duplication when using overlay", because an overlay which doesn't cover the
whole CRTC used to work perfectly fine, even with the cursor plane enabled.
1. We need to make multiple cursor match in the same position and size.
Again, keep in mind that cursors are handled in the HUBP, which is the
first part of our pipe, and it is not a plane.
2. Fwiu, our Display Mode Library (DML), has gaps with multiple cursor
support, which can lead to bandwidth problems such as underflow. Part of
these limitations came from DCN1.0; the new ASIC probably can support
multiple cursors without issues.
Additionally, we fully support a strategy named underlay, which inverts
the logic around the overlay. The idea is to put the DE in the overlay
plane covering the entire screen and the other fb in the primary plane
behind the overlay (DE); this can be useful for playback video
scenarios.
Yeah, as I said above this requires knowing a lot about the target hardware,
which is a bit unfortunate. This requires hole-punching and significantly
changes the composition logic.
