Process for implementing a double buffer on Wayland

[Pekka Paalanen]

On Thu, 26 Nov 2015 17:56:05 +0100
Fabien DESSENNE <fabien.dessenne at st.com> wrote:

> >  > Date: Thu, 26 Nov 2015 10:40:20 +0200
> >  > From: ppaalanen at gmail.com
> >  >
> >  > On Wed, 25 Nov 2015 21:43:49 +0100
> >  > Hardening <rdp.effort at gmail.com> wrote:
> >  >  

> >  > > I may be wrong, but there's no guaranty that the compositor sends
> >  > > wl_buffer.release event on buffer A. I think I have experimented this
> >  > > when the renderer in weston is the pixman renderer.
> >  > > IIRC I have been told on IRC that the compositor decides when the  
> > buffer  
> >  > > is not used, so you may not receive the release message immediately. I
> >  > > have hit that kind of bug when coding libUWAC.  
> >  >
> >  > You are definitely right if you don't commit buffer B.
> >  >
> >  > When you have committed buffer B, the compositor eventually will
> >  > release buffer A if it had not already, but there are some exceptions
> >  > too. One is on certain circumstances when using a sub-surface.
> >  >
> >  >
> >  > Mike,
> >  >
> >  > essentially one should decouple the buffer management from the repaint
> >  > cycle, like simple-shm.c does.
> >  >
> >  > The reply to wl_surface.frame tells you when it is appropriate to draw
> >  > a new frame after the previous one. Whenever you decide to draw a new
> >  > frame, check your buffer pool for available buffers (I mean a collection
> >  > of wl_buffers, not wl_shm_pool). If none are available, create a new
> >  > buffer to draw into, or in some cases you can wait for a buffer become
> >  > available again.
> >  >
> >  > When a buffer is created, it is naturally available to be drawn into.
> >  > Using wl_surface.attach and wl_surface.commit with the buffer makes it
> >  > reserved by the server, unavailable, until you receive a
> >  > wl_buffer.release event making it available again.
> >  >
> >  > When you follow these rules, you get adaptive buffering. You'll only
> >  > ever use just one buffer if possible, and use more if necessary to
> >  > achieve glitch-free output. Double-buffering in the client is not
> >  > always mandatory to achieve the effect of double-buffering, because the
> >  > server might be buffering too.
> >  >
> >  >
> >  > Thanks,
> >  > pq  
> >
> > Hi Pekka,
> >
> > Thanks for your input.  If I understand you correctly, you recommend
> > creating buffers dynamically in the event there aren't any available to
> > use in the shm pool.  I can see how that would help the frame rate.
> >
> > Thanks again for your comments guys.  I have the info I need.
> > Best regards
> > Mike  
> 
> Hi all,
> 
> I have also experienced this : the replaced buffer (A) is not 
> immediately released after the new buffer (B) is on display.

This is correct, depending on what you mean by "immediately", what type
of buffers you submitted, which renderer is used, and which backend is
used.

Also in Weston's case, wl_buffer.release events are not flushed out
automatically, but by some other event. This is controversial behaviour
which has been discussed a few times already, but so far stayed as is.

> I guess that the behavior depends on both the backend (eg DRM) and the 
> renderer (GL, pixman)
> In compositor-drm.c you can read this comment
>   * Also, keep a reference when using the pixman renderer.
>   * That makes it possible to do a seamless switch to the GL
>   * renderer and since the pixman renderer keeps a reference
>   * to the buffer anyway, there is no side effects.
> I am not sure, but this may be be a reason why a buffer is kept longer 
> than expected.

That comment should be completely correct: it should not make a
difference. With the Pixman renderer, only shm buffers are supported.
The Pixman renderer textures directly from the client's buffer, so it
must keep a reference. It makes no difference if the backend also takes
another reference. Shm buffers cannot be scanned out directly, so the
backend's reference should not delay the release when a new buffer is
committed.

> I had deadlock issues when using a 2 buffer pool (A, B).
> Moving to 3 (A, B C) solved the issue : after having pushed C, A is 
> released.

That again depends on several things:
- all buffer's types
- compositor's renderer
- compositor's backend (direct scanout)
- use of sub-surfaces in certain cases
- the delayed flushing of wl_buffer.release event in Weston
- does the client wait for frame callbacks or not before redrawing

> Running with 3 buffers is quite usual, I used it within an 'Android 
> HWComposer' project. The drawback is that you need some extra memory.

FWIW, Weston has a test which ensures that two buffers are enough for
the usual GL application case:
http://cgit.freedesktop.org/wayland/weston/tree/tests/buffer-count-test.c


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151127/718c5b87/attachment.sig>