Opengl VBO是否应该在调用glDeleteBuffers之前解除绑定？

是否需要在删除缓冲区对象之前解除其绑定？如果我在VAO中绑定了它，并在不解除绑定（绑定到0）的情况下删除了它，会发生什么？引用是否仍然存在

public void dispose（）
{
glBindVertexArray（0）；
glDeleteVertexArrays（vaoID）；
glBindBuffer（GL_数组_BUFFER，0）；
glDeleteBuffers（vboVertID）；
glDeleteBuffers（vboColID）；
glBindBuffer（GL_元素_数组_缓冲区，0）；
gld（eboID）；
}

删除前解除绑定是一种好做法还是一种坏做法？

官方文档（）说：

glDeleteBuffers删除由数组缓冲区元素命名的n个缓冲区对象。删除缓冲区对象后，该对象没有任何内容，其名称可以自由重用（例如通过glGenBuffers）如果删除了当前绑定的缓冲区对象，则绑定将恢复为0（没有任何缓冲区对象）。

至于VAO-

有必要吗？ 否。

这是个好主意吗？ 可能，但不在当前的伪代码中。

---

在删除之前，您希望在GL中手动解除资源绑定的唯一时间是在单独的上下文中进行绑定。这是因为实际释放与GL资源关联的内存的标准之一是其引用计数为0

glDelete*（…）

在将对象放入要释放的对象队列之前，仅从当前上下文中解除对象的绑定

如果在当前未绑定的VAO持有指向此缓冲区的指针时删除它，或者如果它绑定在与中调用的

glDelete*（…）

完全不同的OpenGL上下文中，则在

glDelete*（…）

完成之前，引用计数不会达到0。因此，内存将不会被释放，除非您实际将其从保存引用的所有VAO/render上下文中解除绑定或销毁。在处理所有悬空引用之前，您将有效地泄漏内存

简而言之，

glDelete*（…）

将始终从当前上下文中解除资源绑定，并回收任何名称以立即重用，但只有在解除绑定后引用计数为0时，它才会释放关联内存

---

---

在这种情况下，取消绑定是完全不必要的，因为您在调用

glDeleteBuffers（…）

的同一上下文中执行此操作。这个调用隐式地解除您正在删除的对象的绑定，因此您正在做一些冗余的事情。更重要的是，在调用

glDeleteBuffers（…）

之前，您已经删除了VAO——删除该VAO时，它放弃了所有指针，从而减少了对缓冲区的引用计数。

我认为任何要求缓冲区有效的操作都会导致GLError@ratchetfreak我不明白你的意思。请解释一下。解绑被认为是一种好的做法吗？那么这是否是一种好的做法呢？文档清楚地说明它将自动设置为零，但这是一种好的做法吗？如果您是这样要求的话，手动删除绑定不会降低程序的速度。但是，除非GL驱动程序中存在错误（例如，假设某个特定的驱动程序行为不正常，并且没有删除正在使用的缓冲区），否则没有任何区别。虽然您可能希望这样做使事情更加明确-我当然更喜欢这样做，但我不相信这里会有“好/坏”的答案。我主要是显式解除绑定，特别是对于被其他对象引用的对象。假设我删除附加到FBO的纹理，通常在删除它之前从FBO显式取消附加它，即使这不是严格必要的。从引用的spec@keltar部分可以看出，确切的规则相当复杂。而且非常不一致。例如，着色器对象遵循与纹理完全不同的规则。因此，我认为显式解除绑定更清晰，更不容易出错。@RetoKoradi：规则一点也不复杂，也不矛盾。特别是对于着色器（您引用了作为示例），在将它们绑定到程序后立即删除它们是一种非常常见的习惯用法。一般规则是，如果您“删除”某个内容，则名称（整数）将无效，并且您不能在该名称下再使用它。其他一切都在继续工作。此外，之所以有效，是因为您仅将着色器绑定到程序以进行链接。想想它，比如编译一个C++程序——编译器会输出一堆对象文件，然后链接它们，产生一个可执行文件…您可以安全地删除原始对象文件，而不会影响可执行文件的操作。

(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).