<div dir="ltr">Hi Tapani, <div> 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). </div><div>Thanks! </div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Apr 28, 2017 at 1:52 AM, Tapani Pälli <<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 04/28/2017 08:08 AM, Tapani Pälli wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 04/28/2017 08:05 AM, Tapani Pälli wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 04/27/2017 06:59 PM, Mike Gorchak wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote> 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? </blockquote> Sorry nope, now I got it. You mean surface should survive because it is still current at same thread. </blockquote> 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)."<div class="HOEnZb"><div class="h5"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Same applies for Context resource. Thank you! On Thu, Apr 27, 2017 at 2:37 AM, Tapani Pälli <<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a> <mailto:<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>>> 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(): <a href="https://cgit.freedesktop.org/mesa/demos/tree/src/egl/eglut/eglut.c#n321" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/mesa/demos/tree/src/egl/eglut/eglut.c#n321</a> <<a href="https://cgit.freedesktop.org/mesa/demos/tree/src/egl/eglut/eglut.c#n321" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/mesa/demos/tree/src/egl/eglut/eglut.c#n321</a>> |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 <<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a> <mailto:<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>> <mailto:<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a> <mailto:<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>>>> 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: <a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml</a> <<a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml</a>> <<a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml</a> <<a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroySurface.xhtml</a>>> 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: <a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml</a> <<a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml</a>> <<a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml</a> <<a href="https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglDestroyContext.xhtml</a>>> 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 <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>> <mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>>> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> <<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>> <<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> <<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>>> </blockquote> _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote> _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote> </div></div></blockquote></div> </div>