[PATCH mesa v4] wayland: Add support for eglSwapInterval

[Neil Roberts]

Just to be clear, I think the discussion about whether to queue release
events is no longer related to implementing eglSwapInterval(0) so it
shouldn't hold up the patch. As far as I understand if you want to
render at the maximum rate you need four buffer slots and being able to
disable the queuing mechanism isn't going to affect that. If the device
can't handle four buffers then applications simply can't use
eglSwapInterval(0) when rendering fullscreen. Increasing the number of
buffer slots doesn't affect the number of buffers that will actually be
used in the normal case of non-fullscreen applications which should
continue to just use two buffers.

I agree that we should probably do something about the event queuing
anyway. Currently if a fullscreen application goes idle after drawing
its last frame it will never get the release event for the buffer
because nothing will flush the queue. This would deny the application a
chance to free the buffer. However I don't know if having a mechanism to
explicitly disable the queuing is the right answer in this case and it
might make more sense for the compositor to ensure that it always
eventually flushes the queue instead of keeping it indefinitely. My
previous patch to disable the queuing when there are no frame callbacks
could still be a good way to achieve that.

Regards,
- Neil

Daniel Stone <daniel at fooishbar.org> writes:

> Hi,
>
> On 28 October 2013 11:19, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>> I'm still concerned about platforms with high resolution displays but
>> relatively little memory.
>>
>> I'm thinking of the RPi, but my understanding is that Android goes to
>> great lengths to reduce the number of buffers that clients have to
>> keep, because of general memory consumption, but also because scanout
>> buffers are precious when you try to get the smoothest of the
>> experiences that is possible on these phones.
>>
>> I think we should still consider adding a flag through which the
>> client can tell the compositor to send the release events immediately
>> instead of queuing them.
>>
>> Otherwise, the compositor is making a very broad assumption on the
>> client's inner workings if it assumes that release events can be
>> queued without a negative impact on performance.
>
> Yeah, I agree.  Maybe it could be an eglQueryWaylandBufferWL parameter
> for EGL buffers?
>
> Ramping up the number of buffers used just isn't an option on
> platforms with not massive amounts of memory, but enormous displays.
> It also kinda cancels out some of the buffer_age benefits too.  I take
> the point that this is solving a different symptom of the same
> problem, but I'm worried that it'll paper over the problem and we'll
> end up just shipping patched versions (or fielding bug reports) on ARM
> indefinitely.
>
> Cheers,
> Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel