[PATCH xserver] glamor: Limit outstanding drawing queue with glClientWaitSync

[Michel Dänzer]

On 05.06.2016 12:29, Keith Packard wrote:
> The X server doesn't (generally) use SwapBuffers, so we need some
> other mechanism to avoid flooding the device with queued rendering
> requests when the server is busy.

I wrote an eerily similar patch a while ago, but the problem turned out
to be in the GL or kernel driver. Are you sure that's not the case for you?


> diff --git a/glamor/glamor.c b/glamor/glamor.c
> index 62b5c3a..226a10e 100644
> --- a/glamor/glamor.c
> +++ b/glamor/glamor.c
> @@ -271,6 +271,13 @@ _glamor_block_handler(ScreenPtr screen, void *timeout, void *readmask)
>  
>      glamor_make_current(glamor_priv);
>      glFlush();
> +    if (glamor_priv->sync[glamor_priv->sync_id]) {
> +        glClientWaitSync(glamor_priv->sync[glamor_priv->sync_id],
> +                         0,
> +                         GL_TIMEOUT_IGNORED);
> +    }
> +    glamor_priv->sync[glamor_priv->sync_id] = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
> +    glamor_priv->sync_id = (glamor_priv->sync_id + 1) % ARRAY_SIZE(glamor_priv->sync);
>  }

Should glamor_block_handler get the same treatment?


One potential issue (at least with glamor_block_handler) is that we can
end up calling glFlush quite often without any preceding drawing
commands. If that causes too much overhead, we may need to start keeping
track of whether we've submitted any OpenGL drawing commands, and
short-circuit (_)glamor_block_handler if we haven't.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer