glBufferSubData vs glMapBufferRange for High-Frequency Dynamic Geometry

Answer to the core question

When you update large or frequently changing vertex buffers, glMapBufferRange with GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_RANGE_BIT is usually faster than glBufferSubData. The performance advantage grows as the number of vertices per frame increases, typically becoming noticeable once you exceed a few kilobytes of data (≈1 KB–10 KB depending on the driver).

For very small updates (tens of bytes) the copy cost of glBufferSubData can be comparable to the overhead of mapping, so it may still be the simpler choice. The exact threshold is hardware‑dependent and should be measured on the target GPU.

Why the difference scales with vertex count

• glBufferSubData copies the supplied data into the buffer object. The driver may need to stall the GPU if the buffer is in use, and the copy size directly influences the stall time.
• glMapBufferRange gives the CPU direct access to the GPU memory region. With GL_MAP_INVALIDATE_RANGE_BIT the driver can discard the previous contents of the mapped range, avoiding a copy and allowing the CPU to write in place.
• When the vertex count grows, the copy cost of glBufferSubData grows linearly, while the mapping overhead remains roughly constant. Thus the ratio of CPU/GPU stalls versus data size improves in favor of mapping.

Typical data‑volume thresholds

Approx. Vertex Count	Data Size (bytes)	Recommended Method
1 – 200 vertices	~200 – 1 600 bytes	Either; glBufferSubData is simpler.
200 – 2 000 vertices	~1 600 – 16 000 bytes	Start favoring glMapBufferRange with invalidate flags.
2 000 + vertices	>~16 000 bytes	Use glMapBufferRange (or persistent mapping if supported).

Steps for a safe, performance‑aware implementation

1. Query OpenGL support:

   const char* ver = (const char*)glGetString(GL_VERSION);
   const char* ext = (const char*)glGetString(GL_EXTENSIONS);
   // Look for GL_ARB_map_buffer_range or GL_VERSION >= 3.0
   

2. Create the VBO with GL_DYNAMIC_DRAW (or GL_DYNAMIC_STORAGE_BIT if you plan persistent mapping):

   GLuint vbo;
   glGenBuffers(1, &vbo);
   glBindBuffer(GL_ARRAY_BUFFER, vbo);
   glBufferData(GL_ARRAY_BUFFER, size, nullptr, GL_DYNAMIC_DRAW);
   

3. For each frame, choose the method based on data size:
   • Small (<1 KB): glBufferSubData(GL_ARRAY_BUFFER, 0, size, dataPtr);
   • Large: void* ptr = glMapBufferRange(GL_ARRAY_BUFFER, 0, size, GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_RANGE_BIT); memcpy(ptr, dataPtr, size); glFlushMappedBufferRange(GL_ARRAY_BUFFER, 0, size); glUnmapBuffer(GL_ARRAY_BUFFER);
4. After unmapping, optionally insert a fence to avoid tearing when the buffer is still being used by the GPU:

   GLsync sync = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
   glClientWaitSync(sync, GL_SYNC_FLUSH_COMMANDS_BIT, GL_TIMEOUT_IGNORED);
   glDeleteSync(sync);
   

5. Check for GL errors each frame during development:

   GLenum err = glGetError();
   if (err != GL_NO_ERROR) { /* handle or log */ }
   

Key assumptions and uncertainties

• Assumes the GPU supports at least OpenGL 3.0 or the GL_ARB_map_buffer_range extension.
• Performance thresholds are approximate; they vary with driver, memory bandwidth, and CPU‑GPU scheduling policies.
• Persistent mapping can be even faster but requires GL_DYNAMIC_STORAGE_BIT and careful synchronization; it is not covered in detail here.

Missing diagnostic detail

To fine‑tune the recommendation for your specific hardware, please provide the OpenGL version and the list of supported extensions (especially whether GL_ARB_map_buffer_range and/or GL_ARB_buffer_storage are available). This will confirm whether persistent mapping is an option and help set the precise data‑volume threshold for switching from glBufferSubData to glMapBufferRange.