[Mesa-dev] EGL: Question about deferred context and surface destroy
Mike Gorchak
mike.gorchak.qnx at gmail.com
Mon May 1 14:04:32 UTC 2017
Hi Tapani,
Thank you very much for this explanation! All is clear now, and you are
right about function description, they have to be a bit more detailed
regarding this. As far as I understood there is a huge GPS navigation
framework which depends on wrong behavior regarding deferred context and
surface destroy using EGL and GLES drivers for one of the GPUs integrated
into ARM based SoC. And this framework failed to run on automotive Intel
ApolloLake platform using Mesa3D EGL (which is used even if Intel UFO
drivers are used in place of i965 driver).
Thanks!
On Fri, Apr 28, 2017 at 1:52 AM, Tapani Pälli <tapani.palli at intel.com>
wrote:
>
>
> On 04/28/2017 08:08 AM, Tapani Pälli wrote:
>
>>
>>
>> On 04/28/2017 08:05 AM, Tapani Pälli wrote:
>>
>>>
>>>
>>> On 04/27/2017 06:59 PM, Mike Gorchak wrote:
>>>
>>>> Hi Tapani,
>>>>
>>>> Could you please do modification like I suggested to eglut library and
>>>> check how it is going?
>>>>
>>>> I'm asking because I see following code:
>>>>
>>>> EGLBoolean EGLAPIENTRY
>>>> eglDestroySurface(EGLDisplay dpy, EGLSurface surface)
>>>> {
>>>> _EGLDisplay *disp = _eglLockDisplay(dpy);
>>>> _EGLSurface *surf = _eglLookupSurface(surface, disp);
>>>> _EGLDriver *drv;
>>>> EGLBoolean ret;
>>>>
>>>> _EGL_FUNC_START(disp, EGL_OBJECT_SURFACE_KHR, surf, EGL_FALSE);
>>>> _EGL_CHECK_SURFACE(disp, surf, EGL_FALSE, drv);
>>>> _eglUnlinkSurface(surf);
>>>> ret = drv->API.DestroySurface(drv, disp, surf);
>>>>
>>>> RETURN_EGL_EVAL(disp, ret);
>>>> }
>>>>
>>>> It does explicit call to _eglUnlinkSurface(surf) without any conditions
>>>> which unlinks Surface from current Display and then if we re-use this
>>>> surface, for example, in eglSwapBuffer() it return EGL_BAD_SURFACE, because
>>>> _eglCheckSurface() will return error (NULL). This surface was unlinked from
>>>> Display, but not yet destroyed.
>>>>
>>>
>>> ok, so in the driver side we do handle refcount but the API side has
>>> called _eglUnlinkSurface ... yeah, this looks a bit weird, I'll try to
>>> think of an example for this.
>>>
>>> I did not quite get your eglut proposal, I believe in that one I will be
>>> destroying surface and context since no other thread has them current at
>>> that point. I should have 2 threads where both have made surface current
>>> and then destroy surface in another and make sure surface is still usable
>>> in another, right?
>>>
>>
>> Sorry nope, now I got it. You mean surface should survive because it is
>> still current at same thread.
>>
>
> Which IMO is not right, although I agree that EGL spec could state it more
> clearly. For surfaces the spec says:
>
> "Following eglDestroySurface, the surface and the handle referring to it
> are treated in the same fashion as a surface destroyed by eglTerminate (see
> section 3.2)."
>
> which says:
>
> "Termination marks all EGL-specific resources, such as contexts and
> surfaces, associated with the specified display for deletion. Handles to
> all such resources are invalid as soon as eglTerminate returns, but the dpy
> handle itself remains valid. Passing such handles to any other EGL command
> will generate EGL_BAD_SURFACE or EGL_BAD_CONTEXT errors."
>
> And as bonus there is also section 'Updates to EGL 1.4" that has this:
>
> "Change object destruction behavior such that object handles become
> invalid immediately after an object is deleted, although the underlying
> object may remain valid if it’s current to a context. This affects
> eglTerminate (section 3.2), eglDestroySurface (section 3.5.5),
> eglDestroyContext (section 3.7.2), and eglGetCurrentContext and
> eglGetCurrentSurface (section 3.7.4)."
>
>
>
>
>>
>>> Same applies for Context resource.
>>>>
>>>> Thank you!
>>>>
>>>> On Thu, Apr 27, 2017 at 2:37 AM, Tapani Pälli <tapani.palli at intel.com
>>>> <mailto:tapani.palli at intel.com>> wrote:
>>>>
>>>>
>>>>
>>>> On 04/26/2017 05:08 PM, Mike Gorchak wrote:
>>>>
>>>> Hi Tapani,
>>>>
>>>> Sure, I can share them, but they are QNX based. And as far as I
>>>> remember it was an issue in the past :)
>>>>
>>>>
>>>> I thought to ask because there are some multithread dEQP EGL tests
>>>> around this and they are passing at the moment.
>>>>
>>>> Surface and context reference counts are incremented in
>>>> _eglBindContext that gets called during makecurrent. Surface count
>>>> decrements via _eglPutSurface and _eglPutContext calls. AFAIK
>>>> everything looks OK.
>>>>
>>>>
>>>> I think the simplest way for you is to add following calls to
>>>> function eglutCreateWindow():
>>>>
>>>> https://cgit.freedesktop.org/mesa/demos/tree/src/egl/eglut/eglut.c#n321
>>>> <https://cgit.freedesktop.org/mesa/demos/tree/src/egl/eglut/
>>>> eglut.c#n321>
>>>>
>>>> |if (!eglMakeCurrent(_eglut->dpy, win->surface, win->surface,
>>>> win->context)) _eglutFatal("failed to make window current");|
>>>>
>>>> to
>>>>
>>>> |if (!eglMakeCurrent(_eglut->dpy, win->surface, win->surface,
>>>> win->context)) _eglutFatal("failed to make window current");
>>>> |
>>>>
>>>> |||eglDestroySurface(|||_eglut->dpy, ||||win->surface|);|
>>>>
>>>> |eglDestroyContext||(||||_eglut->dpy, ||||win->context||);|
>>>>
>>>> And then run GLES 1.x gears for example. According to EGL
>>>> specification, these Destroy calls should be delayed till
>>>> surface and context is not current in any thread. Perhaps I
>>>> understand specification too literally, that's why I'm asking
>>>> rather than reporting it as a bug.
>>>>
>>>> Thank you!
>>>>
>>>>
>>>> On Wed, Apr 26, 2017 at 2:09 AM, Tapani Pälli
>>>> <tapani.palli at intel.com <mailto:tapani.palli at intel.com>
>>>> <mailto:tapani.palli at intel.com <mailto:tapani.palli at intel.com
>>>> >>>
>>>> wrote:
>>>>
>>>> On 04/25/2017 10:20 PM, Mike Gorchak wrote:
>>>>
>>>> Hi all,
>>>>
>>>> During a quick tests of latest Mesa3D versions at
>>>> different
>>>> branches 12.x, 13.x, 17.x we have found that deferred
>>>> context and
>>>> surface destroy doesn't work properly.
>>>>
>>>>
>>>> What kind of test case are you using, could you share this?
>>>>
>>>> According to docs:
>>>> https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroySurface.xhtml
>>>> <https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroySurface.xhtml>
>>>> <https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroySurface.xhtml
>>>> <https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroySurface.xhtml>>
>>>>
>>>> Description
>>>> If the EGL surface is not current to any thread,
>>>> eglDestroySurface
>>>> destroys it immediately. Otherwise, surface is
>>>> destroyed when it
>>>> becomes not current to any thread. Furthermore,
>>>> resources
>>>> associated with a pbuffer surface are not released
>>>> until all color
>>>> buffers of that pbuffer bound to a texture object have
>>>> been released.
>>>>
>>>> Same for context destroy:
>>>> https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroyContext.xhtml
>>>> <https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroyContext.xhtml>
>>>> <https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroyContext.xhtml
>>>> <https://www.khronos.org/registry/EGL/sdk/docs/man/html/
>>>> eglDestroyContext.xhtml>>
>>>>
>>>> Description
>>>> If the EGL rendering context is not current to any
>>>> thread,
>>>> eglDestroyContext destroys it immediately. Otherwise,
>>>> context is
>>>> destroyed when it becomes not current to any thread.
>>>>
>>>> Should this behavior be handled at EGL common DRI2
>>>> level or DRI2
>>>> platform driver level or it should be handled by EGL
>>>> itself? I can
>>>> see some refcounts implemented for EGL surfaces,
>>>> buteglMakeCurrent
>>>> seems don't increment them for surfaces and contexts.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> <mailto:mesa-dev at lists.freedesktop.org>
>>>> <mailto:mesa-dev at lists.freedesktop.org
>>>> <mailto:mesa-dev at lists.freedesktop.org>>
>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>> <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>
>>>> <https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>> <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170501/93d86c58/attachment.html>
More information about the mesa-dev
mailing list