hi curt, i have since tried to run flightgear on the weaker machine (atholon xp 2000+, geforce 6200 128mb, 768 mb ram). and i get about the same amount of stutters with and without the patch when new terrain is paged in. this is highly subjective, though.
i don't know how to *prove* that the new code doesn't impact performance. if you have a good idea, could you give me a hint? otherwise we might just put it on cvs and see if people notice performance loss? thanks, -till On Tuesday 22 January 2008, till busch wrote: > hi curt, > > why i think that this shouldn't impact performance: > > 1. afaik the database pager now runs in its own thread > 2. most texture-data will be loaded before the screen gets bright > 3. i assume adjacent tiles will have similar materials (in real world, > changes to ground material aren't abrupt) -- so loading the next tile will > require only few new textures. > 4. i tested this on my machine, and it was just fine > > why i think changing this is a good thing: > > 1. at LOAV where i tested this, memory usage after startup dropped by 24 > megs 2. we might want to have more different ground textures and material > types in future. > 3. globals->get_matlib()->load_next_deferred() in fgMainLoop iterated > through 210 materials during each frame, just to see that there is > *nothing* to do. 4. matlib held a reference to each SGMaterial, which in > turn held a reference to osg::State (ok so far, and enough for never being > freed during runtime). the contained osg::State held a reference to the > SGMaterial defining it. this made it impossible for SGMaterial to ever get > deleted - even on exit (yes, i know the kernel takes care of freeing memory > left over - but this isn't good practice, anyway). i saw the leaks in > valgrind, but it took quite some time for me to find the reason in the > code. > > i'm not yet sure how unloading textures could be done. i know it must be > done in a way that won't unload and load the same texture too often. the > osg does caching though, so the impact might be lower than expected. > > the hardware i tested this on is rather new (macbook pro, core 2 duo with > nv 8600M GT 512mb, 2g ram). if you want, i can test this on some older > hardware (atholon xp 2000+, geforce 6200 128mb, 768 mb ram) > > > regards, > > -till > > On Tuesday 22 January 2008, Curtis Olson wrote: > > On Jan 21, 2008 4:03 PM, till busch wrote: > > > hi all, > > > > Hi Till, > > > > I don't know all the nuances of the OSG branch and OSG usage, but > > originally the common material library textures were all loaded at start > > time so they'd be available at any time and not hit the fps like they > > would if they needed to be loaded on demand. Then we bumped up the > > reference count by one so they would never be deleted from the system. > > > > Regards, > > > > Curt. > > > > i have continued my random optimizations to flightgear (and simgear, this > > > > > time). > > > > > > changes in the attached diffs > > > ================= > > > > > > in simgear: > > > * made textures load on demand when SGMaterial::get_state() is first > > > called > > > (the only drawback so far is get_state() becoming non-const) > > > * osg::State held a reference to its "parent" material in userData - > > > this prevented the reference count for SGMaterial from dropping to 0 > > > > Regards, > > > > Curt. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
