[PATCH mesa v4] wayland: Add support for eglSwapInterval

[Jason Ekstrand]

On Wed, Oct 30, 2013 at 3:59 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:

> On 30 October 2013 09:44, Neil Roberts <neil at linux.intel.com> wrote:
> > Tomeu Vizoso <tomeu at tomeuvizoso.net> writes:
> >
> >> What I fail to see is why a single sync should be enough, as we don't
> >> know when the GPU will signal that it's done with the buffer that we
> >> are waiting to be released.
> >
> > You are right that we don't know when the GPU will release the buffer.
> > However we are not waiting for that.
>
> Oh, sure, was saying that in the context of the RPi, there we don't
> want the client to have to create more than 2 buffers per surface.
>
> In that EGL, SwapBuffers blocks waiting for the GPU to signal that
> it's done rendering with the buffer that is to become the back buffer.
> With your patch for not queueing if no frame callbacks are installed,
> we don't need to send any sync requests. Without it, we would need to
> keep syncing until we get the release.
>
> I know that you have dealt with it in Mesa already but wanted to reply
> to Jason's comment, sorry for hijacking your thread :)
>
> This is the relevant part of the code:
>
>
> https://github.com/tomeuv/userland/commit/a4a7cb233af5e5b167a1cb6f928b7a6381380a56#diff-b1115e30ce4f2940df2cd98a85009ccaR2339
>

Ok, you are in the crazy edge-case that I feared.  However, I still don't
think we need some buffer release protocol.  Since the buffer releasing
issues are graphics-stack-dependent, shouldn't we push that off to the
graphics-stack-dependent backends?  I've attached a patch that provides a
hook to let a component specify how it wants a given buffer to be released
when it deferences it.  Since RPi always wants its buffers back ASAP, the
compositor can simply always post the event instead of queue.  I'm going to
reply to this e-mail with a patch that does just that.

If you're concerned with the case where the buffer release would otherwise
get flushed by a frame but no frame events (or other events for that
matter) are coming to the client, then I would consider that a weston bug.
We should really find a way to ensure that buffers do get flushed
eventually so clients don't starve(maybe once per frame).

I'm open to the possibility that this is a really bad idea.  However, it
seems more sane than an extra request or extra EGL extensions.
--Jason Ekstrand


>
> Regards,
>
> Tomeu
>
> > We are assuming that the GPU is
> > only going to hold on to at most 2 buffers. In the DRM / Mesa case it
> > needs to hold on to these because one will be used for scanout and one
> > will be queued for the page flip. If we attach a third buffer then it
> > will be held by the compositor as a queue for the next flip. We are
> > assuming it won't have given this buffer to the GPU. Therefore if we
> > attach a fourth buffer it is easy for the compositor to immediately
> > release its lock on the third buffer and replace it with the fourth. So
> > we can assume that the fourth attach will always generate an immediate
> > release event. Sending a sync request will ensure that we always get
> > this release event. So if we have four buffer slots we can assume that
> > one of the attaches will always generate an immediate release event.
> >
> > In the non-fullscreen case where we don't really need to wait for the
> > GPU, we only need 2 slots because the compositor will only lock one
> > buffer.
> >
> > Regards,
> > - Neil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131030/17ff7d31/attachment.html>