Reusing EGLContext handles for deleted but still current contexts about egl-registry

[stonesthrow]

You are correct about the EGLContext.

I have seen instances where if you call eglMakeCurrent(dpy, null, null, null); just after eglDestroyContext - as given above - which does result in the real destroy, And then ctx2 could have the same Handle value just by coincidence that its the same block of memory reallocated for the new ctx2. But all object handles are unique. You wont have ctx1 and ctx2 with same handle.

The Handle EGLContext exists, but as you point out, eglDestroyContext and eglTerminate will mark it for destroy, and that basically means from the app you can't use that handle for another egl operation (except for eglMakeCurrent and eglReleaseThread). But internally, that context, being "current", can still be in use for rendering. An so it isn't truly deleted until eglMakeCurrent sets it uncurrent - thus not in use for rendering. You can see why that needs to be, if deleted immediately current running GL/GLES draw calls would could come to a crash with your GPU.

eglGetCurrentContext will return the context made current with eglMakeCurrent on the thread that called that operation - it may be a valid current context or EGL_NO_CONTEXT. A different thread can not make it uncurrent. Think of it as when you create a context or any egl object it exists with one ref count. When made current its get a refcount but owned by that specific thread. Only eglMakeCurrent(dpy, null,null,null) decrements that count and only Destroy or Terminate decrements the original ref count. A count of zero is needed to delete.

[evelikov]

FWIW Mesa's implementation matches the reply by @stonesthrow
Namely:

• ctx1 and ctx2 may be the same, only if the mem. allocator provides the same address
• eglGetCurrent* gets the thread specific data, which in the case of a eglDestroy* call is "unlinked" (the term used in Mesa), thus EGL_NO_* is returned.

[stonesthrow]

If the questions/concerns/issues have been addressed, then lets close this issue?

[kbrenneman]

The crux of the question is whether there's an identity relationship between an EGLContext handle and the actual context. That would define what it means when a handle is "invalidated" after eglDestroyContext or eglTerminate returns.

@stonesthrow's (and my) interpretation assumes that there must be an identity relationship between the EGLContext handle and the context. In that case, the handle must be in use as long as the context exists, and therefore you can't re-use the same handle as long as the old context is current.

If an EGLContext handle is simply a pointer to the driver's internal reference-counted context struct, then this is the behavior you'd get.

If you don't assume an identity relationship, then you could read it that the EGLContext handle is more like the context XID in GLX. If the client sends a GLXDestroyContext request for a current context. then the resource ID is destroyed, but the context in the server still sticks around. You can still reference the context by context tag, and (I think) the client could then use that XID for another GLXCreateContext request.

You could get behavior like that if a driver kept an array of pointers to its internal (still reference-counted) context structs, and used an index into that array as an EGLContext handle.

Anyway, I'd be perfectly happy to close the issue and take the first option of not reusing a context, since that's the only way I can think of to get coherent results from eglGetCurrentContext. I just want to make sure we've nailed down the identity question.

[stonesthrow]

Discussed in EGL WG, clarification is warranted. KBrenneman to propose text in a new Khronos gitlab MR