Originally asked this on Computer Graphics, but it might fit in better here.

In my project, for convenience I would like to use many buffers. Many buffers in my case means 50-100 terrain patches represented by buffers with vertex coordinates, normals, indices and maybe color. The magnitude of data would be, let's say 10^4 floats per buffer. Some of this data can be shared between each terrain patch, f.ex. xz-coordinates and indices.

During the rendering loop, some terrain patches will be updated. Which means that for certain buffers I call glBufferSubData() for the whole buffer.

My question is; are there any pros/cons, performance wise between these two methods:

1) Controlling my data in many buffers (50-100), thus letting me call glBufferSubData on a complete buffer when needed.

2) Controlling my data in fewer (5-20) buffers, with more data in each. But then having to set up a system where I need to call glBufferSubData on smaller portion of a buffer. (Which leads to a more complex design in my case).


1 Answer 1


Having fewer buffers is usually better performance-wise, because it avoids overhead from the driver. The approaching-zero-driver-overhead technique makes use of very large buffers that the program manages itself.

The system to manage the small portions of a buffer shouldn't be too complex. Fo each portion, you just need an offset and a size.

  • \$\begingroup\$ Yes I'll probably figure out a way to set it up with fewer buffers. But the reason for less performance is that more draw calls are required or just the fact that the data is split in many buffers? \$\endgroup\$
    – remi000
    Commented Jan 29, 2017 at 21:57
  • \$\begingroup\$ The draw calls, generally. However, as an aside, depending on what you're making, it might not be worth the hassle. 100 buffers is still not that much, relatively speaking. \$\endgroup\$ Commented Jan 29, 2017 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .