[PATCH mesa v4] wayland: Add support for eglSwapInterval

[Tomeu Vizoso]

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:
>>
>>
>> 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
>
>