Sign in to follow this  
AhmedAli

Free GPU Memory after deleting texture

Recommended Posts

AhmedAli    100
[size="4"]hi every body,
I'm using FBO in my application.. at some points My app rendering resize and i need to delete and recreate the FBO by the new dims and data .. it works fine but i noticed that the glDeleteTextures doesn't free the GPU memory that resulted in accumulated GPU memory leakage at run-time. this is my code to delete the FBO and its texture

[code]
glDeleteFramebuffersEXT( 1, TempFrameBuffer);
glDeleteTextures( 1, Tempimage);
[/code]

can you find what i missed? are there any method to free the GPU memory after deleting texture?
thanks in advance for your help :)[/size]

Share this post


Link to post
Share on other sites
AhmedAli    100
[size="4"]i used GPUShark app (downloaded from www.geeks3d.com )to monitor the GPU resources at run-time .. it's really helpful but the graphics card driver should be updated to give accurate results [/size]

Share this post


Link to post
Share on other sites
Aks9    1499
Do you expect the memory will be deallocated at the same moment you call glDeleteTextures()? It is a wrong assumption.

Drivers allocate/deallocate memory at the most suitable moment. Try extensively to allocate/deallocate textures to see whether you will run out of memory.

Share this post


Link to post
Share on other sites
AhmedAli    100
[quote name='Aks9' timestamp='1310317394' post='4833389']
Do you expect the memory will be deallocated at the same moment you call glDeleteTextures()? It is a wrong assumption.

Drivers allocate/deallocate memory at the most suitable moment. Try extensively to allocate/deallocate textures to see whether you will run out of memory.
[/quote]

[size="4"]The GPU memory usage is increasing by a fixed value for every recreated texture and it is increasing continuously without decay .. by this rate it just about time to run out of memory but this-based on my calculations- will happen
[/size]

Share this post


Link to post
Share on other sites
AhmedAli    100
[size="4"] OK , but do you find it reasonable that there is noway to free the the allocated GPU memory which is possible and a very simple operation in the system RAM !!![/size]

Share this post


Link to post
Share on other sites
Hodgman    51223
[quote name='Ahmed Ali' timestamp='1310343342' post='4833529']
[size="4"] OK , but do you find it reasonable that there is noway to free the the allocated GPU memory which is possible and a very simple operation in the system RAM !!![/size]
[/quote]...but the driver might be planning on re-using that allocated memory. If it's holding onto an allocation, so that it can re-use it at some point, or if it "frees" the allocation (so that it can be re-used at some point), what's the difference?

Share this post


Link to post
Share on other sites
AhmedAli    100
[size="4"]Yesterday i tested my application it continued for about 2 hours and the GPU memory usage increased until it reached about 75% without decay .. Although i'm deleting the old textures every about 10seconds. Do you think that the system didn't reached that point at which the memory should be reused? Is that safe ?
[/size]

Share this post


Link to post
Share on other sites
NicoG    172
Use gDebugger and see if he reports a memory leak. It is a very good and free OpenGL Debugger.

[url="http://www.gremedy.com/"]http://www.gremedy.com/[/url]

Share this post


Link to post
Share on other sites
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.

[u]Example:[/u] 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 [i]after [/i]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 [i]possibly [/i]affect one fragment on this framebuffer have been realized and caches have been flushed.

Share this post


Link to post
Share on other sites
AhmedAli    100
[quote name='NicoG' timestamp='1310345689' post='4833541']
Use gDebugger and see if he reports a memory leak. It is a very good and free OpenGL Debugger.

[url="http://www.gremedy.com/"]http://www.gremedy.com/[/url]
[/quote]

[size="4"]thank you very much for this great tool i'll use it to test my application and reevaluate the performance [/size]

Share this post


Link to post
Share on other sites
V-man    813
[quote name='samoth' timestamp='1310371406' post='4833623']
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.

[u]Example:[/u] 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 [i]after [/i]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 [i]possibly [/i]affect one fragment on this framebuffer have been realized and caches have been flushed.
[/quote]

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.

Share this post


Link to post
Share on other sites
AhmedAli    100
[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 ?!
[/size]

Share this post


Link to post
Share on other sites
AhmedAli    100
[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

[/size]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this