Re: [Dri-devel] issues/goals for improved texture memory management
Here is the texmem patch that I talked about at last week's (sorry for the massive delay!) IRC meeting. There's a patch file and a couple new files. Also, mga/mgatexcnv.c should be removed. I'm not sure how to specify removing a file in a patch. :) In any case, I'm primarilly sending this out for discussion at today's meeting / on the list. It would be premature to apply this patch before we decide where to go with the in-kernel memory manager. I suspect that parts of this code would live on in user-mode with the in-kernel memory manager, but most of it would be moved into the kernel. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html texmem_patch.tar.gz Description: application/tar-gz
Re: [Dri-devel] issues/goals for improved texture memory management
>On Mac OS X (from 10.1 on, I believe), the OS can map any memory page into >the AGP aperture at any time. The idea behind A_cs is that people malloc >space for a texture, specify GL_UNPACK_CLIENT_STORAGE_APPLE to >glPixelStorei, then call glTexImage?D with their pointer. The GL driver >then keeps the pointer (instead of copying the data) and, when the texture >is needed, maps the memory into AGP space. This way you really do only have >one copy of the texture in memory. > >I guess the short answer to your question is "yes." :) This is interesting but nasty to implement in linux... also one must take care to properly cache flush the memory before mapping it into the aperture (and eventally unmapping it from client or re-doing the client mapping uncached while the page is mapped into the aperture). Ben. --- 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
Re: [Dri-devel] issues/goals for improved texture memory management
On Wed, Oct 02, 2002 at 04:35:16PM -0600, Jens Owen wrote: > Ian Romanick wrote: > > > 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. :) > > I believe the R200 implementation of APPLE_client_storage allocates > space from a static pool in AGP space. I don't think that's quite right. If I'm not mistaken, the R200 driver exports a GLX extension to allocate memory from AGP space and that memory can be used with A_cs. > Are you looking for a way to > make the AGP pool larger and dynamically move pages in and out of the > AGP aperature? On Mac OS X (from 10.1 on, I believe), the OS can map any memory page into the AGP aperture at any time. The idea behind A_cs is that people malloc space for a texture, specify GL_UNPACK_CLIENT_STORAGE_APPLE to glPixelStorei, then call glTexImage?D with their pointer. The GL driver then keeps the pointer (instead of copying the data) and, when the texture is needed, maps the memory into AGP space. This way you really do only have one copy of the texture in memory. I guess the short answer to your question is "yes." :) -- 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
Re: [Dri-devel] issues/goals for improved texture memory management
Ian Romanick wrote: > 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. :) I believe the R200 implementation of APPLE_client_storage allocates space from a static pool in AGP space. Are you looking for a way to make the AGP pool larger and dynamically move pages in and out of the AGP aperature? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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
Re: [Dri-devel] issues/goals for improved texture memory management
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
[Dri-devel] issues/goals for improved texture memory management
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
