-
Notifications
You must be signed in to change notification settings - Fork 14
Description
We need to abstract synchronization functionally behind our rendering API in order to allow the implementation of advanced applications:
https://www.khronos.org/opengl/wiki/Sync_Object
There are two different kinds: CPU (glClientWaitSync) and GPU (glWaitSync) synchronization
According to the documentation, a glWaitSync requires a manual glFlush before. When using glClientWaitSync the GL_SYNC_FLUSH_COMMANDS_BIT flag already does this. In cases the fence has been created in a different context than it is waited for, a glFlush needs to be also performed on the creating context to make sure the creation of the fence has been performed!
In the current GL backend internal implementation, a flush is performed directly after the creation. In my Application, everything will be executed on the same context, it would be nice to handle this case without performing a flush if the wait is performed on the same context. Maybe we can delay the flush till the unbind of the context and perform it only if there was no wait till then? However, this might flush more than intended for the synchronization. I cannot think of any other clean way except specifying this at the creation time of the fence. I will do some profiling and check if a flush would have a significant impact.
The IRuntime should allow creating Fences with:
- IRuntime.CreateFence(doNotFushAsIWillUsetheSameContextForWaiting? : bool)
- WaitCPU(timeout):
glClientWaitSyncwithGL_SYNC_FLUSH_COMMANDS_BIT - WaitGPU(timeout):
glFlush+glWaitSync - Restart?
Do we need interoperability to RenderCommands?
Implementations that can already found be in the GL backend:
Fencein MappedBuffer.fsFencein Fences.fs: Does not allow to specify a timeout.FenceSet: Do we also need something like this?