Posted 11 July 2011 - 08:35 AM
Look, it isn't even necessary some "magical heuristic" or "decision" that the driver is doing on its own, most of the time it simply cannot free resources when you tell it because the rendering pipeline runs asynchronously to your application.
You post commands onto a work queue, and the OpenGL implementation works them off, one by one. Some of your commands set up objects that have dependencies, and the driver must honour these. This is necessary to produce a reliable, reproducable output.
Example: If you create a texture, bind it, render 2 million triangles, unbind the texture, and delete it, what can the driver do? It can delete the texture after having rendered those triangles. This might take dozens of milliseconds. If you delete a texture that is bound to a framebuffer object, it can delete that texture no earlier than all rendering commands which might possibly affect one fragment on this framebuffer have been realized and caches have been flushed.
What's your point? Are you saying the OP is dumb?
I'm sure he knows that when you call glDeleteTextures, you should stop using it.
And to answer the OP, there is nothing you can do. Unless you are on Linux and have access to open source drivers and you want to spend some time on it.
Sig: http://glhlib.sourceforge.netan open source GLU replacement library. Much more modern than GLU.
float matrix, inverse_matrix;
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);