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.
Free GPU Memory after deleting texture
Author
Use gDebugger and see if he reports a memory leak. It is a very good and free OpenGL Debugger.
http://www.gremedy.com/
[size="4"]thank you very much for this great tool i'll use it to test my application and reevaluate the performance
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.
Author
[size="4"]i made a new test today and this time i completed it to the end.The GPU ran out of memory and the program crashed. I think this result doesn't match the theory that says the GPU after deleting texture will free and use this memory when needed,is not it ?!
Author
[size="4"]Problem solved 
.. now generation made once and at resizing we don't delete the old texture and don't generate a new one and the same for FBO .
The rest of command [glBindTexture , glTexImage2D , glBindFramebufferEXT , glFramebufferTexture2DEXT ,....] are called as normal
I'd like to thank every one here spent his time and effort trying to help me , thanks all
.. now generation made once and at resizing we don't delete the old texture and don't generate a new one and the same for FBO .The rest of command [glBindTexture , glTexImage2D , glBindFramebufferEXT , glFramebufferTexture2DEXT ,....] are called as normal
I'd like to thank every one here spent his time and effort trying to help me , thanks all
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
