On Mon, Oct 16, 2023 at 10:00:51PM +0000, Simon Ser wrote: > On Monday, October 16th, 2023 at 17:10, Ville Syrjälä > <ville.syrj...@linux.intel.com> wrote: > > > On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote: > > > > > On Mon, 16 Oct 2023 15:42:16 +0200 > > > André Almeida andrealm...@igalia.com wrote: > > > > > > > Hi Pekka, > > > > > > > > On 10/16/23 14:18, Pekka Paalanen wrote: > > > > > > > > > On Mon, 16 Oct 2023 12:52:32 +0200 > > > > > André Almeida andrealm...@igalia.com wrote: > > > > > > > > > > > Hi Michel, > > > > > > > > > > > > On 8/17/23 12:37, Michel Dänzer wrote: > > > > > > > > > > > > > On 8/15/23 20:57, André Almeida wrote: > > > > > > > > > > > > > > > From: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > > > > > > > > > Specify how the atomic state is maintained between userspace and > > > > > > > > kernel, plus the special case for async flips. > > > > > > > > > > > > > > > > Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > Signed-off-by: André Almeida andrealm...@igalia.com > > > > > > > > [...] > > > > > > > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is > > > > > > > > allowed to > > > > > > > > +effectively change only the FB_ID property on any planes. > > > > > > > > No-operation changes > > > > > > > > +are ignored as always. [...] > > > > > > > > During the hackfest in Brno, it was mentioned that a commit > > > > > > > > which re-sets the same FB_ID could actually have an effect with > > > > > > > > VRR: It could trigger scanout of the next frame before vertical > > > > > > > > blank has reached its maximum duration. Some kind of mechanism > > > > > > > > is required for this in order to allow user space to perform > > > > > > > > low frame rate compensation. > > > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a VRR > > > > > > monitor > > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > > Right, so it must have some effect. It cannot be simply ignored > > > > > > like in > > > > > > the proposed doc wording. Do we special-case re-setting the same > > > > > > FB_ID > > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > > There's an effect in the refresh rate, the image won't change but it > > > > > > will report that a flip had happened asynchronously so the reported > > > > > > framerate will be increased. Maybe an additional wording could be > > > > > > like: > > > > > > > > Flipping to the same FB_ID will result in a immediate flip as if it was > > > > changing to a different one, with no effect on the image but effecting > > > > the reported frame rate. > > > > > > Re-setting FB_ID to its current value is a special case regardless of > > > PAGE_FLIP_ASYNC, is it not? > > > > No. The rule has so far been that all side effects are observed > > even if you flip to the same fb. And that is one of my annoyances > > with this proposal. The rules will now be different for async flips > > vs. everything else. > > Well with the patches the async page-flip case is exactly the same as > the non-async page-flip case. In both cases, if a FB_ID is included in > an atomic commit then the side effects are triggered even if the property > value didn't change. The rules are the same for everything.
I see it only checking if FB_ID changes or not. If it doesn't change then the implication is that the side effects will in fact be skipped as not all planes may even support async flips. -- Ville Syrjälä Intel
