<p>Allocate a VBO with a reasonable amount of storage during startup, and update the data in it each frame. This will help the driver manage the memory efficiently. Don't destroy and recreate the buffer unless absolutely necessary; too much resource creation/destruction churn will put more pressure on the driver and can potentially lead to stalls.</p>

<p>To be more specific: for data that will be updated every frame, you probably want to initialize it using <a href="http://docs.gl/gl4/glBufferStorage" rel="nofollow noreferrer">glBufferStorage</a> with <code>GL_DYNAMIC_STORAGE_BIT</code> (or, if you're on an older OpenGL version, <a href="http://docs.gl/gl4/glBufferData" rel="nofollow noreferrer">glBufferData</a> with <code>GL_DYNAMIC_DRAW</code>). Then, to update it each frame, use <a href="http://docs.gl/gl4/glMapBufferRange" rel="nofollow noreferrer">glMapBufferRange</a> with <code>GL_MAP_INVALIDATE_BUFFER_BIT</code>. This should be an efficient, fast path in the graphics driver.</p>

CC BY-SA 3.0
2017-06-09T04:22:51.870Z
2017-06-09T04:22:51.870Z
Nathan Reed
<p>Since I am using batch rendering, so I should pack every render units can be batched into one big VBO. But, what if I am in a case where render units are dynamically changed, some new units are added in, and some units are subtracted out. So <strong>I should reconstruct my VBO again and again in very frame.</strong> So here is the question.</p>

<p>Should I allocate a big enough storage in the first time and update the data in it, and only reallocate when run out of the storage, or allocate storage according to the size on demand in each frame?</p>

CC BY-SA 3.0
2017-06-08T17:26:16.717Z
I thought [you said](https://stackoverflow.com/q/44431751/734069), "I will avoid asking more than one question once time later." That rule doesn't only apply to SO; it's all of our sites. Also, all of the other questions asked about that question still apply.
Nicol Bolas
CC BY-SA 3.0
2017-06-09T02:56:03.560Z
Actually, this posting is before that comment I replied.@NicolBolas
Francis
<opengl><glsl>
How can deal with batch rendering when the elements in the batch changed every frame?
Francis
# How can deal with batch rendering when the elements in the batch changed every frame?

(Asked by: username_0 on 2017-06-08)

Since I am using batch rendering, so I should pack every render units can be batched into one big VBO. But, what if I am in a case where render units are dynamically changed, some new units are added in, and some units are subtracted out. So **I should reconstruct my VBO again and again in very frame.** So here is the question.

Should I allocate a big enough storage in the first time and update the data in it, and only reallocate when run out of the storage, or allocate storage according to the size on demand in each frame?

**Tags:** opengl, glsl

> **Comments:**
> **username_1**: I thought [you said](https://stackoverflow.com/q/44431751/734069), "I will avoid asking more than one question once time later." That rule doesn't only apply to SO; it's all of our sites. Also, all of the other questions asked about that question still apply.  
> **username_0**: Actually, this posting is before that comment I replied.@username_1  

---

## 1 answers

### Answer by username_2 on 2017-06-09. Score: 2 | Accepted answer

Allocate a VBO with a reasonable amount of storage during startup, and update the data in it each frame. This will help the driver manage the memory efficiently. Don't destroy and recreate the buffer unless absolutely necessary; too much resource creation/destruction churn will put more pressure on the driver and can potentially lead to stalls.

To be more specific: for data that will be updated every frame, you probably want to initialize it using [glBufferStorage](http://docs.gl/gl4/glBufferStorage) with `GL_DYNAMIC_STORAGE_BIT` (or, if you're on an older OpenGL version, [glBufferData](http://docs.gl/gl4/glBufferData) with `GL_DYNAMIC_DRAW`). Then, to update it each frame, use [glMapBufferRange](http://docs.gl/gl4/glMapBufferRange) with `GL_MAP_INVALIDATE_BUFFER_BIT`. This should be an efficient, fast path in the graphics driver.


---

