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):
glClientWaitSync with GL_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:
Fence in MappedBuffer.fsFence in Fences.fs: Does not allow to specify a timeout.FenceSet: Do we also need something like this?
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) synchronizationAccording to the documentation, a
glWaitSyncrequires a manualglFlushbefore. When using glClientWaitSync theGL_SYNC_FLUSH_COMMANDS_BITflag already does this. In cases the fence has been created in a different context than it is waited for, aglFlushneeds 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
IRuntimeshould allow creating Fences with:glClientWaitSyncwithGL_SYNC_FLUSH_COMMANDS_BITglFlush+glWaitSyncDo 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?