Hi Jason, I will be doing a review of BufferObject pool this morning, comparing it's implementation with the more shaken down TextureObject pool. This might bring up some fixes,
Robert. On Mon, Dec 13, 2010 at 8:12 PM, Jason Beverage <[email protected]> wrote: > Hi Robert, > > I took a look into this again and I think I know what the issue is > although I'm not sure about the solution. In > GLBufferObjectManager::getGLBufferObjectSet a new GLBufferObjectSet is > created each time b/c the number of verts generated on each frame is > different so the profile doesn't match. This means that no reuse is > happening and it also means that all the GLBufferObjectSets are > sticking around forever b/c the _glBufferObjectSetMap is never cleared > out or has items erased from it so it just keeps growing and growing. > Is there a way we could go through periodically and check to see if a > GLBufferSet in the glBufferObjectSetMap hasn't been used in a while > and delete it once some maximum number of sets has been reached? > > Thanks, > > Jason > > On Mon, Oct 4, 2010 at 9:13 AM, Robert Osfield <[email protected]> > wrote: >> Hi Jason, >> >> On Mon, Oct 4, 2010 at 2:07 PM, Jason Beverage <[email protected]> >> wrote: >>> Just pinging again to see if you have any thoughts on this. No rush, >>> just wanted to make sure it didn't get lost. >> >> I haven't had a chance to look into the issue yet. My guess is that >> the texture object pool is keeping the GL texture objects around in >> case they can be reused but as the sizes are never compatible it never >> achieves this and has to allocate new ones. What will need to happen >> is for there to be an automatic scheme for deleting texture objects >> when new ones are needed and there memory has already hit the specific >> texture pool limits. I do recall thinking about this particular >> issue when I implemented the code, and there might even be code that >> already attempts to do this. Go have a look at the code to see if you >> can see what's going on. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
