Overlay issues

[Cornij, Nikola]

[AMD Public Use]

Hi Simon,

Another interim update: so far to me it looks like this is an issue if there's fewer than 24 pixels left on the screen when moving the FB outside of the left edge (e.g. with 300x300 FB size, it repros with X = -280). When this happens, what looks like a boundary condition in our driver is hit and destination rectangle update is skipped.

I need to do some more digging to fully understand why is this condition in place and how to avoid it.

Regards,

Nikola

-----Original Message-----
From: Cornij, Nikola 
Sent: Tuesday, December 15, 2020 11:37 AM
To: Simon Ser <contact at emersion.fr>
Cc: Alex Deucher <alexdeucher at gmail.com>; Kazlauskas, Nicholas <Nicholas.Kazlauskas at amd.com>; Deucher, Alexander <Alexander.Deucher at amd.com>; Wentland, Harry <Harry.Wentland at amd.com>; amd-gfx list <amd-gfx at lists.freedesktop.org>
Subject: RE: Overlay issues

[AMD Public Use]

Yeah, but... it works with bigger FBs (300x300). So looks like some clipping somewhere works OK until a corner-case is reached.

-----Original Message-----
From: Simon Ser <contact at emersion.fr>
Sent: Tuesday, December 15, 2020 2:58 AM
To: Cornij, Nikola <Nikola.Cornij at amd.com>
Cc: Alex Deucher <alexdeucher at gmail.com>; Kazlauskas, Nicholas <Nicholas.Kazlauskas at amd.com>; Deucher, Alexander <Alexander.Deucher at amd.com>; Wentland, Harry <Harry.Wentland at amd.com>; amd-gfx list <amd-gfx at lists.freedesktop.org>
Subject: Re: Overlay issues

On Tuesday, December 15th, 2020 at 5:09 AM, Cornij, Nikola <Nikola.Cornij at amd.com> wrote:

> [AMD Public Use]
>
> Hi Simon,
>
> Just to keep you updated, I've reproduced issue '[1] - Overlay plane:
> position not updated when CRTC_X is negative' on Ubuntu using IGT.
> Seems to happen only with smaller FBs (so far tried 24x24 and I can 
> repro, but 300x300 is OK).
>
> I'll look into fixing this.

Thanks for the update and for looking into this! Let me know if I can help with anything. Nicholas replied on the issue tracker that overlay planes couldn't have negative positions, so I was thinking of having a look at the SRC_Y handling (see if we can do the same for SRC_X), experimenting with FB sizes and SRC_W/H to figure out what's the overlay max size still triggering the bug. If we really can't emulate neg SRC_X we should fail atomic commits with negative SRC_X by returning EINVAL (so that user-space can fall back to not using the plane in this case).

Simon