Platform/GFX/CrossContextSyncing
Order of Execution Between Contexts
We need to sync objects across contexts. Specifically, we need a way to guarantee that all operations on an object complete on one context, and before another context uses it.
If glFlush is sufficient to get the context's commands to the hardware's serial buffer, we can guarantee that even commands across different contexts are executed in the order we want, and that the contents of the backing shared texture will be complete and valid for the layers context.
Spec Wording
The spec does not guarantee glFlush to be sufficient. The main relevant section is D.3.3, specifically Rule 2:
While a container object C is bound, any changes made to the contents of C’s attachments in the current context are guaranteed to be seen. To guarantee seeing changes made in another context to objects attached to C, such changes must be completed in that other context (see section D.3.1) prior to C being bound. Changes made in another context but not determined to have completed as described in section D.3.1, or after C is bound in the current context, are not guaranteed to be seen.
Section D.3.1 reads:
The contents of an object T are considered to have been changed once a command such as described in section D.3 has completed. Completion of a command 1 may be determined either by calling Finish, or by calling FenceSync and executing a WaitSync command on the associated sync object. The second method does not require a round trip to the GL server and may be more efficient, particularly when changes to T in one context must be known to have completed before executing commands dependent on those changes in another context.
This wording is from OpenGL 4.2 spec, but OpenGL ES 2.0 spec has similar wording, though omitting fence/sync objects.
Results
We cannot rely on glFlush being sufficient for all implementations, though some implementations may guarantee that it can. We can use glFlush if the platform's implementation explicitly supports this usage, but otherwise, as per spec, we must use either glFinish or ARB_sync.
However, in the case of ANGLE, we may be able to use D3D10's serializing flush.
A number of texts relating to Apple's OGL implementations leads me to believe glFlush is sufficient for this purpose.
It should further be noted that if context A binds object X, and context B changes the contents of object X, not only must context A wait for the change from context B to complete, but context A must also rebind object X to guarantee seeing its updated contents.
Links
Exceptions
If we're copying the contents into system memory, for example via glReadPixels, the contents are implicitly resolved. That is, there's no need to call glFlush or glFinish before glReadPixels.
