Re: [Mesa-dev] EGL: Question about deferred context and surface destroy

Thu, 27 Apr 2017 22:53:46 -0700 


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.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

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
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