[Mesa-dev] EGL: Question about deferred context and surface destroy
Tapani Pälli
tapani.palli at intel.com
Fri Apr 28 05:52:52 UTC 2017
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
More information about the mesa-dev
mailing list