PDA

View Full Version : TBO streaming



Axelander
01-23-2015, 10:45 AM
Hi.
I'm targeting OpenGL 3.3. Basically, I want to efficiently stream data to TBO (texture buffer object aka buffer texture).
My data is glBufferSubData-ready (it's an array in app memory). I need to do about a dozen of variable-sized uploads per frame. There will be no more than ~1 MB of data uploaded per frame totally.
I want to stream data as efficiently as possible (Bandwidth pressure will be low, probably, so I worry mostly about CPU-GPU syncs and client/server syncs in threaded drivers).
So far I've read many forums, slides (Nvidia's and Valve's) and this two classical sources:
https://www.opengl.org/wiki/Buffer_Object_Streaming
"OpenGL Insights: Asynchronous Buffer Transfers"
But now I'm confused, as there are many contradicting recommendations. Also, TBO's seem somewhat "special".

So I have two questions:

1) Can someone explain to me this two fragments from GL_ARB_texture_buffer_object spec (especially in the context of efficient data streaming)?

(5) What happens if a buffer object is deleted or respecified when bound to a buffer texture?

RESOLVED: BufferData is allowed to be used to update a buffer object that has already been bound to a texture with TexBuffer. The update to the data is not guaranteed to affect the texture until next time it is bound to a texture image unit. When DeleteBuffers is called, any buffer that is bound to a texture is removed from the names array, but remains as long as it is bound to a texture. The buffer is fully removed when the texture unbinds it or when the texture buffer object is deleted.

Reconsidered: Container-style objects (FBO, VAO) may not be shared because of the race conditions or undefined behavior which coukd result when a context modifies the attachments of an object currently in use by a separate context. This restriction can not apply to textures because they have always been sharable. In order to preserve the goals of the non-shared container behavior, calling TexBuffer makes a permanent association between texture and the data store of the buffer.
If the buffer itself is subsequently modified (e.g. BufferData or DeleteBuffers), the data store of the buffer is disassociated from the buffer object and remains valid for the lifetime of the associated texture.

(6) Should applications be able to modify the data store of a buffer object while it is bound to a buffer texture?

RESOLVED: An application is allowed to update the data store for a buffer object when the buffer object is bound to a texture.

Reconsidered: The contents of the data store may be modified, however any operation which attempts to redefine the data store causes the original data store to be disassociated from the buffer, or "orphaned". See issue (5) above for additional information.


2) Can someone (with real experience) recommend me efficient approach to TBO streaming (I'dont mind writing several codepathes for different vendors)?

Alfonse Reinheart
01-23-2015, 11:54 AM
Can someone explain to me this two fragments from GL_ARB_texture_buffer_object spec (especially in the context of efficient data streaming)?

They don't mean anything. The issues section of an extension specification is nice, but it doesn't define the actual behavior. That's defined by the spec itself.

I can't find anything in the specification (either the extension or GL 4.5) that states that reallocating the storage for a buffer object will not be reflected in any buffer textures that the buffer object is attached to. So you ought to be able to reallocate those buffers freely.

Not that you should. Invalidate, yes. Reallocate (ie: using a different size, etc), no. But that's just for general reasons, nothing specifically about buffer textures.