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
