is texture data resident in VRAM and system RAM?

if i do

myTexture = TextureIO.newTexture(new TextureData(0, 0, true, ImageIO.read(new File(filename)));

the texture gets loaded into VRAM, right?

but it seems that it also remains somewhere in system RAM.

is there an option to have the texture data resident in VRAM only? if i am not mistaken, all the texture object should be holding, is a pointer to the data position in VRAM, so that it can do texture.bind(); right?

the problem is, that i use a really lot of textures and so my system RAM increases terribly fast (up to 300MB).

In theory after one or two full GCs (and running of finalizers) any dangling finalizable references to the image data that remain in the Java heap should be garbage collected, so you should see the heap shrink back down if you run with -verbose:gc. If you don’t see this you should try running with a profiler to see what is continuing to refer to the image data.

AFAIK textures are shuffled around vram and ram by the driver.

I don’t have any hard data on it but from my experience with the TurboCache and HyperMemory parts it seems that a copy of textures are kept in system memory instead of being copied back over the bus when they need to be evicted from vram.

There’s an easy way to tell whether the issue is large byte arrays in your Java heap which is to run with -verbose:gc on the command line. That will print the heap size every time a GC occurs and you should be able to watch these large arrays associated with TextureData objects be collected. If your Java heap doesn’t seem to be that big, then yes, the texture data is being held on to somewhere in the C heap (non-Java managed system RAM).

this question is related but off topic: is there a way to get how much memory a graphic card have? graphics device only return the number of available memory to note. any suggestion on getting size of video memory? some vidcard supports virtual memory also, how do i determine how much virtual mem they use?

I don’t think there’s a way to query this from OpenGL. From my understanding this was a deliberate design choice because of the very different ways various graphics cards implement things like texture memory.

OpenGL does not provide this information, but Java does. If you want to query available VRAM, look into the method java.awt.GraphicsDevice.getAvailableAcceleratedMemory().

I’m not sure how reliable it is, but it may help you out.

yeah, I knew about that function; but, I was looking for something like “getTotalAcceleratedMemory().” There is no such function, so I might look at the C equivalent for different platforms. I will go to java.awt. forum to ask about request for enhancement.