Texture Memory Management
Here's a very rough list of issues and goals to consider:
- . Single-copy textures Don't want to have every texture duplicated in two places: client memory (libGL) and on the card. If a texture is only present in the card's memory, what happens when we need to (re)move it to make room for new stuff? Need to make sure we never lose or corrupt a texture image. Consider glCopyTexImage(), don't ever want to lose the contents of texmem since we have no backup of the image.
- . Share texmem among n OpenGL clients. This works in recent DRI drivers, but is kind of klunky. Basically, if the working set of textures for all clients can simultaneously fit in texture memory, we don't want to reload textures when we context switch.
- . Dynamic allocator, to accomodate vertex buffers, pbuffers, etc. Beyond textures, there are vertex buffers, pbuffers, back buffers, depth buffers, etc that may be competing for card memory.
- . AGP texturing (i.e. textures reside in AGP memory). Any circumstances when we'd have to move the textures to card memory or vice versa? Render to texture?
- . Render to texture. Can cards render to AGP memory? Yes? This interacts with pbuffers (bind pbuffer to texture, render to the pbuffer texture).
- . GL_SGIS_generate_mipmaps Use h/w image scaler to generate filtered mipmap levels? Or, for n_x_n texture, render a (n/2)x(n/2) polygon? (w/ render-to-texture)
- . 's memory management proposal: 'pinned' textures, etc. If we ever expose memory management to the user (beyond texture priorities) we want to be sure our allocator is designed with this in mind.
- . 1-D, 3-D, cube maps, texture rectangles, compression, etc. Don't forget that there's more than just traditional 2-D textures. -- BrianPaul