Hi Robert, I updated to the svn trunk today, and i can notice a crash when quitting my application. To be sure it was with the new texture manager i defined USE_NEW_TEXTURE_POOL to 0 and then to 1.
I dont have yet found the problem, but i guess it's linked with my texture manager, i own some static that reference texture. The segfault appear when quitting Program received signal SIGSEGV, Segmentation fault. #0 0xb6ef7ddf in ?? () from /lib/libc.so.6 #1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #3 0xb54f2008 in ?? () #4 0xb54f2008 in ?? () #5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #6 0xb6fd0bcb in ?? () from /lib/libc.so.6 #7 0xb6fd26e8 in ?? () from /lib/libc.so.6 #8 0xb6fcf469 in ?? () from /lib/libc.so.6 #9 0xb6fcf442 in ?? () from /lib/libc.so.6 #10 0xbfc68254 in ?? () #11 0xa7200010 in ?? () #12 0x0000001d in ?? () #13 0x00000000 in ?? () I guess there is something wrong with my texture management and the new texture pool. I continue to dig Cheers, Cedric -- +33 659 598 614 Cedric Pinson mailto:[email protected] http://www.plopbyte.net On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote: > Hi All, > > I've been pretty quiet and the public list/forum through September, > keeping my head down developing new functionality for the OSG... and > the new functionality I'm pleased to announce today is that we now > have a loverly new back-end implementation for texture objects and > buffer objects (VertexBufferObject, ElementBufferObjects and > PixelBufferObjects's) that provides a set of GL objects pools that > enable recycling of both orphaned GL objects and reuse of GL objects > that are still attached to the scene graph, but are stale - i.e. > haven't been rendered in the last frame. > > The benefit the GL object pools provide is that we can scale up the > scene graph in main memory without blowing OpenGL driver and GPU > memory as we would do without the new pools. This feature also > reduces the likely-hood of thrashing of OpenGL driver and GPU memory > so that where we might have previously seen frame drops due to memory > management we avoid them completely or reduce there impact. The > memory pools will come in there own once we scale down the GPU memory > size, such as embedded systems, or on desktop/workstation applications > where GPU memory can be overflowed due to massive databases being kept > in main memory. In the later case this issue is more compounded on > some OS's, such as Vista, that limits the amount of memory that OpenGL > drivers can allocate, so here it should help make the app more stable > (avoid the crashes due to out of memory errors) and faster. > > So... how to try out the new texture and buffer object pools? First > up you'll need to update to the latest OpenScenGraph svn/trunk. Next > you'll need to enable the pools by setting the env vars: (example > below for bash) > > export OSG_TEXTURE_POOL_SIZE=100000000 // size in bytes (100Mb) > export OSG_BUFFER_OBJECT_POOL_SIZE=200000000 // size in bytes (200Mb) > > Then run your app with some big data, such a large paged database, you > can push the amount of main memory used by enabling the MaxPagedLOD > feature in the DatabasePager via: > > export OSG_MAX_PAGEDLOD=100000 // keep in memory a maximum of > 100,000 PagedLOD nodes > > You can also set these values programmatically via osg::DisplaySettings. > > A word of warning though, I have almost completely rewritten the way > that the backend that drives texture objects and buffer objects, even > when you don't enable the texture/buffer object pools, the code > managing the GL objects is still completely different. With major > changes like this comes the likelihood of regressions. I've been > doing a range of tests at my end, but it's still far more limited in > scope to what the community will expose the OSG to, so... there you > may way see problems that I haven't. The best I can do is endeavor to > get them fixed as quickly as possible, just let me know if you see > something odd and I we can work together to spot what the underlying > problem and squish it. The more testing we can get the quicker we can > shape the code up to being release quality. > > Have fun with it :-) > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
