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

Reply via email to