This was a topic on today's IRC session. Here's a very rough list of issues
and goals to consider. After we get a good list we can move onto implementation
proposals. If we're really going to do this, let's be sure we do it right.
Please contribute comments, new issues, etc.
-Brian
1. 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.
2. 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.
3. 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.
4. 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?
5. Render to texture.
Can cards render to AGP memory? Yes?
This interacts with pbuffers (bind pbuffer to texture, render to the
pbuffer texture).
6. GL_SGIS_generate_mipmaps
Use h/w image scaler to generate filtered mipmap levels?
Or, for NxN texture, render a (N/2) x (N/2) polygon? (w/ render-to-texture)
7. Allen Akin'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.
8. 1-D, 3-D, cube maps, texture rectangles, compression, etc.
Don't forget that there's more than just traditional 2-D textures.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
