Calling glMapBuffer(GL_READ) when a GL program is active?


Is it allowed to call glMapBufferRange for reading a SSBO buffer, when a GL program is active?
Here’s what I’m doing:

  1. glUseProgram(prog id)
  2. issue several commands, writing to a SSBO
  3. call glMemoryBarrier(ALL), then create and then wait for a fence.

At this point I can:
A) call glUseProgram(0) and read my buffer with glMapBuffer
B) just read my buffer with glMapBuffer

I experience 1282 errors when resuming issuing GL commands after reading the buffer, but just on nVidia hardware, and just with recent drivers.
When I have no GL program active when calling glMapBuffer, I have no error.

Thank you,

The specification says:

IOW, if you want to be able to issue commands which read or write a buffer while it’s mapped, the buffer must be allocated using glBufferStorage with the MAP_PERSISTENT_BIT flag, and must be mapped using glMapBufferRange with that flag. You can’t use glBufferData or glMapBuffer because they don’t support the required flag.

Thanks for your insight.

However, I am not trying to read from or write to the buffer through a GL program while this buffer is mapped.
I am reading to a buffer while a GL program is still active, but I know for sure all GL commands have completed before my glMapBuffer call is executed, since I used a fence and issued a glmemorybarrier(All). I am not unbinding the GL program though.
Is this wrong?

Even without the fence, glMapBuffer should wait for any commands using that buffer to complete. Just be sure to unmap it before issuing any commands which could access it.

If you’re already doing that, then it sounds like a driver bug.

Thanks for your answer. I agree with you.
Might be a driver thing, although I need to triple check. The only thing a bit odd that I am doing is that I do not always bind my buffer to GL_SHADER_STORAGE - I sometimes bind it to another buffer target (GL_TEXTURE_BUFFER) - the buffer itself is never bound at two different buffer targets at the same time, but maybe the driver does not like that.