In OpenGL the buffer object functions (glBufferData
, glBufferSubData
, and probably a few others) have a parameter usage
, described by the documentation as a hint of the intended usage, likely meant to help the implementation yield better performance.
usage
Specifies the expected usage pattern of the data store. The symbolic constant must be
GL_STREAM_DRAW
,GL_STREAM_READ
,GL_STREAM_COPY
,GL_STATIC_DRAW
,GL_STATIC_READ
,GL_STATIC_COPY
,GL_DYNAMIC_DRAW
,GL_DYNAMIC_READ
, orGL_DYNAMIC_COPY
.
[...]
usage is a hint to the GL implementation as to how a buffer object's data store will be accessed. This enables the GL implementation to make more intelligent decisions that may significantly impact buffer object performance. It does not, however, constrain the actual usage of the data store.
The wiki is similarly vague:
These are only hints, after all. It is perfectly legal OpenGL code to modify a STATIC buffer after it has been created, or to never modify a STREAM buffer.
[...]
These are questions that can only be answered with careful profiling. And even then, the answer will only be accurate for that particular driver version from that particular hardware vendor.
In fine, how relevant is this parameter, if at all? Do drivers actually take it into account, and if they do, in your experience how much does it impact performance in practice? Do you have data to share?
I have written a thin graphics API abstraction layer meant to be implemented as either of the existing APIs, and it is tempting to just ignore this parameter altogether and hide it from the exposed abstraction.