Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Free GPU Memory after deleting texture


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
14 replies to this topic

#1 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 10 July 2011 - 08:49 AM

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

   glDeleteFramebuffersEXT( 1, TempFrameBuffer);
   glDeleteTextures( 1, Tempimage);

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


Sponsor:

#2 Hodgman   Moderators   -  Reputation: 31938

Like
0Likes
Like

Posted 10 July 2011 - 08:52 AM

i noticed that the glDeleteTextures doesn't free the GPU memory that resulted in accumulated GPU memory leakage at run-time

What method did you use to determine this?

#3 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 10 July 2011 - 10:00 AM

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

#4 Aks9   Members   -  Reputation: 918

Like
0Likes
Like

Posted 10 July 2011 - 11:03 AM

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.

#5 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 10 July 2011 - 02:21 PM

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.


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


#6 V-man   Members   -  Reputation: 805

Like
0Likes
Like

Posted 10 July 2011 - 06:00 PM

As Aks9 already explained
http://www.opengl.org/wiki/FAQ#Memory_Usage
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

#7 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 10 July 2011 - 06:15 PM

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 !!!

#8 Hodgman   Moderators   -  Reputation: 31938

Like
0Likes
Like

Posted 10 July 2011 - 06:25 PM

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 !!!

...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?

#9 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 10 July 2011 - 06:44 PM

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 ?


#10 GothSeiDank   Members   -  Reputation: 156

Like
1Likes
Like

Posted 10 July 2011 - 06:54 PM

Use gDebugger and see if he reports a memory leak. It is a very good and free OpenGL Debugger.

http://www.gremedy.com/
If you say "pls", because it is shorter than "please", I will say "no", because it is shorter than "yes"
http://nightlight2d.de/

#11 samoth   Crossbones+   -  Reputation: 5037

Like
0Likes
Like

Posted 11 July 2011 - 02:03 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.

#12 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 11 July 2011 - 03:09 AM

Use gDebugger and see if he reports a memory leak. It is a very good and free OpenGL Debugger.

http://www.gremedy.com/


thank you very much for this great tool i'll use it to test my application and reevaluate the performance

#13 V-man   Members   -  Reputation: 805

Like
0Likes
Like

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.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

#14 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 11 July 2011 - 09:19 AM

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 ?!


#15 Ahmed Ali   Members   -  Reputation: 100

Like
0Likes
Like

Posted 12 July 2011 - 03:42 AM

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






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS