<p>In general, when you render an object in an immediate mode—issuing line drawing commands for instance—you build up a series of commands that you submit to the graphics card to draw. If you're drawing a lot of data, or drawing very frequently, you can waste a lot of time sending this data over and over again.</p>

<p>A vertex buffer allows you to produce a single object that you submit to the graphics card once. If you don't need to change your geometry, you can leave it on the graphics card and simply send the graphics card a request to draw that object. Since it avoids the copy every time you draw, there's much less overhead for each draw.</p>

<p>Note that using a vertex buffer object doesn't always provide a very significant speedup. If you're only drawing the object once per frame, and you're replacing the geometry in between each frame, then you don't get the benefits of avoiding the copy each frame.</p>

<p>Most of my experience comes from writing programs using graphics APIs like OpenGL, so someone who's messed with the backend of a graphics driver can probably provide a more detailed answer, but I hope this makes things a bit clearer.</p>

CC BY-SA 3.0
2015-08-05T01:34:47.203Z
2015-08-05T01:34:47.203Z
porglezomp
<p>There are two steps that make the VBO more efficient than immediate mode.</p>

<ol>
<li><p><strong>Immediate mode</strong> (<a href="https://www.opengl.org/sdk/docs/man2/xhtml/glBegin.xml" rel="nofollow">glBegin/glEnd</a>, <a href="https://www.opengl.org/sdk/docs/man2/xhtml/glVertex.xml" rel="nofollow">glVertex*</a>, etc.) means that at each frame, you spoon feed the vertices, attribute per attribute (position, normal, color, etc.), to the driver, which then reformats them and finally sends the whole package as a command to the GPU. That a lot of function calls per vertex on each frame.<br/>
(Note that <a href="https://www.opengl.org/wiki/History_of_OpenGL#Deprecation_Model" rel="nofollow">immediate mode is deprecated since OpenGL 3.0</a>, and is entirely <a href="https://www.opengl.org/registry/doc/glspec32.core.20091207.pdf" rel="nofollow">removed from 3.2</a>.)</p></li>
<li><p>By using <strong>vertex arrays</strong> (see <a href="https://www.opengl.org/sdk/docs/man/html/glDrawArrays.xhtml" rel="nofollow">glDrawArrays</a>, <a href="https://www.opengl.org/sdk/docs/man/html/glDrawElements.xhtml" rel="nofollow">glDrawElements</a>, <a href="https://www.opengl.org/sdk/docs/man2/xhtml/glVertexPointer.xml" rel="nofollow">glVertexPointer</a>, etc.), you can give the driver the whole thing at once and save it the burden of reformatting the vertices. You're effectively replacing several function calls per vertex by just a handful of calls for the whole mesh. But you still need to do that once a frame.</p></li>
<li><p><strong><a href="https://www.opengl.org/wiki/Vertex_Specification#Vertex_Buffer_Object" rel="nofollow">Vertex Buffer Object</a></strong>, or <strong>VBO</strong> (see <a href="https://www.opengl.org/sdk/docs/man/html/glGenBuffers.xhtml" rel="nofollow">glGenBuffers</a>, <a href="https://www.opengl.org/sdk/docs/man/html/glBindBuffer.xhtml" rel="nofollow">glBindBuffer</a>, etc.) go one step further and store the data on the GPU side: you send it only once, and then just refer to it by a handle. You save bandwidth by not sending the same data over and over at each frame.</p></li>
</ol>

CC BY-SA 3.0
2015-08-05T02:55:44.850Z
2016-04-08T05:37:52.483Z
2016-04-08T05:37:52.483Z
Julien Guertault
<p>By using an immediate mode interface (e.g. old style OpenGL glBegin()/glEnd()/glVertex()) you're effectively drip feeding data to the driver one piece at a time. It then has to take that single piece of data, reformat it and pass it on to the hardware (which these days means putting it into a command buffer).</p>

<p>By using a vertex buffer object, you're providing a (hopefully) large block of data to the driver ahead of when it needs to be used. It can perform a number of optimizations (reformatting, placing into video memory) as well as not having to feed the GPU piecemeal.</p>

<p>In practice if you're only drawing a small number of primitives then it probably won't make much difference, however if you're drawing a multi-million triangle mesh then VBOs in video memory are the way to go.</p>

CC BY-SA 3.0
2015-08-05T01:36:09.247Z
2015-08-05T01:36:09.247Z
Andrew Sidwell
<p>From my basic understanding, a Vertex Buffer Object works something like this (pseudo code):</p>

<p>Normally, if one wanted to say, draw a square, one could issue line drawing commands.</p>

<pre><code>line (0, 0) -&gt; (1, 0)
line (1, 0) -&gt; (1, 1)
line (1, 1) -&gt; (0, 1)
line (0, 1) -&gt; (0, 0)
</code></pre>

<p>Using a VBO, if I understand correctly, would load the vertices into a VBO.</p>

<pre><code>define VBO
load (0,0) -&gt; VBO
load (1,0) -&gt; VBO
load (1,1) -&gt; VBO
load (0,1) -&gt; VBO
load (0,0) -&gt; VBO
</code></pre>

<p>Then you can issue one drawing command.</p>

<pre><code>draw VBO vertices
</code></pre>

<p>While I understand how VBOs work, I don't know why they improve performance. </p>

<p>How do they improve performance?</p>

<performance><rendering><vertex-buffer-object>
Why do Vertex Buffer Objects improve performance?
Ethan Bierlein
# Why do Vertex Buffer Objects improve performance?

(Asked by: username_0 on 2015-08-05)

From my basic understanding, a Vertex Buffer Object works something like this (pseudo code):

Normally, if one wanted to say, draw a square, one could issue line drawing commands.

```
line (0, 0) -> (1, 0)
line (1, 0) -> (1, 1)
line (1, 1) -> (0, 1)
line (0, 1) -> (0, 0)

```

Using a VBO, if I understand correctly, would load the vertices into a VBO.

```
define VBO
load (0,0) -> VBO
load (1,0) -> VBO
load (1,1) -> VBO
load (0,1) -> VBO
load (0,0) -> VBO

```

Then you can issue one drawing command.

```
draw VBO vertices

```

While I understand how VBOs work, I don't know why they improve performance.

How do they improve performance?

**Tags:** performance, rendering, vertex-buffer-object


---

## 3 answers

### Answer by username_1 on 2015-08-05. Score: 11 | Accepted answer

In general, when you render an object in an immediate mode—issuing line drawing commands for instance—you build up a series of commands that you submit to the graphics card to draw. If you're drawing a lot of data, or drawing very frequently, you can waste a lot of time sending this data over and over again.

A vertex buffer allows you to produce a single object that you submit to the graphics card once. If you don't need to change your geometry, you can leave it on the graphics card and simply send the graphics card a request to draw that object. Since it avoids the copy every time you draw, there's much less overhead for each draw.

Note that using a vertex buffer object doesn't always provide a very significant speedup. If you're only drawing the object once per frame, and you're replacing the geometry in between each frame, then you don't get the benefits of avoiding the copy each frame.

Most of my experience comes from writing programs using graphics APIs like OpenGL, so someone who's messed with the backend of a graphics driver can probably provide a more detailed answer, but I hope this makes things a bit clearer.


---

### Answer by username_2 on 2015-08-05. Score: 10

There are two steps that make the VBO more efficient than immediate mode.

1. **Immediate mode** ([glBegin/glEnd](https://www.opengl.org/sdk/docs/man2/xhtml/glBegin.xml), [glVertex\*](https://www.opengl.org/sdk/docs/man2/xhtml/glVertex.xml), etc.) means that at each frame, you spoon feed the vertices, attribute per attribute (position, normal, color, etc.), to the driver, which then reformats them and finally sends the whole package as a command to the GPU. That a lot of function calls per vertex on each frame.  
   (Note that [immediate mode is deprecated since OpenGL 3.0](https://www.opengl.org/wiki/History_of_OpenGL#Deprecation_Model), and is entirely [removed from 3.2](https://www.opengl.org/registry/doc/glspec32.core.20091207.pdf).)
2. By using **vertex arrays** (see [glDrawArrays](https://www.opengl.org/sdk/docs/man/html/glDrawArrays.xhtml), [glDrawElements](https://www.opengl.org/sdk/docs/man/html/glDrawElements.xhtml), [glVertexPointer](https://www.opengl.org/sdk/docs/man2/xhtml/glVertexPointer.xml), etc.), you can give the driver the whole thing at once and save it the burden of reformatting the vertices. You're effectively replacing several function calls per vertex by just a handful of calls for the whole mesh. But you still need to do that once a frame.
3. **[Vertex Buffer Object](https://www.opengl.org/wiki/Vertex_Specification#Vertex_Buffer_Object)**, or **VBO** (see [glGenBuffers](https://www.opengl.org/sdk/docs/man/html/glGenBuffers.xhtml), [glBindBuffer](https://www.opengl.org/sdk/docs/man/html/glBindBuffer.xhtml), etc.) go one step further and store the data on the GPU side: you send it only once, and then just refer to it by a handle. You save bandwidth by not sending the same data over and over at each frame.


---

### Answer by username_3 on 2015-08-05. Score: 6

By using an immediate mode interface (e.g. old style OpenGL glBegin()/glEnd()/glVertex()) you're effectively drip feeding data to the driver one piece at a time. It then has to take that single piece of data, reformat it and pass it on to the hardware (which these days means putting it into a command buffer).

By using a vertex buffer object, you're providing a (hopefully) large block of data to the driver ahead of when it needs to be used. It can perform a number of optimizations (reformatting, placing into video memory) as well as not having to feed the GPU piecemeal.

In practice if you're only drawing a small number of primitives then it probably won't make much difference, however if you're drawing a multi-million triangle mesh then VBOs in video memory are the way to go.


---

