Re: [Flightgear-devel] OSG caching and other OSG issues
Am 01.04.2012 18:25, schrieb Mathias Fröhlich: > If you work with weak pointers/observer_ptr you need to use the lock method. Ok, you're absolutely right. I wasn't aware of the "lock" method before, indeed it has to be used here. I'll push a change. Thanks for reviewing this! cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Hi, I try to catch up on things past an other busy week. On Thursday, March 29, 2012 00:22:46 ThorstenB wrote: > Mathias, maybe you can have a look at the simgear changes. Maybe you see > a way to improve this even further - i.e. do we still need all these > cache maps? Or could we simply rely on some OSG cache in some places? Just looking quick over what you checked in, I think that this needs some improovements: The change just returns pointers to objects you get from the observer_ptr. In general, this is not exactly thread safe. I do not see currently if you can ensure from a higher level that this is not a problem or not. In general consider the following situation: Thread 1 has an observer_ptr to A. Thread 2 owns the last reference to A. Thread 1 gets the still valid raw pointer to A from the observer_ptr. Thread 2 releases the last reference to A and deletes it. Thread 1 assigns the raw pointer to a ref_ptr. This probably ends in a segfault. If you work with weak pointers/observer_ptr you need to use the lock method. That one gives you a atomically a dead or alive ref_ptr to A. If you have this ref_ptr in our hands, you own a thread safe reference which makes sure that nobody deletes the object. If your ref_ptr is invalid. An other one was faster on unreferencing. In effect this groups step 3 and 5 into an atomic operation which can not be intercepted by step 4 in the example above. So, if you use this kind of weak stuff, you need to ensure that all the call chain from getting the ref_ptr from any cache down to adding this object to the scenegraph does not use raw pointers. Also the initial ref_ptr in this chain must be gained by observer_ptr::lock(). Regarding the effects, I don't think we can rely on any caching in osg since we do not currently use any osg based loader mechanism to gain these objects. At least nothing that I know of. Greetings Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Hi, I've pushed a fix for a larger memory issue, mainly affecting effects/texture images, but also other objects. Once loaded, these stuck in memory until shutting down flightgear - so memory consumption was continually growing when flying larger distances. Probably wasn't much of an issue initially, when we only had few or generic textures. Now, with lots of custom models and eye candy, we obviously should be able to drop stuff again. We've discussed this about a year ago. Tim suggested using "observer pointers" instead of "references" in the cache maps. The discussed patch was never pushed to sg/next though, since I was running into stability issues with OSG 2.8.3. Since we don't support OSG 2.8.3 any longer, I've revived this again and changes are in simgear now. Keeps memory consumption a lot lower. I'm still seeing a slight memory growth when moving - but by far, it's not as bad as it was. Simple test is to "relocate-on-ground" to a series of airport locations and watch process memory. Mathias, maybe you can have a look at the simgear changes. Maybe you see a way to improve this even further - i.e. do we still need all these cache maps? Or could we simply rely on some OSG cache in some places? cheers, Thorsten Am 03.05.2011 21:49, schrieb ThorstenB: > On Mon, Apr 18, 2011 at 9:55 AM, Tim Moore wrote: >> On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB wrote: >>> There is >>> a global cache in simgear/makeEffect.cxx (effectMap), and it has no >>> condition to ever drop anything. So, created effects always stay in >>> memory until shutdown - hence also their textures. >> >> It seemed like a good idea at the time :) >> The Effect cache could be changed to use osg::observer_ptr, which is a >> weak pointer. > > Good idea. Here's a patch using observers instead of references for > caching. Puts some live into the effect/texture destructors - so these > can finally free up some memory once the objects are no longer used > anywhere: > http://www.gitorious.org/~thorsten/fg/thorstenbs-simgear/commit/71d14629076b3a56c40cc0309b42b3a22d579bec -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSG caching and other OSG issues
On Mon, Apr 18, 2011 at 9:55 AM, Tim Moore wrote: > On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB wrote: >> There is >> a global cache in simgear/makeEffect.cxx (effectMap), and it has no >> condition to ever drop anything. So, created effects always stay in >> memory until shutdown - hence also their textures. If that's used for >> scenery/MP aircraft a lot, it _might_ accumulate a lot of memory. Tim >> might know more about this :). > > It seemed like a good idea at the time :) > > The Effect cache could be changed to use osg::observer_ptr, which is a > weak pointer. Good idea. Here's a patch using observers instead of references for caching. Puts some live into the effect/texture destructors - so these can finally free up some memory once the objects are no longer used anywhere: http://www.gitorious.org/~thorsten/fg/thorstenbs-simgear/commit/71d14629076b3a56c40cc0309b42b3a22d579bec Patch is in my local branch (not in next). Any comments? It indeed improves memory consumption when switching (or flying :) ) between airports. However, I'm still seeing memory growth/leaks (and I'm really starting to dislike all these "smart" auto pointers - searching the last reference causing an object to leak, is a really annoying job...). I also noticed a bad leak in older OSG versions - including the stable release (2.8.3). It's fixed by now (OSG svn), but I haven't checked for which version it was fixed first. However, we've lost 3D cloud support with latest OSG trunk (not a single 3D cloud visible, everything fine with recent OSG devel releases though). Might be temporary OSG trunk issue... Also, osgText still isn't working for us with latest trunk (see http://code.google.com/p/flightgear-bugs/issues/detail?id=268 ). There were several fixes and updates to osgText just before we started seeing the issues. Since it still isn't fixed on the OSG side, it might also be our problem after all: maybe we're relying on an old osgText bug - or we need to adapt something. We'll probably need to look into this... cheers, Thorsten -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
