[PATCH mesa v4] wayland: Add support for eglSwapInterval

[Jason Ekstrand]

On Oct 30, 2013 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 think I see what you mean (haven't looked at the code yet though).  I'll
try and look at it tonight and maybe send out a patch to better demonstrate
what I'm thinking.
--Jason

> 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
>
> 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/fc2b8dbe/attachment-0001.html>