Should I call glDeleteBuffers to destroy VBOs?

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? When using glBufferData, we can provide a direct NIO buffer (or null). If I destroy this direct NIO buffer after calling glDeleteBuffer, is there a risk of crash or something like that?

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

Thank you for this very complete explanation. I don't use PBO, I don't do anything explicitly asynchronous with Ardor3D. I don't use glMapBuffer in Ardor3D but I use it in some other programs. The most important thing for me is that no cache keeps references on direct NIO buffers passed to glBufferData once I call glDeleteBuffers on their VBOs.

@Sven Do you put the reference of a direct NIO buffer used with glBufferData into a cache too? If so, it will prevent my system from working.

On 02/24/2012 07:07 PM, gouessej [via jogamp] wrote:
>
>
> @Sven Do you put the reference of a direct NIO buffer used with glBufferData
> into a cache too? If so, it will prevent my system from working.
>

No.
User provided buffers are not cached/referenced (not yet).

However, I fail to see why this should break your code,
ie. if we remove the reference at the appropriate GL call
(Delete/BufferData(on-same-target))

But .. it was a brainstorming .. pls explain why this could
break your code. Thx.

~Sven

If you always remove the reference of the buffer from your cache when calling glUnmapBuffer & glDeleteBuffers, there won't be any problem, otherwise the cleaner might be called several times (once by me, once again later when your cache is eventually cleared) even on different threads. In my case, I will always call all cleaners on the thread used to perform the rendering.

Riven reminded me that the use of these cleaners is possible only in signed applications, I was almost sure of that.

Edit.: Do you agree with that statement?
http://www.java-gaming.org/topics/a-general-approach-for-nio-buffer-pooling/25537/msg/224092/view.html#msg224092
"Yes, it can crash the entire process. This is why libraries like JOGL and LWJGL keep a reference to the buffer you passed to those methods. Before that was done, the GC could free that memory, resulting in an access violation in the driver."

Hi

JMonkeyEngine 3 and my game (using Ardor3D) now try to release the native memory used by direct NIO buffers. Sven, does JOGL keep references on such buffers even after calling glDeleteBuffers?

On 05/17/2013 02:46 PM, gouessej [via jogamp] wrote:
> Hi
>
> JMonkeyEngine 3 and my game (using Ardor3D) now try to release the native
> memory used by direct NIO buffers. Sven, does JOGL keep references on such
> buffers even after calling glDeleteBuffers?

Just in the realms of our GLArrayData* instances, not in general,
i.e. low level API calls.

~Sven

Ok. I feared we kept a reference on them to prevent their garbage collection at an inappropriate moment as someone claimed that's how our competitor does.