On Mon, Sep 30, 2002 at 05:07:39PM -0600, Brian Paul wrote: > 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.
This seems to be a pretty complete list. I only have a couple things to add. > 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. Really there are 3 places the texture data can be duplicated: in the app, in libGL, and on-card / AGP. This can either be done by exposing some sort of "allocate AGP memory" extension or with APPLE_client_storage and dynamic AGP remapping. I've done a cursory look at the AGP driver, and it seems like this is possible, but I'm not positive. Anyone know for sure? It is definitly possible in the AGP spec because Mac OS X can do it. :) > 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. 3b. Generic allocator The vast majority of this work can / should be device independent w/some device dependent hints (alignment requirements, etc.). > 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. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ------------------------------------------------------- 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
