Should Weston wait for client buffers to finish rendering?

[Pekka Paalanen]

On Thu, 24 Jan 2019 11:47:30 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed, 23 Jan 2019 18:43:52 +0000
> "Singh, Satyeshwar" <satyeshwar.singh at intel.com> wrote:
> 
> > Imagine a benchmark case where the client renders for example 800
> > frames and attaches their buffer ids to a surface, the compositor
> > uses the last one that came in before its repaint cycle started for
> > composition and display on the screen. This buffer may not have been
> > rendered by the GPU yet because it is working on previous buffers.
> > However, it may not finish before the next Vblank and if it doesn't
> > finish, then the compositor's scan out buffer also isn't going to be
> > displayed by the kernel driver. If we change the policy for the
> > compositor to always use the last finished buffer, then at least the
> > compositor's scan out buffer will be displayed for the next Vblank
> > even if it's not showing the last frame from the client. Thoughts?  
> 
> You are correct. This is an existing caveat.

> Solutions to these issue would be good to have, but the timings
> trade-off probably needs investigation and maybe some extensions here
> and there to reach an optimal solution.

Btw. just so it is clear: personally I would consider an application
that renders completely unthrottled and spams the compositor with
frames to be ill-behaving if not outright broken. Wayland has two
different mechanisms for throttling client drawing, the frame callback
maximising the available time to draw and presentation-time extension
to optimise latency to screen.

The major reasons to fortify a compositor by waiting and prioritisation
is to make the compositor more robust in the presence of either abusive
applications (the spamming) or slow applications (take a long time to
render a frame).


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190124/3a0ccd1d/attachment.sig>