View Full Version : How does OpenGL store its textures
Can i assume, that OpenGL _always_ holds a seperate copy of a texture in system-memory, no matter if it fits into VRAM or not?
I figured out that my very simple engine eats 42 MB of system-memory and i discovered, that when i donīt load one 3 MB texture, it uses 4 or 5 MB less (the extra 1 or 2 MB are certainly the mipmaps).
07-31-2003, 02:59 PM
I don't think that's a safe assumption. Are you freeing the memory in which you store the textures prior to uploading them?
07-31-2003, 10:32 PM
OpenGL always holds a copy of the texture *somewhere*. The driver decides if that "somewhere" is on the video card, in AGP memory, or in system memory, or if multiple copies are needed (or not).
Once you hand GL a texture, you don't need to keep the source data around anymore.
I can confirm that. Keeping textures is an old-fashioned thing which is slow to die.
Delete you texture arrays passed to TexImage immedialty after calling that function.
As a side note, this is why most games reload everything after you changed resolution (window destroyed -> gl destroyed -> textures lost -> need to reload). If they keep the textures in application space ram, they would not need it.
EDIT: whoops, wrong function
[This message has been edited by Obli (edited 08-01-2003).]
I do delete my textures after loading them (i checked it, there is no error in my loading code).
But still it seems as if OpenGL keeps a seperate copy for every texture in system-memory.
But maybe it does that only with big textures (3MB and up) to be able to swap a single texture out and freeing a lot of space.
My gfx card has 128 MB RAM and i use maybe 10 MB, therefore this is not necessary, but of course the driver doesnīt know that.
WEll, what if you start 40 other opengl programs, then i probably NEEDS the texture to be uploaded again, so yes it keeps a copy, but as stated before, you cannot say where it is.. In windows i think its safe to assume its in the system Ram.
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.