If you think about this conceptually, you'll see that all that mapping and filling a PBO does is map and fill a PBO - it does absolutely nothing to a texture object and you must handle that yourself in your own code.

The way to do this is via a glTexImage or glTexSubImage call, with the last (data) parameter handled in the same way as for other buffer object types; i.e. rather than being a pointer to system memory it is overloaded to function as an offset into the currently bound PBO.

So, to update a texture, you need to do the following:

glBindBuffer (GL_PIXEL_UNPACK_BUFFER, pboid); byte *ptr = glMapBuffer (GL_PIXEL_UNPACK_BUFFER, ...); // fill ptr here glUnmapBuffer (GL_PIXEL_UNPACK_BUFFER); // use while PBO is still bound, assumes GL_TEXTURE_2D and offset 0 glBindTexture (GL_TEXTURE_2D, textureid); glTexSubImage2D (GL_TEXTURE_2D, ..., (void *) 0); glBindBuffer (GL_PIXEL_UNPACK_BUFFER, 0); 

Regarding your specific use case, I suspect that this is not going to give you great performance. PBOs are really most useful where you can take advantage of the asynchronous nature of the transfer, i.e. by using the texture for drawing a frame or two after the texture is filled from the PBO. Since you're using the texture in the same frame you don't get that and OpenGL may need to stall until the transfer completes, as well as incurring the extra overhead of binding and mapping a PBO.

Using glMapBuffer itself is also likely to be a suboptimal path; see this link for a further discussion (it's somewhat out of date but I believe still relevant). You will likely obtain a better result with glMapBufferRange if your driver supports it.

What I would do instead of all this however is just use stock glTexSubImage2D with a system memory pointer as source, and see how that performs. You may well find (particularly with a texture that's only 512X512X1) that it's more than fast enough for you (the worst case should be no worse than what I've just described above, your driver may very well have it's own optimal path for replacing the entire texture rect (it could double-buffer internally, for example), or you could double-buffer the texture yourself if needed), and that you don't need to consider any alternate options.

If you think about this conceptually, you'll see that all that mapping and filling a PBO does is map and fill a PBO - it does absolutely nothing to a texture object and you must handle that yourself in your own code.

The way to do this is via a glTexImage or glTexSubImage call, with the last (data) parameter handled in the same way as for other buffer object types; i.e. rather than being a pointer to system memory it is overloaded to function as an offset into the currently bound PBO.

So, to update a texture, you need to do the following:

glBindBuffer (GL_PIXEL_UNPACK_BUFFER, pboid); byte *ptr = glMapBuffer (GL_PIXEL_UNPACK_BUFFER, ...); // fill ptr here glUnmapBuffer (GL_PIXEL_UNPACK_BUFFER); // use while PBO is still bound, assumes GL_TEXTURE_2D and offset 0 glBindTexture (GL_TEXTURE_2D, textureid); glTexSubImage2D (GL_TEXTURE_2D, ..., (void *) 0); glBindBuffer (GL_PIXEL_UNPACK_BUFFER, 0); 

Regarding your specific use case, I suspect that this is not going to give you great performance. PBOs are really most useful where you can take advantage of the asynchronous nature of the transfer, i.e. by using the texture for drawing a frame or two after the texture is filled from the PBO. Since you're using the texture in the same frame you don't get that and OpenGL may need to stall until the transfer completes, as well as incurring the extra overhead of binding and mapping a PBO.

Using glMapBuffer itself is also likely to be a suboptimal path; see this link for a further discussion (it's somewhat out of date but I believe still relevant - especially since the advent of glMapBufferRange (see next point) I believe that glMapBuffer is not likely to be anything of a candidate for optimization or sensible implementation for driver writers). You will likely obtain a better result with glMapBufferRange if your driver supports it.

What I would do instead of all this however is just use stock glTexSubImage2D with a system memory pointer as source, and see how that performs. You may well find (particularly with a texture that's only 512X512X1) that it's more than fast enough for you. The worst case should be no worse than what I've just described above, your driver may very well have it's own optimal path for replacing the entire texture rect (it could double-buffer internally, for example), or you could double-buffer the texture yourself if needed. You shouldn't need to consider any alternate options unless this process proves to be a definite and measurable bottleneck.