[PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay

[Rodrigo Siqueira]

Hi Simon,

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"
 
> 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.

> > 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. 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:

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.

Best Regards

-- 
Rodrigo Siqueira
https://siqueira.tech