Posted by
Sven Gothel on
Feb 24, 2012; 12:37am
URL: https://forum.jogamp.org/Should-I-call-glDeleteBuffers-to-destroy-VBOs-tp3771162p3771406.html
On 02/23/2012 11:54 PM, gouessej [via jogamp] wrote:
>
>
> Hi
>
> Sometimes I would like to destroy a useless VBO. As far as I know,
> glDeleteBuffer frees the supplied identifier and destroys the data store,
> doesn't it?
The GPU side buffer data and name, yes.
It will also remove an existing binding.
> When using glBufferData, we can provide a direct NIO buffer (or
> null).
Yes, a new 'data store' is being created for the target
of the given size and type. If NULL is passed, no data will
be copied.
> If I destroy this direct NIO buffer after calling glDeleteBuffer, is
> there a risk of crash or something like that?
Should be fine regarding the spec, since the binding is being
removed implicit.
However, if your remove all references to a passed buffer
_and_ the GC hits _and_ you have not removed the binding
_and_ the GPU is about to use the buffer (eg. asynchronous PBO),
then you will probably have a nice crash :)
But this is the expected behavior and can be easily
reproduced by native code, where you free a given buffer
and asynchronous access is 'on the way'.
Based on my 'meditations' below, we could hold the reference
and release it with the glDeleteBuffer / glBufferData.
This would help if the data is being used async., eg PBO.
BTW .. PBO is the only async use-case here, isn't it ?
+++
Note to myself:
All the GPU buffer discussions remind me of fixing
our glMapBuffer()'s NIO cache .. ie. ensuring a proper
user controllable lifecycle is possible.
"A buffer object's mapped data store is automatically unmapped when the buffer
object is deleted or its data store is recreated with glBufferData."
So we may simply be able to reference count the cached NIO buffers
by glMapBuffer(), which are released by either:
- glDeleteBuffer
- glBufferData (which creates a new data store)
Sounds good I guess, so no new entry point is required.
I Will add impl. and unit test in a few days.
~Sven