|
The Vish Visualization Shell 0.3
Vish
|
Limitations of using OpenGL fences for VAO and buffer upload readiness. More...
#include <ocean/GLvish/VertexArrayObject.hpp>
Limitations of using OpenGL fences for VAO and buffer upload readiness.
This document explains why glFenceSync() is unsuitable for determining the readiness of individual VAOs or buffer objects during asynchronous data uploads. The behavior follows directly from the OpenGL execution and memory model.
A fence created via glFenceSync() represents a global timeline marker. The fence becomes signaled only after all GPU commands issued prior to the fence in the same context have completed, regardless of which resources those commands operate on.
As a consequence, a fence cannot be associated with a specific VAO or buffer. Any unrelated long-running operation (e.g., a slow upload to a different buffer) delays the fence, even if the resources relevant to the intended VAO are already fully uploaded and ready for use.
In contrast to fences, draw commands perform resource-based dependency tracking. A draw call waits only for GPU writes that affect the specific buffers, textures, and state objects it will read. Unrelated uploads or operations on other VAOs do not delay the draw.
This means a draw call may execute correctly even when a fence inserted after the upload of its associated buffers remains unsignaled due to unrelated earlier commands.
Fences should not be used as a per-VAO or per-buffer readiness mechanism. Instead, readiness must be tracked at the granularity of the specific buffer operations (e.g., completion of the copy into the device-local buffer), using explicit synchronization associated with those operations only.