On 31 October 2013 02:54, Jason Ekstrand <[email protected]> wrote: > On Wed, Oct 30, 2013 at 3:59 AM, Tomeu Vizoso <[email protected]> wrote: >> >> On 30 October 2013 09:44, Neil Roberts <[email protected]> wrote: >> > Tomeu Vizoso <[email protected]> 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?
Works for the rpi backend, but wonder if the gl renderer may need something similar when running on top of a mobile GL stack. > 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. Looks good to me. > 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). Nod. > 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. Thanks, Tomeu > --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 > > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
