All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
@ 2021-04-14  0:06 Rodrigo Siqueira
  2021-04-14 13:29 ` Harry Wentland
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Rodrigo Siqueira @ 2021-04-14  0:06 UTC (permalink / raw)
  To: amd-gfx
  Cc: Sean Paul, Hersen Wu, Harry Wentland, Nicholas Kazlauskas, Louis Li

Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with various planes. 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.

For those reasons, when we enable hardware cursor and multiple planes,
our driver should accept variations like the ones described below:

  +-------------+   +--------------+
  | +---------+ |   |              |
  | |Primary  | |   | Primary      |
  | |         | |   | Overlay      |
  | +---------+ |   |              |
  |Overlay      |   |              |
  +-------------+   +--------------+

In this scenario, we can have the desktop UI in the overlay and some
other framebuffer attached to the primary plane (e.g., video). However,
userspace needs to obey some rules and avoid scenarios like the ones
described below (when enabling hw cursor):

                                      +--------+
                                      |Overlay |
 +-------------+    +-----+-------+ +-|        |--+
 | +--------+  | +--------+       | | +--------+  |
 | |Overlay |  | |Overlay |       | |             |
 | |        |  | |        |       | |             |
 | +--------+  | +--------+       | |             |
 | Primary     |    | Primary     | | Primary     |
 +-------------+    +-------------+ +-------------+

 +-------------+   +-------------+
 |     +--------+  |  Primary    |
 |     |Overlay |  |             |
 |     |        |  |             |
 |     +--------+  | +--------+  |
 | Primary     |   | |Overlay |  |
 +-------------+   +-|        |--+
                     +--------+

If the userspace violates some of the above scenarios, our driver needs
to reject the commit; otherwise, we can have unexpected behavior. Since
we don't have a proper driver validation for the above case, we can see
some problems like a duplicate cursor in applications that use multiple
planes. This commit fixes the cursor issue and others by adding adequate
verification for multiple planes.

Change since V1 (Harry and Sean):
- Remove cursor verification from the equation.

Cc: Louis Li <Ching-shih.Li@amd.com>
Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Hersen Wu <hersenxs.wu@amd.com>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e29cb2e956db..ac1408d52eff 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9946,6 +9946,53 @@ static int add_affected_mst_dsc_crtcs(struct drm_atomic_state *state, struct drm
 }
 #endif
 
+static int validate_overlay(struct drm_atomic_state *state)
+{
+	int i;
+	struct drm_plane *plane;
+	struct drm_plane_state *old_plane_state, *new_plane_state;
+	struct drm_plane_state *primary_state, *overlay_state = NULL;
+
+	/* Check if primary plane is contained inside overlay */
+	for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state, new_plane_state, i) {
+		if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
+			if (drm_atomic_plane_disabling(plane->state, new_plane_state))
+				return 0;
+
+			overlay_state = new_plane_state;
+			continue;
+		}
+	}
+
+	/* check if we're making changes to the overlay plane */
+	if (!overlay_state)
+		return 0;
+
+	/* check if overlay plane is enabled */
+	if (!overlay_state->crtc)
+		return 0;
+
+	/* find the primary plane for the CRTC that the overlay is enabled on */
+	primary_state = drm_atomic_get_plane_state(state, overlay_state->crtc->primary);
+	if (IS_ERR(primary_state))
+		return PTR_ERR(primary_state);
+
+	/* check if primary plane is enabled */
+	if (!primary_state->crtc)
+		return 0;
+
+	/* Perform the bounds check to ensure the overlay plane covers the primary */
+	if (primary_state->crtc_x < overlay_state->crtc_x ||
+	    primary_state->crtc_y < overlay_state->crtc_y ||
+	    primary_state->crtc_x + primary_state->crtc_w > overlay_state->crtc_x + overlay_state->crtc_w ||
+	    primary_state->crtc_y + primary_state->crtc_h > overlay_state->crtc_y + overlay_state->crtc_h) {
+		DRM_DEBUG_ATOMIC("Overlay plane is enabled with hardware cursor but does not fully cover primary plane\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 /**
  * amdgpu_dm_atomic_check() - Atomic check implementation for AMDgpu DM.
  * @dev: The DRM device
@@ -10120,6 +10167,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 			goto fail;
 	}
 
+	ret = validate_overlay(state);
+	if (ret)
+		goto fail;
+
 	/* Add new/modified planes */
 	for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state, new_plane_state, i) {
 		ret = dm_update_plane_state(dc, state, plane,
-- 
2.25.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-04-14  0:06 [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay Rodrigo Siqueira
@ 2021-04-14 13:29 ` Harry Wentland
  2021-05-10  2:20 ` youling257
  2021-08-18 10:48 ` Simon Ser
  2 siblings, 0 replies; 14+ messages in thread
