ubuntu-phone team mailing list archive

[Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx>]

>>It feels like we're misusing our egl implementation to deal with app
lifecycle.

Actually that's the thing. Ultimately, EGL implementations aren't ours,
they belong to the GPU vendors. The problem is the spec isn't strong
enough. For instance, where in the spec does it say eglSwapBuffers must
return in a "some amount of time"...in fact, by the strictest
interpretation if you fill the buffers and there is no vsync...it should
block until vsync returns (but alas this is exactly what Qt cannot handle).
And vendors have made varying choices anywhere from blocking to throwing
EGL_CONTEXT_LOST to promotion custom vendor extensions (or even this, see
this AMD specific implementation that actually just lets rendering continue
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/969860...its still
open because they say, its not a bug). But anyway, yes it is common EGL
implementations to block & potentially hide the power management events.
This is what is happening today on the desktop - blocking is actually
expected.

And actually, I'm starting to think, Mir may not be able to arbitrate.
Since toolkits are using EGL directly Mir can't do much to arbitrate. We
might actually be back to delivering a solution in the toolkit.


On Tue, Apr 1, 2014 at 4:16 AM, Michal Hruby <michal.hruby@xxxxxxxxxxxxx>wrote:

> On 31/03/14 14:24, Kevin Gunn wrote:
>
>> @Michal Hruby -  We are working on a solution that unblocks the GUI
>> thread's event handling & avoids the race (between eglswapbuffer & the side
>> channel expose event). However, we're not going to return true when that's
>> not the case, that would be naughty, what if that one frame was _the_ most
>> important frame?...in general we need to solve while staying within the egl
>> interface per spec. And I think we have a potential solution to chase...see
>> below
>>
>
> Right, that would workaround the issue in Qt, but do we know how for
> example SDL will deal with eglSwapBuffers blocking? I do not see in the
> spec any mention of indefinite blocking, and afaict it doesn't seem
> expected, afterall the spec does say that eglSwapBuffers implicitly
> performs glFlush which doesn't block. It feels like we're misusing our egl
> implementation to deal with app lifecycle.
>
> Also I didn't suggest to just ignore the frame and return true, as you
> mentioned it might be *the* frame which the user is most interested in, so
> it should be sent to the GPU memory.
>
>
>  For those not directly involved, "what is the current plan?" you ask?
>> We've reviewed the EGL specification and the most appropriate way forward
>> is to return EGL_FALSE  with the EGL error set to EGL_CONTEXT_LOST since
>> this is a power management event. This approach will unblock the GUI
>> thread, however does have a cost that the EGL client has to account for by
>> destroying/creating EGL context (thankfully surfaces are treated
>> seperately, not part of the egl context). It seems to me there is room for
>> another egl error state that doesn't involve contexts, like EGL_NO_DISPLAY,
>> but alas we have to work within the API. At the moment this means reworking
>> Mir's current handling of the power management event as well as a matching
>> patch to Qt to handle the error on the client side.
>>
>
> I also don't think EGL_CONTEXT_LOST is a good idea - it seems to be used
> for cases when GPU wakes up after deep sleep and the (GL) state cannot be
> restored, so everything needs to be rebuilt from scratch.
>
> Michal
>