We have a working implementation of vertex double buffering, rendering from one buffer and uploading vertex data to next frame buffer at the same time.

However I am concerned that CPU spends quite a lot of time uploading vertex data. Is the upload blocked by video driver because it's busy with drawing?

Or is it caused by driver's pipeline using the frame N+1 buffers for internal rendering of the frame N-1 frame while the drawing thread is issuing commands for frame N and I should consider switching to triple buffering (however I seriously doubt that it can improve FPS)?

Or should I rather queue the frame N+1 vertex uploads and do them after frame N commands have been issued so that there are no blocks in driver?

It's just that the thread that uploads vertex data also does much other work and is now a bottleneck and I want to offload it as much as possible and definitely don't want to see it blocked by driver.


1 Answer 1


What you need is buffer orphaning. Before uploading new data, you first orphan the old buffer by passing NULL to a glBufferData() call.

This will avoid the synchronization, and the GPU can keep working with the old buffer, if it has to. GL will allocate a new block for the new data, and will take care of the deallocation for you once the GPU is done with it.

Right after the glBufferData with NULL, you call it again with the actual new data.

Doing it this way, both the GPU and CPU can keep doing their thing without having to sync up.

  • \$\begingroup\$ I forgot to mention, we use shared buffers for many surfaces, and only upload changed subdata's \$\endgroup\$ Nov 27, 2017 at 10:25
  • \$\begingroup\$ @AntonDuzenko - depending on how much this data changes, doing a single large upload of absolutely everything may be orders of magnitude faster than doing many smaller uploads - I'd encourage you to profile both approaches. \$\endgroup\$ Nov 27, 2017 at 11:31

You must log in to answer this question.

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