Question

Is it possible to glUnmapBuffer a GL_STREAM_DRAW pixel-buffer-object and still keep the data pointed to by the pointer returned previously by glMapBuffer valid for read-only operations using SSE 4.1 streaming loads?

If not, is there any technical reason for this? Or was this “feature” just left out?

Answer 1

The purpose of map and unmap is to say “I need a pointer to this.” and “I’m finished using the pointer to this.” That’s what the functions do.

When you unmap a buffer, the driver is now free to:

1. Copy the data you wrote (if you wrote anything) to the buffer object, if the mapped pointer is not a direct pointer to that buffer.
2. Move the buffer object around in GPU memory, if the mapped pointer is a pointer to that object.

Remember: mapping a pointer does not have to return an actual pointer to that buffer. It simply returns a pointer that when read, will have the data stored in that buffer, and when written, the written bytes will be transferred into the buffer upon unmapping.

Furthermore, the only reason to do what you’re suggesting is because you want to read the data in the buffer. Well, since you just mapped the buffer (presumably for writing, or else you wouldn’t have unmapped it), you know what’s in it. If you needed CPU access to it, you should have just stored the data locally; you’ll get a lot more reliable access to it that way.

And if you do another pixel transfer, reading from that pointer it means that OpenGL would have to execute a synchronization, because the whole point of PBO is asynchornous transfer. That is, when you execute glReadPixels or whatever, OpenGL can wait to actually finish this operation until you map the buffer or use glGetBufferSubData.

But if the buffer is mapped for reads, then OpenGL doesn’t know when you’re going to read from it (since it can’t tell when you read from a pointer). So OpenGL can’t guarantee the storage within it. In short: undefined behavior. You could get anything at that point.

So what you’re talking about doesn’t make sense.