[Mesa-dev] [PATCH] Revert "wayland: Block for the frame callback in get_back_bo not dri2_swap_buffers"

Jonas Ådahl jadahl at gmail.com
Thu Nov 10 06:08:56 UTC 2016


On Mon, Oct 24, 2016 at 08:42:59PM +0100, Daniel Stone wrote:
> This reverts commit 25cc889004aad6d1cab9edd76db898658e347b97, though
> since the code has changed, it was applied manually.
> 
> The intent of moving blocking from SwapBuffers to get_back_bo, was to
> avoid unnecessary triple-buffering by ensuring that the compositor had
> fully processed the previous frame before we started rendering. This
> means that the only time we would have to resort to triple-buffering
> would be when the buffer is directly scanned out, thus saving an extra
> buffer for composition anyway.
> 
> The 'repaint window' changes introduced in Weston since then, however,
> have narrowed the window of time between the frame event being sent and
> the repaint loop needing to conclude, to 7ms by default, in order to
> reduce latency. This means however that blocking in get_back_bo gives a
> maximum of 7ms for the entire GL submission to begin and complete.
> 
> Not only this, but if a client is using buffer_age to avoid full
> repaints, the buffer-age request will stall in get_back_bo until the
> frame callback completes, meaning that the client cannot even calculate
> the repaint area before the 7ms window.
> 
> The combination of the two meant that WebKit-GTK+ was failing to
> achieve full framerate on a Minnowboard, due to spending a great deal of
> its time attempting to query the age of the next buffer before redraw.
> 
> Revert to the previous behaviour of allowing rendering to begin but
> delaying SwapBuffers, unless and until we can find a more gentle
> behaviour.
> 
> Signed-off-by: Daniel Stone <daniels at collabora.com>
> Cc: Neil Roberts <neil at linux.intel.com>
> Cc: Kristian Høgsberg <krh at bitplanet.net>

The explanations sounds sane to me, and even though it's a revert, I
looked at the patch and it seems correct, so this is

Reviewed-by: Jonas Ådahl <jadahl at gmail.com>

I suspect we can't avoid tripple buffering if the client asks for
information about the next buffer early enough, since mesa won't have a
clue what the future will be regarding any buffer being released or not
before the frame callback.

Or maybe we could possibly fake the buffer age, pretending the buffer is
a fresh one if the client queries "too early", but then eventually
re-use the buffer had it been released before the frame callback. We'd
at least avoid the extra buffer being allocated, while instead only
wasting resources painting the whole buffer which we would do anyway if
we allocated the third buffer.


Jonas

> ---
>  src/egl/drivers/dri2/platform_wayland.c | 30 ++++++++++++++----------------
>  1 file changed, 14 insertions(+), 16 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_wayland.c b/src/egl/drivers/dri2/platform_wayland.c
> index ccab192..ba74d33 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -324,14 +324,8 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
>        return -1;
>     }
>  
> -   /* We always want to throttle to some event (either a frame callback or
> -    * a sync request) after the commit so that we can be sure the
> -    * compositor has had a chance to handle it and send us a release event
> -    * before we look for a free buffer */
> -   while (dri2_surf->throttle_callback != NULL)
> -      if (wl_display_dispatch_queue(dri2_dpy->wl_dpy,
> -                                    dri2_dpy->wl_queue) == -1)
> -         return -1;
> +   /* There might be a buffer release already queued that wasn't processed */
> +   wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
>  
>     if (dri2_surf->back == NULL) {
>        for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> @@ -705,6 +699,11 @@ dri2_wl_swap_buffers_with_damage(_EGLDriver *drv,
>     struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
>     int i;
>  
> +   while (dri2_surf->throttle_callback != NULL)
> +      if (wl_display_dispatch_queue(dri2_dpy->wl_dpy,
> +                                    dri2_dpy->wl_queue) == -1)
> +         return -1;
> +
>     for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++)
>        if (dri2_surf->color_buffers[i].age > 0)
>           dri2_surf->color_buffers[i].age++;
> @@ -1464,14 +1463,8 @@ swrast_update_buffers(struct dri2_egl_surface *dri2_surf)
>  
>     /* find back buffer */
>  
> -   /* We always want to throttle to some event (either a frame callback or
> -    * a sync request) after the commit so that we can be sure the
> -    * compositor has had a chance to handle it and send us a release event
> -    * before we look for a free buffer */
> -   while (dri2_surf->throttle_callback != NULL)
> -      if (wl_display_dispatch_queue(dri2_dpy->wl_dpy,
> -                                    dri2_dpy->wl_queue) == -1)
> -         return -1;
> +   /* There might be a buffer release already queued that wasn't processed */
> +   wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
>  
>     /* try get free buffer already created */
>     for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> @@ -1552,6 +1545,11 @@ dri2_wl_swrast_commit_backbuffer(struct dri2_egl_surface *dri2_surf)
>  {
>     struct dri2_egl_display *dri2_dpy = dri2_egl_display(dri2_surf->base.Resource.Display);
>  
> +   while (dri2_surf->throttle_callback != NULL)
> +      if (wl_display_dispatch_queue(dri2_dpy->wl_dpy,
> +                                    dri2_dpy->wl_queue) == -1)
> +         return -1;
> +
>     if (dri2_surf->base.SwapInterval > 0) {
>        dri2_surf->throttle_callback =
>           wl_surface_frame(dri2_surf->wl_win->surface);
> -- 
> 2.9.3
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list