ubuntu-phone team mailing list archive

[Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx>]

Couple of followup points.

We've engaged Khronos EGL WG on the topic, and its fair to describe the
power management definitions as crude as well as there seems to be an
unsettled debate on blocking/non-blocking. Suggestions from the EGL WG list
were mainly to define custom extensions, and there is some thought about
this going into the EGL2.0 spec (but consider that EGL1.5 just got
published...its going to be a while, not helpful here).

After some more discussion we've raised some potential issues with our
approach of using EGL_CONTEXT_LOST. First that we'd be enforcing behavior
on clients which after some googling reveal that many egl clients simply
don't even check the result, some that do just bail. Secondly, we'd have to
patch/convince Qt upstream (non-technical issue...but issue nonetheless).
Third the primary issue, we would still be stuck with exact same race
condition in the instance of an occluded window (e.g. buffers get
exhausted, but aren't being comsumed by the compositor....call blocks, app
can't get the Qt exposeEvent() & apps gui thread again can't service
events)....and in this instance, there really isn't a good error to use,
certainly not one that doesn't come with a cost.

We are going to prototype the use of always returning true. Now, this has a
downside in that some (me, b/c it feels naughty) believe there's an implied
result of your rendered data making it to the screen, which it obviously
doesn't in either the screen off or occluded case...if it was the apps
"most important frame" oh well, and in this case we may put more
investigation into an extension to help communicate this back (e.g. i know
my buffers swapped, but did it actually make it to screen). However, this
_should_ only be the case for 1 to 2 frames from an application before the
shell fires the exposeEvent() and stopping the application. In effect
relinquishing any attempt from Mir to take care of thwarting spinning apps,
and putting the onus on the shell (in combination with the toolkit). So in
this case there may be some un-warranted rendering, but will be short
lived. Note, adding in the exposeEvent() for both indicating loss/gain of
focus to the apps is something we must do anyway per this discussion with
the Qt upstream.

We hope to have something in a silo by early next week, with a few use
cases tested & some analysis on ensuring we're using the exposeEvent()
properly.

As a side note, we are going to have to address X legacy applications which
actually do expect & rely on blocking of eglSwapBuffers, so will be
something we'll have to address as part of our rootless X effort, to tie in
our life cycle management to insert blocking in the rootlessx-mirclient
case.



On Tue, Apr 1, 2014 at 9:02 AM, Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx> wrote:

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