[PATCH mesa v4] wayland: Add support for eglSwapInterval
tomeu at tomeuvizoso.net
Thu Oct 31 10:59:22 CET 2013
On 31 October 2013 02:54, Jason Ekstrand <jason at jlekstrand.net> wrote:
> 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:
> 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).
> 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
>> > 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
More information about the wayland-devel