To my knowledge it’s always been the case that creating a texture on the card using glTexImage2D causes the driver to internally create a duplicate in RAM (I am very sure of this for NVidia on Windows).
I have also been aware that glDeleteTextures doesn’t free up this memory rather does something akin to marking it available for reuse.
In previous applications this has always been fine for me. But in my current application it no longer is. I have a preview mode in my app where I generate a preview of a large 3d volume the total memory foorprint of all the textures involved runs close to Gb. And as it turns out subsequent phases of the workflow do not require this memory for anything Ogl related but do require that RAM that the driver is holding on to.
How do I get it back? I’ve even tried regenerating a list of small textures in the hope that the reuse of the slots with smaller data would free up the old memory… doesn’t seem to work.
Anyone seen this? Anyone know how to get this memory back?
Thinking deviously , I wonder about creating/loading buffer objects in OpenCL or CUDA, sharing with GL, and then merely copying the data into the few active OpenGL textures as needed.
Yeah that would be nice… problem is there are too many problems using that technique. I’m actually going from a high res short based representation of the volume in Cuda to a byte based for Ogl preview, turns out that leaving everything on the card and going direct from the pbo to the textures using glTexSubImage2D and an offset is actually a factor of 10 slower than doing the conversion of short to byte in Cuda pulling it all into RAM and copying to gl… and… using glTexSubImage2D on these large datasets was also causing instability…
But it would be interesting to see if the driver still want’s to make a copy a texture that was created from pbo in RAM… I’m kind of expecting it would… but maybe it wouldn’t… I may give that a shot just to see.
Did you have any luck finding a workaround / fix? I have the same issue in my app. I can never get all the memory back, even after calling glDeleteTextures();
Note, If I never render the texture (i.e. call glDeleteTextures() immediately after gluBuild2DMipmaps and deleting the buffer), I get all the memory back.
Nope. We managed to reduce memory usage elsewhere and get by for the short time. It’s a pretty critical error. One I get the release out the dor I’ll be logging this as a bug with NVidia.
You’re right that the memory doesn’t get consumed until the texture is displayed… that’s kind of peculiar… the data is sitting on the card but when you go to render the first time they make a copy in system memory…
, I wonder about creating/loading buffer objects in OpenCL or CUDA, sharing with GL, and then merely copying the data into the few active OpenGL textures as needed.