[Mesa-dev] [PATCH 2/2] egl/dri2: don't require a context for ClientWaitSync

Albert Freeman albertwdfreeman at gmail.com
Sun Sep 27 22:45:52 PDT 2015


On 28 September 2015 at 15:20, Albert Freeman <albertwdfreeman at gmail.com> wrote:
> On 28 September 2015 at 14:38, Albert Freeman <albertwdfreeman at gmail.com> wrote:
>> On 28 September 2015 at 04:12, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 26 September 2015 at 00:49, Marek Olšák <maraeo at gmail.com> wrote:
>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>
>>>> The spec doesn't require it. This fixes a crash on Android.
>>>>
>>> Nicely spotted Marek.
>>>
>>> A couple of related (not supposed to be part of this patch) notes:
>>>  - This will just move the crash (from libEGL to i965_dri.so) for i965
>>> hardware :)
>> I rediscovered this before I read the email related to this patch
>> (where Marek mentions it): "Re: [Mesa-dev] Pending issues of
>> lollipop-x86".
>> Who (if anyone) should we CC this to?
>>>  - We really shouldn't be setting the flags if ctx is NULL, as per the spec.
>>>
>>>     "If no context is
>>>     current for the bound API, the EGL_SYNC_FLUSH_COMMANDS_BIT_KHR bit
>>>     is ignored."
>> Maybe handle this in the driver (probably state_tracker in the case of
>> gallium) level. Both here and drivers?
> OpenGL ClientWaitSync is very clear about SYNC_FLUSH_COMMANDS_BIT only
> flushing the GL context when the fence sync is created (it doesn’t
> seem to require it at the moment wait sync is called (probably to
> leave room for drivers to optimise)). EGL is a lot less clear, it
> could be interpreted as behaving just like GL, but to someone writing
> an EGL program it could be easily interpreted as "the flush() must
> occur when eglClientWaitSync is called with SYNC_FLUSH_COMMANDS_BIT".
Instead of
"the flush() must occur when eglClientWaitSync is called with
SYNC_FLUSH_COMMANDS_BIT"
I meant
"the flush() must occur at the moment eglClientWaitSync is called with
SYNC_FLUSH_COMMANDS_BIT"
>
> The current behaviour of gallium (not sure about i965) is to always
> flush() when creating the sync object (hence always behave as
> SYNC_FLUSH_COMMANDS_BIT is set according to GL). However
> implementations are allowed to behave as if flush was not required (in
> GL and I am assuming EGL). So technically the current behaviour of the
> gallium dri state tracker could reduce performance (since flushing
> tends to do that). It however doesn’t actually violate the EGL spec.
> Perhaps some heuristics on when to flush would be a good solution?
>>>
>>> -Emil
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list