GL_EXT_buffer_storage support?

NVIDIA is ratifying this extension to work with OpenGL ES 3.x and they are exposing it with their latest video drivers (Which are only available on the X1 development platform).

My application takes advantage of the desktop OpenGL variant(GL_ARB_buffer_storage) to dramatically reduce CPU overhead from calling in to the OpenGL API.

This also allows us to easily decode our data directly in to GPU buffers while rendering from it with the GPU. Making sure we don't overwrite information in flight by having multiple frames of data of course. For UMA systems like those that run Mali GPUs this is a big win for us, especially with how little bandwidth is available on these compared to what we have available to us on desktops.

Hopefully you'll think about implementing support for this extension.

  • I also going with the assumption that persistent mapping is what the op is interested in..Though its a nice feature to have, developers have been doing without persistent mapping before and after its introduction. The explanation giving above works fine as I have used them myself, using a ring buffer or orphaning won't be necessarily slower than a persistent mapping( mileage may vary and one would have to profile both method to see ). A chapter in OpenGL Insight covers experiments done with a few of the strategy listed above ( but for OpenGL not OpenGL ES ) and you would be surprised. Persistent mapping is not a panacea either as one would still have to worry about synchronization and that also add overhead. Last but not least, I don't think designing an application around a single extension is good design practice as now you are limiting the number of device the application can run on, unless the core of the design is to run on just system X.

Reply Children
No Data