Texture Objects and texture management

This isn’t strictly an ES-question, but more a general OpenGL question. I have only used OpenGL for like a week, so bear with me if I have misunderstood something.
I can’t really get a clear view of how it works from reading the OpenGL or OpenGL ES specifications. So maybe its implementation specific…

Its about texture management… I read that when using texture objects the GL will have some kind of texture management to load and unload textures. But how does this really work?

Am I right that the idea is that I as a user of the GL don’t know if the actual pixel data for a texture object is actually loaded in texture memory or not?
What actually happens when I do a glTexImage2D on a texture target bound to a specific texture object? Is it loaded into texture memory at this point? It seems so.

What if it doesn’t fit in texture memory?
Will it throw out the least recently used texture? what happens if I then try to bind the texture object name I used to define that old texture? will it be loaded into texture memory again automaticly? I assume so.

But from where? Here is my problem.
Does the pointer I specified to glTexImage2D have to still be valid for it to be reloaded? What if I when I called glTexImage2D provided a NULL pointer and filled my texture with glTexSubImage? then it couldn’t know where to reload it from?
Is texture management disabled then?

It all seems a bit weird to me…
If anyone can shed any light on the subject I would appreciate it.

[ January 20, 2005: Message edited by: Olof Hedman ]

Once you’ve called glTexImage2D, you don’t need to hold on to your pointer. The driver now has a copy of the image data, assuming there was memory available. If not, you should check glGetError for GL_OUT_OF_MEMORY, but this should be a rare case. The driver won’t overwrite old texture memory to make room for a new one unless you explicitly tell it to, say, by calling glTexImage2D several times with the same bound texture object. But that would be plain silly.

After a successful call to glTexImage2D, a bound texture object is considered to be “defined”. If the call fails, or has not been called, and thus the texture object is not defined, then it is as if that texture unit were disabled.

There’s really too many questions here to answer :wink: I suggest you glance through the OpenGL 1.1 specification (where texture objects were first introduced) to get a better grasp.

  • ben

I think, what I am most interested in, is. Does the driver keep some kind of texture storage in system ram, outside of texture memory?
That is, after a call to glTexImage2D, will the texture be in texture ram or system ram? or both?
You say out of memory is a rare condition, but specially on a ES hardware, you have relativly little texture memory, and at least in the application I’m working with, the amount of texture memory is not enough, and out of texture memory condition is potentially common…
Is it rare because the driver uses system ram too?
Does the driver have some kind of texture management if I try to define more texture objects then fit in physical texture memory?
How does this work if so?

More questions, all more or less the same really. :slight_smile:

>Does the driver keep some kind of texture storage in system ram, outside of texture memory?<

On destkops, yes it stores a copy. The copy can even be swapped to the swap file by the OS if RAM starts running out.
If there is AGP technology, the copy can be be kept in AGP memory for faster access.

I assume on embedded systems copies won’t be made since it consumes lots of RAM, specially when textures are not compressed.

GL is responsible for the memory management.

>Will it throw out the least recently used texture? what happens if I then try to bind the texture object name I used to define that old texture? will it be loaded into texture memory again automaticly? I assume so.<

If a texture is invalid or incomplete, then a white color will be applied instead.

So coming back to your original question: No, the OpenGL ES API does not provide the means to implement a smart texture manager. You could probably build one based on heuristics like trying to load textures into memory until you get a failure to estimate the amount of texture memory available. Or by trying to load into a new texture object, and if it this fails, attempting to free/re-use the LRU one yourself.

  • HM

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.