Question

I just found the following OpenGL specification for ARB_map_buffer_range.

I’m wondering if it is possible to do non-blocking map calls using this extension?

Currently in my application im rendering to an FBO which I then map to a host PBO buffer.

glMapBuffer(target_, GL_READ_ONLY);  

However, the problem with this is that it blocks the rendering thread while transferring the data.

I could reduce this issue by pipelining the rendering, but latency is a big issue in my application.

My question is whether i can use map_buffer_range with MAP_UNSYNCHRONIZED_BIT and wait for the map operation to finish on another thread, or defer the map operation on the same thread, while the rendering thread renders the next frame.

e.g.

thread 1:

map();
render_next_frame();

thread 2:

wait_for_map

or

thread 1:

map();
while(!is_map_ready())
   do_some_rendering_for_next_frame();

What I’m unsure of is how I know when the map operation is ready, the specification only mentions “other synchronization techniques to ensure correct operation”.

Any ideas?

Answer 1

In general, it is not possible to do a “nonblocking map”, but you can map without blocking.

The reason why there can be no “nonblocking map” is that the moment the function call returns, you could access the data, so the driver must make sure it is there, positively. If the data has not been transferred, what else can the driver do but block.
Threads don’t make this any better, and possibly make it worse (adding synchronisation and context sharing issues). Threads cannot magically remove the need to transfer data.

And this leads to how to not block on mapping: Only map when you are sure that the transfer is finished. One safe way to do this is to map the buffer after flipping buffers or after glFinish or after waiting on a query/fence object. Using a fence is the preferrable way if you can’t wait until buffers have been swapped. A fence won’t stall the pipeline, but will tell you whether or not your transfer is done (glFinish may or may not, but will probably stall).
Reading after swapping buffers is also 100% safe, but may not be acceptable if you need the data within the same frame (works perfectly for screenshots or for calculating a histogram for tonemapping, though).

A less safe way is to insert “some other stuff” and hope that in the mean time the transfer has completed.

---

In respect of below comment:
This answer is not incorrect. It isn’t possible to do any better than access data after it’s available (this should be obvious). Which means that you must sync/block, one way or the other, there is no choice.
Although, from a very pedantic point of view, you can of course use GL_MAP_UNSYNCHRONIZED_BIT to get a non-blocking map operation, this is entirely irrelevant, as it does not work unless you explicitly reproduce the implicit sync as described above. A mapping that you can’t safely access is good for nothing.

Mapping and accessing a buffer that OpenGL is transferring data to without synchronizing/blocking (implicitly or explicitly) means “undefined behavior”, which is only a nicer wording for “probably garbage results, maybe crash”.
If, on the other hand, you explicitly synchronize (say, with a fence as described above), then it’s irrelevant whether or not you use the unsynchronized flag, since no more implicit sync needs to happen anyway.