cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

coordz
Adept II

How to force OpenGL texture/buffer memory to be freed?

In our application, (rather large) texture and buffer resources are created and destroyed at various points during the course of execution. Sadly, these resources do not seem to be freed by the driver after the texture/buffer has been deleted leading to the GL eventually giving an out of memory error and dying a horrible death. Is it possible to force the driver to free the memory associated with a deleted texture/buffer?

So far I have tried:

- Making the texture/buffer a tiny size before deleting the resource.

- Doing a glFlush() and glFinish() after the delete.

- Swapping buffers.

- Drawing a simple triangle then swapping buffers.

- A number of combinations of the above to try to prompt the (lazy) driver to free the memory.

I fully understand the need for the driver to lazily free memory so as not to harm performance but not to free memory and force an out of memory error is, imho, a nasty bug.

One day we'll have a public Mantle interface and OGL Next so I can do the memory alloc/dealloc. Until then: how can I force the OGL driver to free memory that is associated with deleted resource?

Thanks

0 Likes
1 Solution
jtrudeau
Staff

Q: how can I force the OGL driver to free memory that is associated with deleted resource


As noted separately today, I want to encourage the community to answer general programming questions. But since I was bugging one of our people on another programming question, I passed this one on as well. And the answer:


Answer is, you can’t. You can’t even force C’s free() function to actually return memory to the operating system.


Anyone else care to discuss?

View solution in original post

0 Likes
4 Replies
jtrudeau
Staff

Q: how can I force the OGL driver to free memory that is associated with deleted resource


As noted separately today, I want to encourage the community to answer general programming questions. But since I was bugging one of our people on another programming question, I passed this one on as well. And the answer:


Answer is, you can’t. You can’t even force C’s free() function to actually return memory to the operating system.


Anyone else care to discuss?

0 Likes

Thanks for your reply. This is definitely a bug in the AMD driver if it cannot free memory that has been marked for release and there is a pending memory request that needs satisfying, i.e. a giant memory leak. Might this be fixed or should I give up and wait for Vulkan drivers?

(As a discussion aside on C's free(): while there is no guarantee the C library will return the memory to the OS, the OS is perfectly capable of paging out that (unused) memory. Unless the address space is exhausted (extremely unlikely in 64 bit), the memory that has not been returned to the OS can sit out of the way. Now if AMD's drivers actually paged out memory from the device which would then allow further allocations to occur successfully then we'd be in a different place.....)

0 Likes

I think 'Doing a glFlush() and glFinish() after the delete' should work. Does the texture detached before delete ?

0 Likes

Do you have access to Nvidia hardware to test the behavior ?  Even though the GPU driver does the allocation of memory for the graphics resources you mentioned...driver memory management is tightly coupled with the OS memory management scheme. The GPU driver is also able to allocate memory in the host address space and thus have to negotiate memory transaction with the operating system. Also is it possible that memory is being allocated at a faster rate than its being de-allocated. Keep in mind that if there are pending transaction referencing the memory region, they will not be freed immediately or this may even force the driver to clone the memory internally before freeing..It would be interesting to see if this behavior can be replicated on other HW..