# OpenGL Any performance difference between glMapBuffer() and glMapBufferRange()?

This topic is 395 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Both functions are available since 3.0, and I'm currently using glMapBuffer(), which works fine.

But, I was wondering if anyone has experienced advantage in using glMapBufferRange(), which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?

Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.

##### Share on other sites

Could this be only a safety measure or does it improve performance?

I wouldn't think so..glMapBuffer maps the entire buffer into the address space of the process, while glMapBufferRange  maps only a range. Now, lets consider you have a buffer thats several 100 MBs in size ( just an extreme though possible ), now when you map this buffer using glMapBuffer, whenever the buffer is unmapped, there is the potential that this entire region is now dirty and will have to be flushed back to the source. In reality its a little more involved than this as the mapped memory should be backed by paged memory so at least only dirty pages should be flush ( don't really know if this is how the driver does it ). However, if you have some knowledge of how the buffer is being used, then glMapBufferRange  makes more sense as now you limit how much data that has to be synchronized with the server upon unmapping/invalidation. I have not personally measured and compared the performance of both, but the voice in my head keep telling me that glMapBufferRange  should be more performant..lol. Hope that helps.

##### Share on other sites

Ok, that is what I was thinking. It's the only thing It makes sense to me, at least. Thanks!

1. 1
Rutin
36
2. 2
3. 3
4. 4
5. 5

• 12
• 14
• 9
• 9
• 14
• ### Forum Statistics

• Total Topics
633343
• Total Posts
3011434
• ### Who's Online (See full list)

There are no registered users currently online

×