Passing the buffer mapped pointer to glTex (Sub) Image2D. Is texture loading asynchronous?
Suppose I am displaying a buffer, with
map_ptr = glMapBuffer (..)
(The goal shouldn't matter, but let it be GL_TEXTURE_BUFFER
)
Then I load the texture data with
glTexImage2D(..., map_ptr)
passing in map_ptr as my texture data. (I have no binding GL_PIXEL_UNPACK_BUFFER
)
Semantically, it has to do with copying data from the buffer store to the texture object's data store, and the operation can be done on a DMA copy with the GPU.
But what is really going on? Is the data completely copied to the GPU, or is the CPU reading and caching the mapped memory and then writing back to the GPU in a separate location in the GPU memory? That is, is the copy asynchronous, or is the processor synchronously coordinating the copy using processor cycles?
Is the answer to this implementation dependent? It depends on whether it is enough for the OpenGL driver to be smart enough to recognize the data pointer passed to the glTexImage2D
graphics pointer with the GPU and that there is no need to go back to the CPU? If so, how common is this feature in common drivers today?
Also, what about the behavior for the OpenCL buffer whose memory has been mapped, i.e .:
map_ptr = clEnqueueMapBuffer(..)
(mapped memory in OpenCL format)
and map_ptr
transferred glTexImage2D
?
source to share
What you are doing there is just undefined behavior as per the spec .
Pointer values returned by MapBufferRange cannot be passed as a value parameter to GL commands. For example, they cannot be used to point to an array of pointers or to point or query image data for pixels or textures; such actions produce undefined results, although implementations may not test this behavior for performance reasons.
Let me quote from the GL_ARB_vertex_buffer_object extension specification , which originally represented buffer objects and display operations (emphasis mine):
Are any GL commands allowed when displaying at least one buffer object?
RESOLVED: NO. In general, applications can use whatever GL commands they want when displaying the buffer. However, several other application restrictions apply: the application should not attempt to retrieve original data from, or lose data in, the currently mapped buffer. In addition, the application cannot use the pointer returned by Map as an argument to the GL command. (Note that this latter limitation is unlikely to be enforced in, but it violates reasonable expectations about how the extension should be used, and it doesn't seem to be a very interesting usage model. Maps are for the user, not GL.)
source to share