Sync objects shared when using a shared context

[bl4ckb0ne]

I went through the EGL_KHR_fence_sync extensions, and the behaviour of sync objects in shared context is not defined.

I did found this bit of text refering to the bound client API (GL/GLES)

When a fence sync object is created, eglCreateSyncKHR also inserts a
fence command into the command stream of the bound client API's
current context (i.e., the context returned by
eglGetCurrentContext), and associates it with the newly created sync
object.

Is it implied that they the sync objects are shared via the client API?

[cubanismo]

That's a good question. My interpretation had always been that the sync object handles themselves, as EGL rather than client API handles, are context-independent, and it was only the sync commands that operated on the current context's command stream. Hence, there'd be no need to specify sharing rules for them because they don't need to be shared. They, like an EGLSurface handle, would already be valid handles in any client API context, and hence could be used with any context that supported them. However, I don't know if that interpretation is universally agreed-upon or can be derived from any EGL spec language.

[bl4ckb0ne]

I hacked around the piglit test for the ext to add 2 test cases 1 about shared contexts. The first test case calls eglCreateSyncKHR with a context, then eglGetSyncAttribKHR and eglDestroySyncKHR in a shared context, and the second one calls eglCreateSyncKHR with a context, then eglClientWaitSyncKHR with a shared context, and eglDestroySyncKHR with the creation context.

Everything passes on the NVIDIA driver (525.147 on debian), but I have not tried with mesa. So they do seems context independent. It might be good to have this behaviour written down somewhere.

[stonesthrow]

I concur with Cubanismo.

[bl4ckb0ne]

Anything I could do to make this official in the spec?

[stonesthrow]

So I guess we could up the version of the extension with adding a paragraph about the returned fence sync handle EGLSync is usable by any other context/shared or not with a ClientWaitSync or GetSyncAttrib operation.
When accepted, we could then update EGL spec 1.5 also.

If everyone's implementation is consistent with this, then maybe we just update revision version. If it is a change to someone's implementation, we'll need a new extension EGL_KHR_fence_sync_2 with just new changes.

• @oddhack for comment on proper procedure.

[cubanismo]

Assuming everyone's implementation is consistent, I was thinking it may be sufficient to add a some umbrella language early in the EGL spec saying all EGL handles and their associated objects' state are context-independent. 2.2 "Rendering contexts" already has similar language covering surfaces, so that might be an appropriate place. Another option would be to generalize the language in 2.5 "EGLImages" to apply to sync objects as well, since the motivations and usage model are similar, though not identical (EGLImages have to be explicitly bound to some per-context client API object before accessing their state them. EGLSync objects are accessed directly.). If deemed necessary, maybe a blurb or footnote referencing that in the paragraph that defines eglCreateSync[KHR]. I can't think of an EGL-level object that has context scope off-hand.

eglGetSyncAttrib() does not require a current context AFAIK, which should make it clearer EGLSync state is not context state. EGL commands in general do not operate on the current context, unless such an interaction is explicitly called out, per my understanding. Hopefully implementations are consistent in this regard.

[stonesthrow]

That is a bit wider scope than I was thinking. But your suggestions seem good to me. So long as we are not changing expected implementation.
So instead of a change to the fence sync extension - need a proposal to EGL 1.5 spec text.