Purge images/textures from VRAM?
BlitzMax Forums/BlitzMax Programming/Purge images/textures from VRAM?
| ||
| Is this possible? Nulling TImages does not seem to release VRAM. |
| ||
| Isn't there a DeleteImage() command? in GL you'd need to deallocate the texture handle like glFreeTextures() or something. |
| ||
| Isn't there a DeleteImage() command? Nope. in GL you'd need to deallocate the texture handle like glFreeTextures() or something. I'm using DX9. |
| ||
| Maybe when you CloseGraphics()? |
| ||
| There's no CloseGraphics() command either? Assuming you meant EndGraphics, I don't want to do that. I just don't want my VRAM to get chock-full of redundant data as it appears to be doing, as there is apparently no way of flushing it out properly. |
| ||
| I actually had to tackle this when running a game on my mac that has only 32mb of vram. The game in question used transition fades and story boards that involved many 800 x 600 bitmaps (which I assume occupy as much vram as a 1024x1024 because of the power-of-two requirements). Without clearing them out we'd eventually see white images where new stuff failed to load. Null'ing them and forcing a gccollect() did work and eliminated the problem entirely. Are you sure you don't have any references to the TImage hanging anywhere else? |
| ||
| Nope. Classes are created and destroyed from a single function, and all images are contained within those classes. I'm not currently using GCCollect() as I'm just leaving GC to take care of that as and when. I'll give GCCollect() a try in the morn. :) [edit] Just done some basic test code which repeatedly loads a large image, draws it then nulls it. Without GCCollect, resources rockets up to over 400MB in just a few seconds. With GCCollect, its consistently below 30MB. So, think I'll be sticking that in my game tomorrow. Thanks for the tip. :D |
| ||
| Hm isn't that something a garbage collector is meant to do on its own? :S |
| ||
| I've noticed similar actions with the garbage collector in the past, at this point I leave the GC on auto but them pepper my loading/unloading code with GCCollect() to clean up the bits that auto misses as well as to force cleanup when I want it so it won't happen during more important times like when actually playing. It also cleans up junk created in loading/preping so there's more memory available for the next item to be loaded/preped. Not a big deal most of the time, but if you have to push memory limits you don't want your ceiling artificially lowered by leftovers that should be gone already. Seems especially important when there's mallocs in C in some modules... I think auto cleans "as needed", and a manual collect cleans everything available to be cleaned... but I haven't gone digging to find out if this is true or just appearance. |
| ||
| the gc is meant to clean up memory when needed. if 70% of the ram are empty then its meant to not clean it. this has all no impact on the vram though as the gc handles the managed memory thats the ram stuff. the vram is managed by dx in dx and in opengl its not managed at all, newer stuff just overwrites older stuff (this no management is the root why there is no reliable way to define how much vram you used and whats free on opengl) |
   |