On Oct 30, 2013 3:59 AM, "Tomeu Vizoso" <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> wrote: > > On 30 October 2013 09:44, Neil Roberts <<a href="mailto:neil@linux.intel.com">neil@linux.intel.com</a>> wrote: > > Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> 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: > > <a href="https://github.com/tomeuv/userland/commit/a4a7cb233af5e5b167a1cb6f928b7a6381380a56#diff-b1115e30ce4f2940df2cd98a85009ccaR2339">https://github.com/tomeuv/userland/commit/a4a7cb233af5e5b167a1cb6f928b7a6381380a56#diff-b1115e30ce4f2940df2cd98a85009ccaR2339</a> > > 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