From: Harry Wentland @ 2021-04-14 13:29 UTC (permalink / raw)
  To: Rodrigo Siqueira, amd-gfx
  Cc: Sean Paul, Hersen Wu, Nicholas Kazlauskas, Louis Li



On 2021-04-13 8:06 p.m., Rodrigo Siqueira wrote:
> Our driver supports overlay planes, and as expected, some userspace
> compositor takes advantage of these features. If the userspace is not
> enabling the cursor, they can use multiple planes as they please.
> Nevertheless, we start to have constraints when userspace tries to
> enable hardware cursor with various planes. 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.
> 
> For those reasons, when we enable hardware cursor and multiple planes,
> our driver should accept variations like the ones described below:
> 
>    +-------------+   +--------------+
>    | +---------+ |   |              |
>    | |Primary  | |   | Primary      |
>    | |         | |   | Overlay      |
>    | +---------+ |   |              |
>    |Overlay      |   |              |
>    +-------------+   +--------------+
> 
> In this scenario, we can have the desktop UI in the overlay and some
> other framebuffer attached to the primary plane (e.g., video). However,
> userspace needs to obey some rules and avoid scenarios like the ones
> described below (when enabling hw cursor):
> 
>                                        +--------+
>                                        |Overlay |
>   +-------------+    +-----+-------+ +-|        |--+
>   | +--------+  | +--------+       | | +--------+  |
>   | |Overlay |  | |Overlay |       | |             |
>   | |        |  | |        |       | |             |
>   | +--------+  | +--------+       | |             |
>   | Primary     |    | Primary     | | Primary     |
>   +-------------+    +-------------+ +-------------+
> 
>   +-------------+   +-------------+
>   |     +--------+  |  Primary    |
>   |     |Overlay |  |             |
>   |     |        |  |             |
>   |     +--------+  | +--------+  |
>   | Primary     |   | |Overlay |  |
>   +-------------+   +-|        |--+
>                       +--------+
> 
> If the userspace violates some of the above scenarios, our driver needs
> to reject the commit; otherwise, we can have unexpected behavior. Since
> we don't have a proper driver validation for the above case, we can see
> some problems like a duplicate cursor in applications that use multiple
> planes. This commit fixes the cursor issue and others by adding adequate
> verification for multiple planes.
> 

It might be good to have a brief mention that regardless of whether we 
have a cursor plane we want to reject the problematic plane configs 
since some userspace doesn't handle atomic check/commit rejections well 
when only the cursor enablement changes.

> Change since V1 (Harry and Sean):
> - Remove cursor verification from the equation.
> 
> Cc: Louis Li <Ching-shih.Li@amd.com>
> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
> Cc: Harry Wentland <Harry.Wentland@amd.com>
> Cc: Hersen Wu <hersenxs.wu@amd.com>
> Cc: Sean Paul <seanpaul@chromium.org>
> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>

EIther way, this patch is
Reviewed-by: Harry Wentland <harry.wentland@amd.com>

Harry

> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +++++++++++++++++++
>   1 file changed, 51 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e29cb2e956db..ac1408d52eff 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9946,6 +9946,53 @@ static int add_affected_mst_dsc_crtcs(struct drm_atomic_state *state, struct drm
>   }
>   #endif
>   
> +static int validate_overlay(struct drm_atomic_state *state)
> +{
> +	int i;
> +	struct drm_plane *plane;
> +	struct drm_plane_state *old_plane_state, *new_plane_state;
> +	struct drm_plane_state *primary_state, *overlay_state = NULL;
> +
> +	/* Check if primary plane is contained inside overlay */
> +	for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state, new_plane_state, i) {
> +		if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
> +			if (drm_atomic_plane_disabling(plane->state, new_plane_state))
> +				return 0;
> +
> +			overlay_state = new_plane_state;
> +			continue;
> +		}
> +	}
> +
> +	/* check if we're making changes to the overlay plane */
> +	if (!overlay_state)
> +		return 0;
> +
> +	/* check if overlay plane is enabled */
> +	if (!overlay_state->crtc)
> +		return 0;
> +
> +	/* find the primary plane for the CRTC that the overlay is enabled on */
> +	primary_state = drm_atomic_get_plane_state(state, overlay_state->crtc->primary);
> +	if (IS_ERR(primary_state))
> +		return PTR_ERR(primary_state);
> +
> +	/* check if primary plane is enabled */
> +	if (!primary_state->crtc)
> +		return 0;
> +
> +	/* Perform the bounds check to ensure the overlay plane covers the primary */
> +	if (primary_state->crtc_x < overlay_state->crtc_x ||
> +	    primary_state->crtc_y < overlay_state->crtc_y ||
> +	    primary_state->crtc_x + primary_state->crtc_w > overlay_state->crtc_x + overlay_state->crtc_w ||
> +	    primary_state->crtc_y + primary_state->crtc_h > overlay_state->crtc_y + overlay_state->crtc_h) {
> +		DRM_DEBUG_ATOMIC("Overlay plane is enabled with hardware cursor but does not fully cover primary plane\n");
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>   /**
>    * amdgpu_dm_atomic_check() - Atomic check implementation for AMDgpu DM.
>    * @dev: The DRM device
> @@ -10120,6 +10167,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
>   			goto fail;
>   	}
>   
> +	ret = validate_overlay(state);
> +	if (ret)
> +		goto fail;
> +
>   	/* Add new/modified planes */
>   	for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state, new_plane_state, i) {
>   		ret = dm_update_plane_state(dc, state, plane,
> 

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-04-14  0:06 [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay Rodrigo Siqueira
  2021-04-14 13:29 ` Harry Wentland
@ 2021-05-10  2:20 ` youling257
  2021-05-11  0:37   ` Rodrigo Siqueira
  2021-08-18 10:48 ` Simon Ser
  2 siblings, 1 reply; 14+ messages in thread
From: youling257 @ 2021-05-10  2:20 UTC (permalink / raw)
  To: Rodrigo.Siqueira
  Cc: amd-gfx, seanpaul, hersenxs.wu, Harry.Wentland,
	Nicholas.Kazlauskas, Ching-shih.Li

I using amd 3400g running with android-x86, this patch is a bad commit when i use android-x86 on amdgpu.

Revert "Revert "drm/amdgpu: Ensure that the modifier requested is supported by plane."" is the first bad commit, cause a androidx86 run on amdgpu problem, look the video, https://drive.google.com/file/d/1QklH_H2AlOTu8W1D3yl6_3rtZ7IqbjR_/view?usp=sharing

"drm/amd/display: Fix two cursor duplication when using overlay" is the second bad commit, also cause this problem, https://drive.google.com/file/d/1QklH_H2AlOTu8W1D3yl6_3rtZ7IqbjR_/view?usp=sharing
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-05-10  2:20 ` youling257
@ 2021-05-11  0:37   ` Rodrigo Siqueira
  2021-05-11  1:47     ` youling 257
  0 siblings, 1 reply; 14+ messages in thread
From: Rodrigo Siqueira @ 2021-05-11  0:37 UTC (permalink / raw)
  To: youling257
  Cc: amd-gfx, seanpaul, hersenxs.wu, Harry.Wentland,
	Nicholas.Kazlauskas, Ching-shih.Li


[-- Attachment #1.1: Type: text/plain, Size: 906 bytes --]

On 05/10, youling257 wrote:
> I using amd 3400g running with android-x86, this patch is a bad commit when i use android-x86 on amdgpu.
> 
> Revert "Revert "drm/amdgpu: Ensure that the modifier requested is supported by plane."" is the first bad commit, cause a androidx86 run on amdgpu problem, look the video, https://drive.google.com/file/d/1QklH_H2AlOTu8W1D3yl6_3rtZ7IqbjR_/view?usp=sharing
> 
> "drm/amd/display: Fix two cursor duplication when using overlay" is the second bad commit, also cause this problem, https://drive.google.com/file/d/1QklH_H2AlOTu8W1D3yl6_3rtZ7IqbjR_/view?usp=sharing

Hmmm... I don't think that the two cursor patch would cause that
flickering. Are you using the latest amd-staging-drm-next? Do you have
this patch in your local branch:

 drm/amd/display: Reject non-zero src_y and src_x for video planes

Thanks

-- 
Rodrigo Siqueira
https://siqueira.tech

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-05-11  0:37   ` Rodrigo Siqueira
@ 2021-05-11  1:47     ` youling 257
  0 siblings, 0 replies; 14+ messages in thread
From: youling 257 @ 2021-05-11  1:47 UTC (permalink / raw)
  To: Rodrigo Siqueira
  Cc: amd-gfx, seanpaul, hersenxs.wu, Harry.Wentland,
	Nicholas.Kazlauskas, Ching-shih.Li

I using linux kernel 5.13 rc1, has "drm/amd/display: Reject non-zero
src_y and src_x for video planes" patch, git bisect bad commit is
"drm/amd/display: Fix two cursor duplication when using overlay", i
build kernel 5.13 many times, reboot test many times.

2021-05-11 8:37 GMT+08:00, Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>:
> On 05/10, youling257 wrote:
>> I using amd 3400g running with android-x86, this patch is a bad commit
>> when i use android-x86 on amdgpu.
>>
>> Revert "Revert "drm/amdgpu: Ensure that the modifier requested is
>> supported by plane."" is the first bad commit, cause a androidx86 run on
>> amdgpu problem, look the video,
>> https://drive.google.com/file/d/1QklH_H2AlOTu8W1D3yl6_3rtZ7IqbjR_/view?usp=sharing
>>
>> "drm/amd/display: Fix two cursor duplication when using overlay" is the
>> second bad commit, also cause this problem,
>> https://drive.google.com/file/d/1QklH_H2AlOTu8W1D3yl6_3rtZ7IqbjR_/view?usp=sharing
>
> Hmmm... I don't think that the two cursor patch would cause that
> flickering. Are you using the latest amd-staging-drm-next? Do you have
> this patch in your local branch:
>
>  drm/amd/display: Reject non-zero src_y and src_x for video planes
>
> Thanks
>
> --
> Rodrigo Siqueira
> https://siqueira.tech
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-04-14  0:06 [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay Rodrigo Siqueira
  2021-04-14 13:29 ` Harry Wentland
  2021-05-10  2:20 ` youling257
@ 2021-08-18 10:48 ` Simon Ser
  2021-08-18 13:18   ` Rodrigo Siqueira
  2 siblings, 1 reply; 14+ messages in thread
From: Simon Ser @ 2021-08-18 10:48 UTC (permalink / raw)
  To: Rodrigo Siqueira
  Cc: amd-gfx, Sean Paul, Hersen Wu, Harry Wentland,
	Nicholas Kazlauskas, Louis Li

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.

This patch makes the overlay plane very useless for me, because the primary
plane is always under the overlay plane.

> 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?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-18 10:48 ` Simon Ser
@ 2021-08-18 13:18   ` Rodrigo Siqueira
  2021-08-24 13:59     ` Simon Ser
  0 siblings, 1 reply; 14+ messages in thread
From: Rodrigo Siqueira @ 2021-08-18 13:18 UTC (permalink / raw)
  To: Simon Ser
  Cc: amd-gfx, Sean Paul, Hersen Wu, Harry Wentland,
	Nicholas Kazlauskas, Louis Li

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-18 13:18   ` Rodrigo Siqueira
@ 2021-08-24 13:59     ` Simon Ser
  2021-08-24 14:56       ` Kazlauskas, Nicholas
  0 siblings, 1 reply; 14+ messages in thread
From: Simon Ser @ 2021-08-24 13:59 UTC (permalink / raw)
  To: Rodrigo Siqueira
  Cc: amd-gfx, Sean Paul, Hersen Wu, Harry Wentland,
	Nicholas Kazlauskas, Louis Li

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@amd.com> 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).

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://github.com/Plagman/gamescope
[2]: https://github.com/emersion/libliftoff

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-24 13:59     ` Simon Ser
@ 2021-08-24 14:56       ` Kazlauskas, Nicholas
  2021-08-24 16:48         ` Harry Wentland
  2021-08-27 13:47         ` Simon Ser
  0 siblings, 2 replies; 14+ messages in thread
From: Kazlauskas, Nicholas @ 2021-08-24 14:56 UTC (permalink / raw)
  To: Simon Ser, Rodrigo Siqueira
  Cc: amd-gfx, Sean Paul, Hersen Wu, Harry Wentland, Louis Li

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@amd.com> 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&amp;data=04%7C01%7CNicholas.Kazlauskas%40amd.com%7C0a5e1d2ce0874a87929e08d96707743a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637654104020179511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=PCliYWadIaVDDnEQUOONNo%2FmC2ieIMjUw9Zr4XP3XDM%3D&amp;reserved=0
> [2]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femersion%2Flibliftoff&amp;data=04%7C01%7CNicholas.Kazlauskas%40amd.com%7C0a5e1d2ce0874a87929e08d96707743a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637654104020179511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=q4NCvqFpwdSXVnBcBSdxCYII44ekOiQBWTe9SUDhFUo%3D&amp;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.
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-24 14:56       ` Kazlauskas, Nicholas
@ 2021-08-24 16:48         ` Harry Wentland
  2021-08-27 13:53           ` Simon Ser
  2021-08-27 13:47         ` Simon Ser
  1 sibling, 1 reply; 14+ messages in thread
From: Harry Wentland @ 2021-08-24 16:48 UTC (permalink / raw)
  To: Kazlauskas, Nicholas, Simon Ser, Rodrigo Siqueira
  Cc: amd-gfx, Sean Paul, Hersen Wu, Louis Li



On 2021-08-24 10:56 a.m., Kazlauskas, Nicholas wrote:
> 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@amd.com> 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.
> 

To elaborate on this a bit more, each HW plane's scanout engine
has the ability to scan out a cursor, in addition to the plane's
framebuffer. This cursor is drawn onto the plane at the scanout
phase. Any further scaling, color processing, or other operation
on the pipe will equally apply to the cursor as to the framebuffer
itself.

Our driver will look at the cursor position and place the cursor
with the topmost HW plane at that position.

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

If I understood Simon right the primary plane (bottom-most,
game plane) might not cover the entire screen, which is fine.

Is the Steam overlay always the size of the crtc, or does it
match the size of the game plane, or is it unrelated to either?

If the overlay is covering the entire screen and always active
you should be good. If the overlay appears and disappears the
cursor drawing would switch between the overlay and the game
plane.

> 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://github.com/Plagman/gamescope>>> [2]: https://github.com/emersion/libliftoff>>>
>>>>> 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?
>>

MMHUBBUB > DCHUBBUB > HUBP (for each pipe)

MMHUBBUB is irrelevant if DWB (display writeback) is not used. DWB is not
enabled in the driver.

DCHUBBUB is the overall scanout engine for all DC pipes and includes a
HUBP per pipe.

HUBP will have requestors for the primary framebuffer, DCC meta, dynamic
metadata (for things like Dolby HDR, though it's not fully implemented),
and cursor data.

Harry

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-24 14:56       ` Kazlauskas, Nicholas
  2021-08-24 16:48         ` Harry Wentland
@ 2021-08-27 13:47         ` Simon Ser
  1 sibling, 0 replies; 14+ messages in thread
From: Simon Ser @ 2021-08-27 13:47 UTC (permalink / raw)
  To: Kazlauskas, Nicholas
  Cc: Rodrigo Siqueira, amd-gfx, Sean Paul, Hersen Wu, Harry Wentland,
	Louis Li

Hi Nicholas!

On Tuesday, August 24th, 2021 at 16:56, Kazlauskas, Nicholas <nicholas.kazlauskas@amd.com> wrote:

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

Ah, I see. So the reason why we need to draw the cursor twice is to
accomodate for the case where it's visible on both the primary and
overlay planes, e.g.

┌────────────────────────────┐
│Primary                     │
│                            │
│                            │
│        ┌───────┐           │
│        │Cursor │           │
│        │       │           │
│        │   ┌───┼────────┐  │
│        └───┼───┘        │  │
│            │            │  │
│            │            │  │
│            │     Overlay│  │
│            └────────────┘  │
│                            │
└────────────────────────────┘

Is that right?

In the case where the cursor only intersects a single plane (either primary
or overlay) we need to draw it once only.

Since some KMS user-space (ChromeOS) uses the non-atomic cursor with the rest
of the atomic API, we need to always ensure that the cursor can be enabled at
any time, even if it's currently disabled.

> 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

(1) and (2) are correct, but (3) is not. My overlay plane isn't scaled, but my
primary plane may be. That doesn't change the outcome: the unscaled cursor can
be painted onto the overlay pipe, but not onto the primary pipe.

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

KMS has a standard "zpos" property [1], which may be mutable. So we could in
theory set an immutable "zpos" for the primary plane and overlay plane, and
allow user-space to change the "zpos" of the cursor plane to move it
in-between.

But for my use-case, I need the cursor plane to be painted on top of the
overlay, so it'd only be useful when the cursor doesn't intersect the overlay.

[1]: https://drmdb.emersion.fr/properties/4008636142/zpos

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

My use-case actually falls under both (1) and (2). We want to leave as much
bandwidth as possible for the game to use. We want to save power because we're
running on battery.

We don't _require_ KMS planes to run, we have a fallback composition path which
uses the compute queue. But we want to do as much as possible to use KMS planes.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-24 16:48         ` Harry Wentland
@ 2021-08-27 13:53           ` Simon Ser
  2021-08-27 14:04             ` Harry Wentland
  0 siblings, 1 reply; 14+ messages in thread
From: Simon Ser @ 2021-08-27 13:53 UTC (permalink / raw)
  To: Harry Wentland
  Cc: Kazlauskas, Nicholas, Rodrigo Siqueira, amd-gfx, Sean Paul,
	Hersen Wu, Louis Li

On Tuesday, August 24th, 2021 at 18:48, Harry Wentland <harry.wentland@amd.com> wrote:

> To elaborate on this a bit more, each HW plane's scanout engine
> has the ability to scan out a cursor, in addition to the plane's
> framebuffer. This cursor is drawn onto the plane at the scanout
> phase. Any further scaling, color processing, or other operation
> on the pipe will equally apply to the cursor as to the framebuffer
> itself.
>
> Our driver will look at the cursor position and place the cursor
> with the topmost HW plane at that position.

Ah. I may have missed something in my previous email then. With the
scenario I've described:

┌────────────────────────────┐
│Primary                     │
│                            │
│                            │
│        ┌───────┐           │
│        │Cursor │           │
│        │       │           │
│        │   ┌───┼────────┐  │
│        └───┼───┘        │  │
│            │            │  │
│            │            │  │
│            │     Overlay│  │
│            └────────────┘  │
│                            │
└────────────────────────────┘

Is it possible to draw the cursor only on the overlay pipe (not on the primary
pipe), even though the overlay pipe doesn't cover the whole CRTC?

Or will the overlay pipe crop the cursor image?

> If I understood Simon right the primary plane (bottom-most,
> game plane) might not cover the entire screen, which is fine.

Yes.

> Is the Steam overlay always the size of the crtc, or does it
> match the size of the game plane, or is it unrelated to either?

The overlay may not cover the whole CRTC. The usual case is some kind of
notification bubble showing in a corner. See the drawing above.

> >>>>> 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?
>
> MMHUBBUB > DCHUBBUB > HUBP (for each pipe)
>
> MMHUBBUB is irrelevant if DWB (display writeback) is not used. DWB is not
> enabled in the driver.
>
> DCHUBBUB is the overall scanout engine for all DC pipes and includes a
> HUBP per pipe.
>
> HUBP will have requestors for the primary framebuffer, DCC meta, dynamic
> metadata (for things like Dolby HDR, though it's not fully implemented),
> and cursor data.

I see. Thanks!

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-27 13:53           ` Simon Ser
@ 2021-08-27 14:04             ` Harry Wentland
  2021-08-27 14:12               ` Simon Ser
  0 siblings, 1 reply; 14+ messages in thread
From: Harry Wentland @ 2021-08-27 14:04 UTC (permalink / raw)
  To: Simon Ser
  Cc: Kazlauskas, Nicholas, Rodrigo Siqueira, amd-gfx, Sean Paul,
	Hersen Wu, Louis Li



On 2021-08-27 9:53 a.m., Simon Ser wrote:
> On Tuesday, August 24th, 2021 at 18:48, Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> To elaborate on this a bit more, each HW plane's scanout engine
>> has the ability to scan out a cursor, in addition to the plane's
>> framebuffer. This cursor is drawn onto the plane at the scanout
>> phase. Any further scaling, color processing, or other operation
>> on the pipe will equally apply to the cursor as to the framebuffer
>> itself.
>>
>> Our driver will look at the cursor position and place the cursor
>> with the topmost HW plane at that position.
> 
> Ah. I may have missed something in my previous email then. With the
> scenario I've described:
> 
> ┌────────────────────────────┐
> │Primary                     │
> │                            │
> │                            │
> │        ┌───────┐           │
> │        │Cursor │           │
> │        │       │           │
> │        │   ┌───┼────────┐  │
> │        └───┼───┘        │  │
> │            │            │  │
> │            │            │  │
> │            │     Overlay│  │
> │            └────────────┘  │
> │                            │
> └────────────────────────────┘
> 

Nice diagram.

> Is it possible to draw the cursor only on the overlay pipe (not on the primary
> pipe), even though the overlay pipe doesn't cover the whole CRTC?
> 
> Or will the overlay pipe crop the cursor image?
> 

It will be cropped to the overlay rectangle.

If you can allocate your overlay such that its destination rectangle
always spans the entire CRTC you'd have no cursor issues. Unfortunately
that means that you would use more memory bandwidth since you're
scanning out an overlay that's larger than you really need.

Harry

>> If I understood Simon right the primary plane (bottom-most,
>> game plane) might not cover the entire screen, which is fine.
> 
> Yes.
> 
>> Is the Steam overlay always the size of the crtc, or does it
>> match the size of the game plane, or is it unrelated to either?
> 
> The overlay may not cover the whole CRTC. The usual case is some kind of
> notification bubble showing in a corner. See the drawing above.
> 
>>>>>>> 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?
>>
>> MMHUBBUB > DCHUBBUB > HUBP (for each pipe)
>>
>> MMHUBBUB is irrelevant if DWB (display writeback) is not used. DWB is not
>> enabled in the driver.
>>
>> DCHUBBUB is the overall scanout engine for all DC pipes and includes a
>> HUBP per pipe.
>>
>> HUBP will have requestors for the primary framebuffer, DCC meta, dynamic
>> metadata (for things like Dolby HDR, though it's not fully implemented),
>> and cursor data.
> 
> I see. Thanks!
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay
  2021-08-27 14:04             ` Harry Wentland
@ 2021-08-27 14:12               ` Simon Ser
  0 siblings, 0 replies; 14+ messages in thread
From: Simon Ser @ 2021-08-27 14:12 UTC (permalink / raw)
  To: Harry Wentland
  Cc: Kazlauskas, Nicholas, Rodrigo Siqueira, amd-gfx, Sean Paul,
	Hersen Wu, Louis Li

On Friday, August 27th, 2021 at 16:04, Harry Wentland <harry.wentland@amd.com> wrote:

> > Is it possible to draw the cursor only on the overlay pipe (not on the primary
> > pipe), even though the overlay pipe doesn't cover the whole CRTC?
> >
> > Or will the overlay pipe crop the cursor image?
> >
>
> It will be cropped to the overlay rectangle.
>
> If you can allocate your overlay such that its destination rectangle
> always spans the entire CRTC you'd have no cursor issues. Unfortunately
> that means that you would use more memory bandwidth since you're
> scanning out an overlay that's larger than you really need.

Hm, yeah, unfortunately the buffers come from an X11 client, so it's
exactly the size of the visible area, I can't easily draw transparent
areas around it.

Thanks for all of the details, I'll think about all of this for a
while and try to come up with a plan.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-08-27 14:12 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-14  0:06 [PATCH v2] drm/amd/display: Fix two cursor duplication when using overlay Rodrigo Siqueira
2021-04-14 13:29 ` Harry Wentland
2021-05-10  2:20 ` youling257
2021-05-11  0:37   ` Rodrigo Siqueira
2021-05-11  1:47     ` youling 257
2021-08-18 10:48 ` Simon Ser
2021-08-18 13:18   ` Rodrigo Siqueira
2021-08-24 13:59     ` Simon Ser
2021-08-24 14:56       ` Kazlauskas, Nicholas
2021-08-24 16:48         ` Harry Wentland
2021-08-27 13:53           ` Simon Ser
2021-08-27 14:04             ` Harry Wentland
2021-08-27 14:12               ` Simon Ser
2021-08-27 13:47         ` Simon Ser

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.