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.
Same applies for Context resource.
Thank you!
On Thu, Apr 27, 2017 at 2:37 AM, Tapani Pälli <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
>>
>> |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>> 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>
>>>
>>> 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>
>>>
>>> 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.freedes
>>> ktop.org>
>>> 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
