<blockquote>
  <p>It seems like the right thing to do would be to always specify that flag yet it is optional.</p>
</blockquote>

<p>You can map buffers for <em>reading</em>; invalidation is negatively useful for that. Also, you can map a buffer and only overwrite part of it. Invalidation is negatively useful for that too.</p>

<p><code>glMapBufferRange</code> has to be able to work outside of the narrow use case of mapping for overwriting an entire range.</p>

<blockquote>
  <p>Are there performance reasons (or other reasons) why you would not want to invalidate the data that is in a buffer that you are writing over?</p>
</blockquote>

<p>Invalidation is a mechanism to allow the implementation to not delay the act of mapping the buffer (due to prior GPU commands that read from it) if you're going to overwrite all of the area in the buffer. The implementation can allocate a chunk of memory, and you can write to that. Then, it'll schedule the DMA from that chunk into the actual buffer storage when you unmap it, handling the synchronization operations as well. For whole buffer invalidation, it can allocate GPU-accessible memory and completely <em>replace</em> the buffer's storage.</p>

<p>Of course, this only matters if you're mapping frequently. If you're using <a href="https://www.khronos.org/opengl/wiki/Buffer_Object#Persistent_mapping" rel="nofollow noreferrer">persistent mapped buffers</a> for <a href="https://www.khronos.org/opengl/wiki/Buffer_Object_Streaming#Persistent_mapped_streaming" rel="nofollow noreferrer">streaming</a> (and you should be, if you're using DSA), then you don't care about invalidation. You're going to handle synchronization manually.</p>

CC BY-SA 4.0
2018-05-06T04:30:12.290Z
2018-05-06T04:30:12.290Z
Nicol Bolas
<p>The <a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMapBufferRange.xhtml" rel="nofollow noreferrer">docs</a> for <code>glMapNamedBufferRange</code> list several optional flags that can be used when a buffer is mapped such as <code>GL_MAP_INVALIDATE_RANGE_BIT</code>.</p>

<p>The docs say:</p>

<blockquote>
  <p>The following optional flag bits in access may be used to modify the mapping:
  GL_MAP_INVALIDATE_RANGE_BIT indicates that the previous contents of the specified range may be discarded. </p>
</blockquote>

<p>It seems like the right thing to do would be to always specify that flag yet it is optional.  Even if you do not specify <code>GL_MAP_INVALIDATE_RANGE_BIT</code> or the other, similar flags I do not see how you could retrieve this data or what its value would be.</p>

<p>Are there performance reasons (or other reasons) why you would not want to invalidate the data that is in a buffer that you are writing over?</p>

<opengl>
What are the performance implications of the optional flags used when mapping a buffer?
Startec
# What are the performance implications of the optional flags used when mapping a buffer?

(Asked by: username_0 on 2018-05-06)

The [docs](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMapBufferRange.xhtml) for `glMapNamedBufferRange` list several optional flags that can be used when a buffer is mapped such as `GL_MAP_INVALIDATE_RANGE_BIT`.

The docs say:

> The following optional flag bits in access may be used to modify the mapping:
> GL\_MAP\_INVALIDATE\_RANGE\_BIT indicates that the previous contents of the specified range may be discarded.

It seems like the right thing to do would be to always specify that flag yet it is optional. Even if you do not specify `GL_MAP_INVALIDATE_RANGE_BIT` or the other, similar flags I do not see how you could retrieve this data or what its value would be.

Are there performance reasons (or other reasons) why you would not want to invalidate the data that is in a buffer that you are writing over?

**Tags:** opengl


---

## 1 answers

### Answer by username_1 on 2018-05-06. Score: 3 | Accepted answer

> It seems like the right thing to do would be to always specify that flag yet it is optional.

You can map buffers for *reading*; invalidation is negatively useful for that. Also, you can map a buffer and only overwrite part of it. Invalidation is negatively useful for that too.

`glMapBufferRange` has to be able to work outside of the narrow use case of mapping for overwriting an entire range.

> Are there performance reasons (or other reasons) why you would not want to invalidate the data that is in a buffer that you are writing over?

Invalidation is a mechanism to allow the implementation to not delay the act of mapping the buffer (due to prior GPU commands that read from it) if you're going to overwrite all of the area in the buffer. The implementation can allocate a chunk of memory, and you can write to that. Then, it'll schedule the DMA from that chunk into the actual buffer storage when you unmap it, handling the synchronization operations as well. For whole buffer invalidation, it can allocate GPU-accessible memory and completely *replace* the buffer's storage.

Of course, this only matters if you're mapping frequently. If you're using [persistent mapped buffers](https://www.khronos.org/opengl/wiki/Buffer_Object#Persistent_mapping) for [streaming](https://www.khronos.org/opengl/wiki/Buffer_Object_Streaming#Persistent_mapped_streaming) (and you should be, if you're using DSA), then you don't care about invalidation. You're going to handle synchronization manually.


---

