Official feedback on OpenGL 3.2 thread

[Jon Leech (oddhack)]

Currently sending data to VBO (or any other buffer data object) works like this:
1. Allocate and fill the data
2. Give it to glBufferData
3. glBufferData immediately makes a copy of the data (or sends it directly to the card which is unlikely)
4. When glBufferData returns the data is no longer needed and I can delete or modify it

What I want is to skip #3 to avoid the extra copy done by glBufferData. When using glBufferDataRetained the data is not immediately copied and I cannot change/delete it till OpenGL signals that this data is no longer needed.

OK, I understand now. I think both Sun and Apple have done vendor extensions along these lines, and we have sometimes discussed it as a future use case in the ARB. If we do something like this in a future release I hope it would use sync objects to signal the driver being done with the client buffer, but at present it's not being actively discussed in the group.

[Scribe]

Now I'm just waiting for extension APIs like GLEW to catch up with a major release.

Does anyone know of any APIs like GLEW that allow for the easy handling of extensions in openGL 3.1/3.2?

[GeLeTo]

I think both Sun and Apple have done vendor extensions along these lines, and we have sometimes discussed it as a future use case in the ARB. If we do something like this in a future release I hope it would use sync objects to signal the driver being done with the client buffer, but at present it's not being actively discussed in the group.

Now that we have sync objects, the API to implement this functionality is a no-brainer, so I hope to see it implemented sooner rather than later.

[mfort]

Currently the only way (that I know of) to avoid the extra copying is to use glMapBuffer. And this is another can of worms...

Al least for PBO the glMapBuffer API works fine.
- Mapping buffer is pretty straight forward usage pattern.
- NVIDIA drivers provides good performance.
- Loading the data using glTexImage and similar is async
- Current ARB_sync should fill the missing gap

[Scribe]

In my experience glMapBuffer works very well for the initial loading of any buffer. It's once you start to use that buffer that you suffer synch issues. Certainly it's much faster than multiple calls to glBufferSubData.

[mfort]

yes, calling glBufferData with data set to NULL is painless.

Maybe glCopyBufferSubData (ARB_copy_buffer) for updating subdata can help.

[Stephen A]

C# wrappers for OpenGL 3.2 available here. Also usable by VB.Net, F# and the rest of the Mono/.Net family of languages.

[Y-tension]

Very well done Khronos!!Now let's see some drivers!..NVIDIA (officially) released 3.1 just a few weeks ago.
Again, great release!

[GeLeTo]

Al least for PBO the glMapBuffer API works fine.
- Mapping buffer is pretty straight forward usage pattern.
- NVIDIA drivers provides good performance.
- Loading the data using glTexImage and similar is async
- Current ARB_sync should fill the missing gap

Straightforward usage pattern? Mapping a buffer to update data will most certainly lead to sync issues. Even discarding the buffer with glBufferData(…, NULL) and updating the whole thing might not help. And of course updating the whole buffer migh not be what you want.
glTexImage being async comes at a cost - it will most likely create a copy of your image data right away. And this is what I want to avoid.

In my experience glMapBuffer works very well for the initial loading of any buffer. It's once you start to use that buffer that you suffer synch issues. Certainly it's much faster than multiple calls to glBufferSubData.

This very much depends on the sizes of your data/subdata.
The intricacies of glMapBuffer have been discussed to death. The solution to use buffer objects with sync objects is both elegant and simple.

[mfort]

And of course updating the whole buffer migh not be what you want.

OK

glTexImage being async comes at a cost - it will most likely create a copy of your image data right away. And this is what I want to avoid.

It is hard to argue on this. Only driver guys can tell. But I see no reason why driver needs to make a copy. Probably it starts some DMA to copy the data from system memory to GPU memory.

This very much depends on the sizes of your data/subdata.
The intricacies of glMapBuffer have been discussed to death. The solution to use buffer objects with sync objects is both elegant and simple.

Using buffers for small chunks of data is questionable. The overhead could be larger then using simple memory pointers and letting driver to copy it.

I am using buffers glBufferData(…, NULL) for streaming several hundreds of megabytes per seconds without problems. Of course I am not using SubData. Driver developers should write some performance hints&tips for using smaller chunks with SubData. I can imagine it is not for free.

If you are afraid of copying data in system memory try to use WriteCombined memory and/or SSE instructions with non temporal hint to not pollute cache.