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?


Same applies for Context resource.

Thank you!

On Thu, Apr 27, 2017 at 2:37 AM, Tapani Pälli <tapani.pa...@intel.com <mailto:tapani.pa...@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.pa...@intel.com <mailto:tapani.pa...@intel.com>
        <mailto:tapani.pa...@intel.com <mailto:tapani.pa...@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@lists.freedesktop.org
            <mailto:mesa-dev@lists.freedesktop.org>
            <mailto:mesa-dev@lists.freedesktop.org
            <mailto:mesa-dev@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to