[PATCH mesa v4] wayland: Add support for eglSwapInterval

[Tomeu Vizoso]

On 1 November 2013 02:35, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Thu, Oct 31, 2013 at 4:59 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>>
>> 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.
>
>
> This is a non-issue with the GL renderer.  It makes the tacit assumption
> that, upon return from eglSwapBuffers, it can safely release any buffers.
> It is assumed that the underlying GL stack will either pass fences or block
> to make this possible.  I'm not 100% sure on the details; Daniel or Kristian
> could tell you much more.

Well, that's one more assumption that I don't know if Weston should be
making. Guess it depends on whether we want to make our reference
compositor work well only with stacks as sane as Mesa is, or if we
want to have it work well also with the crappy GL implementations that
all mobile hardware uses these days.

Regards,

Tomeu

> The result is that the buffer releases here always happen in correspondence
> to an attach or destroying a surface.  The only time we should get these
> crazy release times is when dealing with backends that are doing non-EGL
> things with the underlying graphics 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
>> >
>> >
>
>