Memory issue

Your computer has a series of caches to speed things up. It is possible the OpenGL library is caching the graphics memory under the (usually reasonable) assumption that you'll be requesting more soon (or you'll shut down, in which case it doesn't matter if it is cached briefly). Or perhaps the OS is doing something similar.

In other words, don't expect a 1 for 1 mapping between the allocation and deallocation of resources in your application and any external tool to measure the resource.

However, this assumes you are doing it right. Are you sure that you are deleting the correct texture identifiers? Are you sure you haven't deallocated this texture before?

Your computer has a series of caches to speed things up. It is possible the OpenGL library is caching the graphics memory under the (usually reasonable) assumption that you'll be requesting more soon (or you'll shut down, in which case it doesn't matter if it is cached briefly). Or perhaps the OS is doing something similar.

In other words, don't expect a 1 for 1 mapping between the allocation and deallocation of resources in your application and any external tool to measure the resource.

However, this assumes you are doing it right. Are you sure that you are deleting the correct texture identifiers? Are you sure you haven't deallocated this texture before?

Please find my code snippet below

GLuint uiTexID[500];
for( int i=0; i<500; i++)
{
// Get an free texture ID
int iTextureWidth = 64;
int iTextureHeight = 64;
glGenTextures(1, &uiTexID);
//Allocate memory for the texture data.
GLuint* pubData = new GLuint[4 * iTextureWidth * iTextureHeight];
// init memory
memset(pubData, 0, 4 * iTextureWidth * iTextureHeight);
// bind the text
glBindTexture( GL_TEXTURE_2D, uiTexID);

// Copy to texture
// Set texture parameters
glTexParameterx(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);

glTexParameterx(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);


glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, iTextureWidth, iTextureHeight,
0, GL_RGBA, GL_UNSIGNED_BYTE, pubData );

// free memory
delete [] pubData;
// free texture
}
CheckMemory();
for( int i=0; i<500; ++i)
{
glDeleteTextures(1, &uiTexID);

}
CheckMemory();

Memory Results:

BEFORE LOADING TEXTURES
=========================
1. MEMORY LOAD = 20 percent
2. TOTAL PHY MEM = 169385984 bytes
3. AVAIL PHY MEM = 136916992 bytes
4. TOTAL VIRTUAL MEM = 1073741824 bytes
5. AVAIL VIRTUAL MEM = 1063190528 bytes

AFTER LOADING TEXTURES
=========================
1. MEMORY LOAD = 25 percent
2. TOTAL PHY MEM = 169385984 bytes
3. AVAIL PHY MEM = 127725568 bytes
4. TOTAL VIRTUAL MEM = 1073741824 bytes
5. AVAIL VIRTUAL MEM = 1052311552 bytes

AFTER DELETING TEXTURES
=========================
1. MEMORY LOAD = 25 percent
2. TOTAL PHY MEM = 169385984 bytes
3. AVAIL PHY MEM = 127725568 bytes
4. TOTAL VIRTUAL MEM = 1073741824 bytes
5. AVAIL VIRTUAL MEM = 1052311552 bytes
If you notice available physical memory is unchanged even after deleting the textures.Please help me out in this,what is happening in glDeleteTextures,Is it any heap problem.

What is [font="Lucida Console"]CheckMemory[/font]?

What is [font="Lucida Console"]CheckMemory[/font]?

Its my code to check the memory status.

1) Physical memory is highly unlikely to ever be freed by your actions. It is managed by the OS. The OS is going to cache anything it can, and be as lazy as it can about freeing stuff incase it is needed again.
2) Your virtual memory might not go up either, as the drivers are free to also be lazy about their reclamation of memory. What if you allocate another texture right away? Opengl could be keeping those pages around from the last texture to avoid expensive frees back to the OS. You also have to consider that, while you may be done with the texture, the GPU might not be, so the driver might not be able to instantly free it.
3) If your checkmemory function is anything like the functions used by TaskManager, it is going to be reporting the memory that your application has claimed as its own. This memory may be free for your application to use, but it may be impossible to free it back to the OS at the moment, as memory is freed in pages (usually 4KiB). You have to be done with every bit on those pages before they can be dumped.

Use an actual profiling tool like Valgrind, or the build in CRuntime's memory debug functions like _CrtDumpMemoryLeaks, and be aware that it will likely report many false-positives for things like globally constructed STL containers (who aren't leaking, but won't have been freed at the time you call that debug function).

There is always someone who comes here and talks about their memory leaks. Dude, it is normal operation. Forget about it.

