Hi Robert, could you please give a short message here when the patch is ready? We had to switch VBOs off due to serious stability problems. It would be cool to have a backport to version 2.8.3 (or at least some hint how to backport it ourselves).
OSG is great work! Many thanks!!! - Werner - Am Dienstag, 14. Dezember 2010, 09:35:49 schrieb Robert Osfield: > 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.or > >> g > > > > _______________________________________________ > > 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 -- TEXION Software Solutions TEXION GmbH - Rotter Bruch 26a - D 52068 Aachen - HRB 14999 Aachen Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu Geschäftsführer/Managing Director: Werner Modenbach _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
