On 28/10/2024 16:04, Leo Li wrote:
On 2024-10-25 22:01, Melissa Wen wrote:
On 25/10/2024 16:37, Zaeem Mohamed wrote:
[why]
Prevent index-out-of-bounds due to requiring cursor overlay when
plane_count is MAX_SURFACES.
Hi Zaeem,
Thanks for working on this fix.
[how]
Bounds check on plane_count when requiring overlay cursor.
I agree. Atomic check makes sense.
1) Since the native cursor mode was previously the unique mode
avaliable, I
wonder if the driver should fall to native cursor mode in favor of
the overlay
planes advertised. I.e. if driver says it supports two overlay planes
and
the userspace requested both, cursor overlay mode should not be
available or
should switch to native cursor mode, as before the introduction of
cursor
overlay mode.
Hey Melissa,
The overlay cursor implementation today should still do native cursor
in all
cases, except for when it is not possible: if there is a underlying
scaled or
YUV plane.
In such cases, we previously rejected the atomic commit, since the hw
won't be
able to produce the rendering intent. Now, we try to accommodate it by
using a
dedicated overlay plane. IOW, fallback to native here is equivalent to
an atomic
reject.
2) Then my second question: can we increase the number of surfaces to
4 first to
accommodate more than one active overlay plane with cursor overly
mode enabled.
If four is still possible, this increase can reduce the number of commit
failure scenarios and mitigate current userspace issues first. After
addressing
current array-out-of-bounds, follow-up patches can do the proper
changes and
checks.
My initial thought was to merge the proper fix first to address the
current
issues. But if increasing MAX_SURFACES->4 also helps, I don't have a
strong
opinion about it :)
I think Zaeem is working on MAX_SURFACES->4 as well, but there's some
detangling
work required in DC to accommodate another OS that dc supports. I have
a feeling
this fix may land earlier than the ->4 patch. (see my patch comments
below)
Hi Leo,
Thanks for explaining these issues.
I thought changing MAX_SURFACES -> 4 would be faster than reworking
atomic checks for properly handling active planes, but I understand your
approach now, since this change impacts other OSes.
BTW, I've been away for the last few weeks and may have missed some
updates. Any news on this?
Melissa
3) IMHO, the incoherence between MAX_SURFACE_NUM and MAX_SURFACE
should be
addressed before adding debugging points. For example, there are part
of the
DC code using MAX_SURFACE_NUM == MAX_PLANE == 6 to allocate
dc_surface_update
arrays, instead of using MAX_SURFACE value. You can find one of this
case here:
https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/
gpu/drm/amd/display/dc/core/dc.c#L4507
It doesn't make sense to me and it can contribute to an incomplete
solution.
Right, also see below
Also, please add the references of bugs reported in the amd tracker,
so far:
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3693
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3594
Co-developed-by: Melissa Wen <mwen@xxxxxxxxxx>
I don't think I contributed enough to your code to get any credits.
Thanks, but you can remove my co-dev-by :)
Best Regards,
Melissa
Signed-off-by: Zaeem Mohamed <zaeem.mohamed@xxxxxxx>
---
amdgpu_dm/amdgpu_dm.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/amdgpu_dm/amdgpu_dm.c b/amdgpu_dm/amdgpu_dm.c
index df83e7b42b..c2595efb74 100644
--- a/amdgpu_dm/amdgpu_dm.c
+++ b/amdgpu_dm/amdgpu_dm.c
@@ -11676,6 +11676,12 @@ static int amdgpu_dm_atomic_check(struct
drm_device *dev,
* need to be added for DC to not disable a plane by mistake
*/
if (dm_new_crtc_state->cursor_mode ==
DM_CURSOR_OVERLAY_MODE) {
+ if(dc->current_state->stream_status->plane_count >= MAX_SURFACES){
+ drm_dbg_driver(crtc->dev,
+ "Can't enable cursor plane with %d
planes\n", MAX_SURFACES);
+ ret = -EINVAL;
+ goto fail;
+ }
Hey Zaeem,
I took a tour through DC, and it seems to me that MAX_SURFACE_NUM can
be made
equal to MAX_SURFACES in all cases. I wonder, if we simply replace
MAX_SURFACE_NUM with MAX_SURFACES = 3, will we still need these
explicit fails?
FWICT, `dc_state_add_plane` should fail for us.
Thanks,
Leo
ret = drm_atomic_add_affected_planes(state, crtc);
if (ret)
goto fail;
@@ -11769,8 +11775,16 @@ static int amdgpu_dm_atomic_check(struct
drm_device *dev,
/* Overlay cusor not subject to native cursor restrictions */
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
- if (dm_new_crtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE)
+ if (dm_new_crtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE){
+ if(dc->current_state->stream_status->plane_count > MAX_SURFACES){
+ drm_dbg_driver(crtc->dev,
+ "Can't enable cursor plane with %d
planes\n", MAX_SURFACES);
+ ret = -EINVAL;
+ goto fail;
+ }
+
continue;
+ }
/* Check if rotation or scaling is enabled on DCN401 */
if ((drm_plane_mask(crtc->cursor) &
new_crtc_state->plane_mask) &&
