What's still not clear to me is whether that presentation and the copy engine stuff applies specifically, in the upload case, to direct upload to texture with glTexSubimage(). Is it the same with all other transfers? For example, the way I normally stream is to buffer objects that are persistently mapped with GL_MAP_PERSISTENT_BIT. If uploading to a buffer, then, is behavior a) same as with the upload to texture case--that is, the transfer is only concurrent with rendering when initiated in another context, b) works along side rendering even if in the same thread (until the appropriate barrier), as seems to be implied in http://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead, or c) always serialized on the GPU side?
For example, in the case of transform and material data, I have those in buffer objects, per shader program, and then render with glMultiDrawElementsIndirectCountARB() once per shader. The buffer objects are treated as triple-sized ring buffers. My rendering thread has been: glClientWaitSync on buffer ranges to be updated, write updated data into mapped buffers, maybe do some other rendering stuff not involving updated data, glMemoryBarrier(GL_BUFFER_UPDATE_BARRIER_BIT), draw calls using the buffer objects, and glFenceSync and advance the triple buffer indexes. I had assumed that the DMA transfer would proceed from after the "write updated data" in that sequence in parallel with any other GL stuff, up until the memory barrier. Is this incorrect? Does it mean that, just like with glTexSubimage(), I'd have to instead move the buffer upload that to another thread/context in order to actually be a DMA transfer that doesn't prevent the GPU from rendering in the meantime? Or is it even that it's never in parallel because only glTexSubimage() triggers the copy engine?
