Jump to content
  • Advertisement
Sign in to follow this  
Nanoha

OpenGL Reading buffer data (OpenGL ES 2.0)

This topic is 909 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am hoping to read data from an an array buffer but the function glGetBufferSubData doesn't seem to be available in 2.0: https://www.khronos.org/opengles/sdk/docs/man/

I can do other things to the buffer such as determine it's size but I can't figure out how to read the data which I would think would be possible. I can't see any other functions that seem to do this. Is it possible? If so how do I do it.

 

I can work around this but it involves storing a copy of the buffer at the time of creation and I don't always need to access the buffer's data so I'd like to only do it as and when it is required rather than always.

 

Thanks.

Share this post


Link to post
Share on other sites
Advertisement

Store the copy.

 

Reading back from the GPU is an expensive operation; you'll stall the pipeline and completely break CPU/GPU asynchronous operation.  Doing a readback every frame would be bad enough, but at least you'd have consistently poor performance.  Reading back at arbitrary times is even worse because you'll have uneven framerate and performance spikes.

 

Alternatively find a way to do whatever it is you're trying to do without accessing this data at all.

Share this post


Link to post
Share on other sites

Every time the app is minimized, rotates and similar the display is destroyed along with the OpenGL contexts. As far as I can tell that's just how Android devices work. To get around this all my textures, shaders and buffers are able to recreate themselves rather than having to recreate absolutely everything any time the context is lost. This works out quite well and it does it transparently.

 

The only time I need to do this is if a user destroys the context somehow so it's not a very frequent occurrence at all and I am quite happy if it is slightly slow. Most of my buffers I keep the data out of necessity but I was hoping to do only as and when for some other data that I don't need to store.

Edited by Nanoha

Share this post


Link to post
Share on other sites


The only time I need to do this is if a user destroys the context somehow


How would they do that on Android? Besides the life-cycle activities  that you referred to ( minimize, rotate ), that informs the app when to recreate its resources due to the GL context being invalid, the user does not have access to the OpenGL context, unless you provide them with such access. If the user close/minimized the application, then the app life-cycle activity will notify you accordingly. So I think you are worry about a non existent issue. In any case I'm going to make the same suggestion as mhagain, to store the data. This is the current approach I used in my framework for heavyweights such as mesh data and textures, with shaders reloaded from source. If you are concerned about resource limitation ( memory ), then you can have your app flush cached resources when memory is low ( however, I've had cases where memory is extremely low to the point of Android locking up and restarting the device, but my low memory app life-cycle callback was not invoked ).

Share this post


Link to post
Share on other sites

 


The only time I need to do this is if a user destroys the context somehow


How would they do that on Android? Besides the life-cycle activities  that you referred to ( minimize, rotate ), that informs the app when to recreate its resources due to the GL context being invalid, the user does not have access to the OpenGL context, unless you provide them with such access. If the user close/minimized the application, then the app life-cycle activity will notify you accordingly. So I think you are worry about a non existent issue. In any case I'm going to make the same suggestion as mhagain, to store the data. This is the current approach I used in my framework for heavyweights such as mesh data and textures, with shaders reloaded from source. If you are concerned about resource limitation ( memory ), then you can have your app flush cached resources when memory is low ( however, I've had cases where memory is extremely low to the point of Android locking up and restarting the device, but my low memory app life-cycle callback was not invoked ).

 

The user would destroy it by minimizing (what you termed life-cycle, I didn't have a term for it). I was pointing out it is a fairly rare occurrence. Obviously a user doesn't directly have access to it and I certainly do know when a context is being destroyed, it's at that point I was hoping to read the buffer and back it up ready to recreate.

 

As I said, I do store most of my data already out of necessity, I don't have memory issues I was just looking for an alternative way to approach this but it seems the original idea is the one to stick with.

 

Thanks.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!