checking if GLsync is signalled without calling into the API

The OpenGL wiki about GLsync objects (Sync Object - OpenGL Wiki) states:

“Sync objects are never bound to the context, nor do they encapsulate state the way normal GL objects do. These are not OpenGL objects.”

On Android it’s possible to create a native sync from a EGLsync through the ANDROID_native_fence_sync extension which allows to check the state of the fence through a file descriptor (apparently under the hood the EGLsync on Android is implemented as a file descriptor).

These things make me believe that it should be possible to check the signaled state of a GLsync object without having to perform an API call.
The reason I am looking for such a way is because I want to check the signaled state of a GLsync on a worker thread and creating a second context for the worker thread solely for the purpose of checking the state of the sync feels overkill (plus, even though multiple contexts work fine with each other in theory, in the real world they seem to often cause obscure performance problems).

I am on windows, does anyone know any way to check the state of a GLsync without calling into the API?

“Sync objects are never bound to the context, nor do they encapsulate state the way normal GL objects do. These are not OpenGL objects.”

I apologise for the confusion. But when it says “These are not OpenGL objects”, that only means that they do not fall into the strict paradigm of standard [OpenGL Objects](https://www.opengl.org/wiki/OpenGL Object). That should not be taken to imply that those objects do not belong to OpenGL or are somehow not part of OpenGL.

As to your specific question, no. Desktop OpenGL does not have any non-vendor-specific facilities for talking to a sync object without a context. Of course, neither does OpenGL ES or EGL; ANDROID_native_fence_sync is, as the name suggests, an Android-specific OpenGL ES/EGL extension.

You should not assume that the existence of this extension means that sync objects must be implemented in a way that can be checked via native facilities.

[QUOTE=Alfonse Reinheart;1280210]I apologise for the confusion. But when it says “These are not OpenGL objects”, that only means that they do not fall into the strict paradigm of standard [OpenGL Objects](https://www.opengl.org/wiki/OpenGL Object). That should not be taken to imply that those objects do not belong to OpenGL or are somehow not part of OpenGL.

As to your specific question, no. Desktop OpenGL does not have any non-vendor-specific facilities for talking to a sync object without a context. Of course, neither does OpenGL ES or EGL; ANDROID_native_fence_sync is, as the name suggests, an Android-specific OpenGL ES/EGL extension.

You should not assume that the existence of this extension means that sync objects must be implemented in a way that can be checked via native facilities.[/QUOTE]

Thank you a lot for your response. Is there any other way in which a worker thread can check whether the GPU has finished processing something without causing a context switch?

The worker thread should not need a context switch of any kind. It should simply have a context that remains current all the time. As long as that context is shared with your main one, there is no need for switching between them.

But without a context of any kind, there is no way of doing that. Not without some vendor-specific extension. And I don’t know of any that could even do that. The closest that might exist would be the very old WGL_I3D_image_buffer extension. And that only allows waiting for rendering to complete.

but won’t the GPU or at the very least the driver need to perform a context switch (the real cost of which I am not aware of, I just heard that Graphics cards do not like context switches) since API calls are issued from multiple contexts?

The term “context switch”, when talking about graphics, tends to refer to… switching contexts. As in wglMakeContextCurrent and so forth. So if you’re not calling that function, then no context switching of that kind is happening.

Generally speaking, as long as you’re not actually issuing commands that go down the GPU pipeline (ie: things that change object state, data storage, or rendering commands), you’re fine. Checking the status of a query object on a different thread shouldn’t cause problems.