[Mesa-dev] [PATCH 2/2] egl: make eglWaitClient behave like glFinish

Eric Anholt eric at anholt.net
Mon May 14 18:24:17 UTC 2018


Tapani Pälli <tapani.palli at intel.com> writes:

> On 14.05.2018 10:03, Eric Anholt wrote:
>> Tapani Pälli <tapani.palli at intel.com> writes:
>> 
>>> As defined by the spec:
>>>     "All rendering calls for the currently bound context, for
>>>     the current rendering API, made prior to eglWaitClient, are
>>>     guaranteed to be executed before native rendering calls made
>>>     after eglWaitClient which affect the read or draw surfaces
>>>     associated with that context.
>>>
>>>     The same result can be achieved using client API-specific calls
>>>     such as glFinish or vgFinish."
>>>
>>> v2: call glFinish() to ensure identical behaviour
>>>
>>> Signed-off-by: Tapani Pälli <tapani.palli at intel.com>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106337
>> 
>> I don't think the operation they're doing there is "native rendering" as
>> far as EGL is concerned.  I think the backend flush is the right thing
>> for us to be calling here, same as glXWaitGL().  If they want
>> glFinish(), they should be calling glFinish().
>> 
>
> Hmm ok .. the problem is that they do CPU read on the buffer which is 
> not "native rendering" but it seemed to me something that native API 
> could also attempt to do. I'm OK with 'just use glFinish' also.

To pretend to be "native rendering", the CPU read on the other side
should be participating in implicit synchronization.  That's what a
glamor fallback would be doing in X11, for example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180514/d782c876/attachment.sig>


More information about the mesa-dev mailing list