<p>Functionally they are the same. </p>

<p>The driver could use them to differentiate how to handle the buffer behind the scenes. Where for example static_draw would be copied to vram as soon as possible and left there but stream_read would have a op to date copy in RAM at all times.</p>

<p>This vagueness is the reason that <a href="http://docs.gl/gl4/glBufferStorage" rel="noreferrer">glBufferStorage</a> became a thing. That way you specify what you want to be able to do with the buffer (whether you'll update it through BufferSubData, whether you'll read or write through a map, how coherent the mapping is, whether the mapping can persist across uses) and going outside those boundaries is an error.</p>

CC BY-SA 3.0
2017-10-11T08:54:45.903Z
2017-10-11T08:54:45.903Z
ratchet freak
<p>This will vary between implementations, but the driver I worked on did use these, mainly to decide memory layout. The optimizations enabled by these hints are much smaller than you would like, mainly because of the restriction that you <em>can</em> do any use whatever hints you give. e.g. it would make cache invalidation a lot cheaper if buffers hinted for read access only could not be written at all, but this optimization is impossible.</p>

<p>Some notable games which are widely used for benchmark comparisons between GPUs do not use these hints correctly, so GPU vendors have an incentive to make all uses fast even if they doesn't match the hints.</p>

CC BY-SA 3.0
2017-10-11T10:00:24.917Z
2017-10-11T10:00:24.917Z
Dan Hulme
<p>In OpenGL the buffer object functions (<a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferData.xhtml" rel="noreferrer"><code>glBufferData</code></a>, <a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferSubData.xhtml" rel="noreferrer"><code>glBufferSubData</code></a>, and probably a few others) have a parameter <code>usage</code>, described by the documentation as a hint of the intended usage, likely meant to help the implementation yield better performance.</p>

<blockquote>
  <p><em>usage</em></p>
  
  <p>Specifies the expected usage pattern of the data store. The symbolic constant must be <code>GL_STREAM_DRAW</code>, <code>GL_STREAM_READ</code>, <code>GL_STREAM_COPY</code>, <code>GL_STATIC_DRAW</code>, <code>GL_STATIC_READ</code>, <code>GL_STATIC_COPY</code>, <code>GL_DYNAMIC_DRAW</code>, <code>GL_DYNAMIC_READ</code>, or <code>GL_DYNAMIC_COPY</code>.<br/>
  <em>[...]</em><br/>
  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.</p>
</blockquote>

<p><a href="https://www.khronos.org/opengl/wiki/Buffer_Object#Buffer_Object_Usage" rel="noreferrer">The wiki</a> is similarly vague:</p>

<blockquote>
  <p>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.<br/>
  <em>[...]</em><br/>
   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.</p>
</blockquote>

<p>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?</p>

<p>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.</p>

<opengl><optimisation><vertex-buffer-object>
GL_STATIC_DRAW vs GL_DYNAMIC_DRAW vs GL_STREAM_DRAW: does it matter?
Julien Guertault
# GL_STATIC_DRAW vs GL_DYNAMIC_DRAW vs GL_STREAM_DRAW: does it matter?

(Asked by: username_0 on 2017-10-11)

In OpenGL the buffer object functions ([`glBufferData`](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferData.xhtml), [`glBufferSubData`](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferSubData.xhtml), 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`, or `GL_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](https://www.khronos.org/opengl/wiki/Buffer_Object#Buffer_Object_Usage) 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.

**Tags:** opengl, optimisation, vertex-buffer-object


---

## 2 answers

### Answer by username_2 on 2017-10-11. Score: 15 | Accepted answer

This will vary between implementations, but the driver I worked on did use these, mainly to decide memory layout. The optimizations enabled by these hints are much smaller than you would like, mainly because of the restriction that you *can* do any use whatever hints you give. e.g. it would make cache invalidation a lot cheaper if buffers hinted for read access only could not be written at all, but this optimization is impossible.

Some notable games which are widely used for benchmark comparisons between GPUs do not use these hints correctly, so GPU vendors have an incentive to make all uses fast even if they doesn't match the hints.


---

### Answer by username_1 on 2017-10-11. Score: 8

Functionally they are the same.

The driver could use them to differentiate how to handle the buffer behind the scenes. Where for example static\_draw would be copied to vram as soon as possible and left there but stream\_read would have a op to date copy in RAM at all times.

This vagueness is the reason that [glBufferStorage](http://docs.gl/gl4/glBufferStorage) became a thing. That way you specify what you want to be able to do with the buffer (whether you'll update it through BufferSubData, whether you'll read or write through a map, how coherent the mapping is, whether the mapping can persist across uses) and going outside those boundaries is an error.


---

