5

Is it required that we should unbind a buffer object before deleting it? If I had bound it in a VAO and deleted it without unbinding (binding to 0), what will happen? Will the reference still exist?

public void dispose()
{
    glBindVertexArray(0);
    glDeleteVertexArrays(vaoID);

    glBindBuffer(GL_ARRAY_BUFFER, 0);
    glDeleteBuffers(vboVertID);
    glDeleteBuffers(vboColID);

    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
    glDeleteBuffers(eboID);
}

Is it a good or a bad practice to unbind before deletion?

genpfault
  • 51,148
  • 11
  • 85
  • 139
Sri Harsha Chilakapati
  • 11,744
  • 6
  • 50
  • 91

2 Answers2

5

Is it necessary?

  No.

Is it a good idea?

  Possibly, but not in your current pseudo-code.

The only time you would want to manually unbind a resource in GL prior to deletion is if you have it bound in a separate context. That is because one the criteria for actually freeing the memory associated with a GL resource is that it have a reference count of 0. glDelete* (...) only unbinds an object from the current context prior to putting it on a queue of objects to free.

If you delete it while a VAO that is not currently bound holds a pointer to this buffer, or if it is bound in a completely different OpenGL context from the one you call glDelete* (...) in, then the reference count does not reach 0 before glDelete* (...) finishes. As a result, the memory will not be freed until you actually unbind it from or destroy all VAO / render contexts that are holding references. You will effectively leak memory until you take care of all the dangling references.

In short, glDelete* (...) will always unbind resources from the current context and reclaim any names for immediate reuse, but it will only free the associated memory if after unbinding it the reference count is 0.

In this case, unbinding is completely unnecessary because you are doing so in the same context you call glDeleteBuffers (...) from. This call implicitly unbinds the object you are deleting, so you are doing something redundant. What is more, you already deleted your VAO prior to calling glDeleteBuffers (...) -- when that VAO was deleted, it relinquished all of its pointers and thus decremented the reference count to your buffer.

Andon M. Coleman
  • 42,359
  • 2
  • 81
  • 106
4

Official documentation (https://www.opengl.org/sdk/docs/man/html/glDeleteBuffers.xhtml) says:

glDeleteBuffers deletes n buffer objects named by the elements of the array buffers. After a buffer object is deleted, it has no contents, and its name is free for reuse (for example by glGenBuffers). If a buffer object that is currently bound is deleted, the binding reverts to 0 (the absence of any buffer object).

As for VAO - https://www.opengl.org/registry/specs/ARB/vertex_array_object.txt

(2) What happens when a buffer object that is attached to a non-current
    VAO is deleted?

RESOLUTION: Nothing (though a reference count may be decremented). 
A buffer object that is deleted while attached to a non-current VAO
is treated just like a buffer object bound to another context (or to
a current VAO in another context).
keltar
  • 17,711
  • 2
  • 37
  • 42
  • So is it a good practice or not? The documentation clearly says that it will be automatically made to zero, but is this a good practice? – Sri Harsha Chilakapati May 09 '14 at 13:07
  • Manually dropping binding wouldn't slow your program down, if that's what you asking. But unless there is a bug in GL driver (e.g. let's say one specific driver misbehaves and doesn't delete buffer that is being used), it makes no difference. Although you might want to do it to make things more explicit - I certainly prefer that, but I don't believe there could be 'good/bad' answer here. – keltar May 09 '14 at 13:12
  • I mostly unbind explicitly, particularly for objects that are referenced by other objects. Say I delete a texture that is attached to an FBO, I normally un-attach it from the FBO explicitly before deleting it, even if that's not strictly necessary. As you can tell from the parts of the spec @keltar quoted, the exact rules are fairly complicated. And very inconsistent. For example shader objects follow completely different rules than textures. So I think it's clearer and less error prone to unbind explicitly. – Reto Koradi May 09 '14 at 14:50
  • 1
    @RetoKoradi: The rules are not complicated at all, nor inconsistent. For shaders (which you quoted as example) in particular, deleting them immediately after binding them to a program is a very common idiom. The general rule is that if you "delete" something, the name (integer) becomes invalid, and you can't use it any more under that name. Everything else continues to work. – Damon May 09 '14 at 19:16
  • Moreover, the reason that works is because you only bind shaders to your program for the purpose of linking. Think about it like compiling a C++ program - the compiler will output a bunch of object files, and then link them to produce an executable... you can safely delete the original object files without affecting the operation of the executable. – Andon M. Coleman May 09 '14 at 21:20
  • @Damon: You say that "the general rule is that if you delete something, the name becomes invalid". One example of the inconsistencies I'm talking about is that this rule does not apply to all types of objects. From the spec (emphasis added): "When a shader object or program object is deleted, it is flagged for deletion, but **its name remains valid** until the underlying object can be deleted because it is no longer in use." And that's just a simple example, it gets worse once container objects and multiple contexts get involved. – Reto Koradi May 10 '14 at 18:18
  • @AndonM.Coleman: That comparison does not make much sense. You can call `glDeleteShader()` on the shader while it is attached to a program **before** you link the program, and still link the program. Try deleting an object file in a C++ program before linking, and see if you can still link... – Reto Koradi May 10 '14 at 18:21
  • @RetoKoradi: The shader is still ***attached***, and that is the important point. Try ***detaching*** the shader before deleting it, and then you will have a completely different story. The original situation I was referring to is a bit like deleting the object file from disk after the linker has already loaded it into memory - it will not make a bit of difference. – Andon M. Coleman May 10 '14 at 18:25
  • @RetoKoradi: When you delete a shader object, the name becomes invalid, _for you_. It is inaccessible, deleted, non-existing from your point of view. That does however not mean it ceases to exist for the implementation which is using it. The implementation needs (or _may need_, something else is possible) the shader objects while the program object exists, but that is not your business. – Damon May 11 '14 at 10:05