There is always someone who comes here and talks about their memory leaks. Dude, it is normal operation. Forget about it.

Nope Sorry guys still i am in confusion.My direct question is as soon as i delete a block of texture will it get free the physical memory or not ?
If so why i couldnt able to see any changes in the memory status,

After deleting the textures and context i could see virtual memory is got freed up but if i compare the memory details before loading the textures
virtural memory is still holding some memory,it is not fully freed could you please guide me on why and what is it holding.

I am worrying bcoz application has to run on embedded target

It doesn't matter if the physical memory becomes free or not, only whether it is logically free. There is no guarantee that deallocations will result in changes in physical memory use. What is guaranteed is that the driver or runtime is aware that the memory is logically free, so it can re-use it when necessary.

You are doing the right thing in your code, any condition where the memory cannot be re-used is a runtime or driver bug. Caching the memory is not a bug; it is an optimisation.

Can you post CheckMemory()?

It doesn't matter if the physical memory becomes free or not, only whether it is logically free. There is no guarantee that deallocations will result in changes in physical memory use. What is guaranteed is that the driver or runtime is aware that the memory is logically free, so it can re-use it when necessary.

You are doing the right thing in your code, any condition where the memory cannot be re-used is a runtime or driver bug. Caching the memory is not a bug; it is an optimisation.

Can you post CheckMemory()?


void CheckMemory()
{
MEMORYSTATUS MemStatus = {0};

MemStatus.dwLength = sizeof(MEMORYSTATUS);

/* Get the system memory parameters */
GlobalMemoryStatus(&MemStatus);

/* Display syatem memory parameters to syatem console window at every 25 sec */
printf("\n\n###########################################################\n");
printf(" TEST APP MEMORY STATUS DISPLAY \n");
printf("###########################################################\n\n");

printf("1. MEMORY LOAD = %d percent\n",MemStatus.dwMemoryLoad);

printf("2. TOTAL PHY MEM = %ld bytes\n",MemStatus.dwTotalPhys);

printf("3. AVAIL PHY MEM = %ld bytes\n",MemStatus.dwAvailPhys);

printf("4. TOTAL VIRTUAL MEM = %ld bytes\n",MemStatus.dwTotalVirtual);

printf("5. AVAIL VIRTUAL MEM = %ld bytes\n",MemStatus.dwAvailVirtual);

printf("\n*************************************************************\n\n");
}


You might find some interesting information using GetProcessMemoryInfo() instead. It might help you figure out if it is the OS caching the memory, rather than something inside your process. You may also look into something like gDEBugger, which claims to include memory profiling for OpenGL.

I am worrying bcoz application has to run on embedded target

It looks like you are testing on windows, yes?

If so then your test enviroment is worthless if it isn't anything like the deploy enviroment. Window on an x86/x64 machine with a large amount of memory is going to have utterly different memory management operations to an embedded system with limited memory and a different OS; the two situations are not even remotely comparable in this instance.

You are talking about main system memory here. A texture will exist in both system memory and GPU memory, and your measurement has absolutely no relevance whatsoever to GPU memory usage.

It's also possible that glDeleteTexures may not delete the texture object immediately, but instead queue it for later deletion at a time when the GPU is not busy. This would be an implementation detail - OpenGL does not specify when full deletion happens, merely that the higher-level object is destroyed (in other words it does not specify how the backing storage is dealt with, this is up to the driver) - and the inner workings of it should not concern you.

Always remember that when you're coding to any 3D API you're no longer in software-only land. You're no longer just dealing with resources that only exist on the main system, and you're no longer dealing with operations that occur in the precise order you specify them.

You are talking about main system memory here. A texture will exist in both system memory and GPU memory, and your measurement has absolutely no relevance whatsoever to GPU memory usage.

It's also possible that glDeleteTexures may not delete the texture object immediately, but instead queue it for later deletion at a time when the GPU is not busy. This would be an implementation detail - OpenGL does not specify when full deletion happens, merely that the higher-level object is destroyed (in other words it does not specify how the backing storage is dealt with, this is up to the driver) - and the inner workings of it should not concern you.

Always remember that when you're coding to any 3D API you're no longer in software-only land. You're no longer just dealing with resources that only exist on the main system, and you're no longer dealing with operations that occur in the precise order you specify them.

Phantom,
Thanks for your reply.For your info, i am using winCE.So the details i have provided is from the target memory status.

Thanks mhagain,
Now i am getting a grip on this issue.