I am doing instancing in opengl using vbos to store the per frame data (like matrix, color tint, etc.). I have a vbo per vao to store the instance data. Then each render batch (use same shader, vao etc.) in the frame I use the glBufferData call to update the data. However I realised if the same vao occurs in more then one render batch, i use the same vbo that might have already been used for a previous render batch.
It hasn't seemed to matter, , however thought it might just be reading out of invalid memory, but from reading this , Opengl generates a new one until the frame is over (I call SwapBuffers).
I was wondering if this is a bad idea to be relying on opengl to do this and should I be managing a list of available vbos in a linked list or something like this? something that I guess is happening behind the scenes in Opengl.
It hasn't seemed to matter, , however thought it might just be reading out of invalid memory, but from reading this , Opengl generates a new one until the frame is over (I call SwapBuffers).
Whenever you see either of these, think of it as a directive to OpenGL to 1) detach the old block of storage and 2) give you a new block of storage to work with, all behind the same buffer handle. The old block of storage will be put on a free list by OpenGL and reused once there can be no draw commands in the queue which might be referring to it (e.g. once all queued GL commands have finished executing).
I was wondering if this is a bad idea to be relying on opengl to do this and should I be managing a list of available vbos in a linked list or something like this? something that I guess is happening behind the scenes in Opengl.
Edited by Oliver Marsh
on
Yes, glBufferData internally allocates new memory and uploads data to this place. Old memory is kept alive until all previous commands referencing this memory are finished.
It is ok to rely on OpenGL to do this. Unless you are not satisfied with performance. Then to optimize for your usage patterns you can start handling buffer usage manually. Do you need to have multiple buffers at all? You can have only one buffer and update only parts of it (and tell GL which parts are updated). Or you could have simple persistently mapped buffer - just update pointer and never touch buffer handle at all.
It is ok to rely on OpenGL to do this. Unless you are not satisfied with performance. Then to optimize for your usage patterns you can start handling buffer usage manually. Do you need to have multiple buffers at all? You can have only one buffer and update only parts of it (and tell GL which parts are updated). Or you could have simple persistently mapped buffer - just update pointer and never touch buffer handle at all.
thanks martins, when you say use one buffer for everything does that mean one vbo is shared with potentially lots of vaos?
Edited by Oliver Marsh
on
I believe he means that you would just have a single VBO on the OpenGL side that is large enough to store all your information for various purposes. So basically you would only update and use sections of this VBO at a time, kind of like treating it as a common GPU side memory space. That's my understanding at least.
yes i think i understand, does this work better if i know how much space i’ll need before hand? (i guess i could just resize bigger, and keep it at the high water mark).
i’m going to try and see if this scheme will work: one globally shared vbo for instance data, using glbufferdata to handle the reuse, then each render batch will use this vbo for their instance dats.
i’m going to try and see if this scheme will work: one globally shared vbo for instance data, using glbufferdata to handle the reuse, then each render batch will use this vbo for their instance dats.