With regard to the speed of loading models from Nasal into the scenery I was writing about a while ago, I have made some discovery yesterday.
I was testing a setup in 2.0.0 with some heavy numerics running on the second CPU, and this pushed the behaviour of the framerate into the behaviour I was observing with GIT. I did some follow-up testing and discovered that while multithreading is apparently by default on in 2.0.0, it is off in GIT. I subsequently observed that when I run GIT with multithreading on in GIT, the load on the second CPU is usually modest (5-10%, but when I load the initial configuration of clouds into the scenery, it increases to 80-90%. In addition, the experience of flying with heavy cloud configurations was much smoother in GIT and the multithreading seems to take care of a good part of the difference I have seen between 2.0.0 and GIT (I don't know if all - that requires some systematic testing). So this ends up to a sugestive picture - local weather actually benefits a lot from a second CPU on board, and although it can be flown with just a single CPU, it runs much smoother with a second one (which raises the question - does Heiko who reported the framerate drop on loading models for the first time usually fly with a single CPU machine?). I still have no real understanding why this is so, or why loading a large number of *identical* models into the scenery should take a long time (I would think that one can make use of the fact that there are really multiple copies of the same model around to speed things up, and while I was told that OSG does that automatically, this isn't what I observe) - if anyone can aid my understanding, please do so, it would be rather important. Cheers, * Thorsten > To follow up on my previous message: > >> Not so with my GIT binary: Loading of the initial cloud configuration >> brings me down to 4 fps, and every time (!) a cloud is loaded from the >> buffer my framerate drops from 34+ to something like 20+ for a moment - >> which makes the whole experience rather jerky. > > I have now made a series of tests to quantify the effect. The test > situation is > > --disable-fullscreen --geometry=1200x900 --aircraft=ufo --airport=KINS > --timeofday=noon --disable-real-weather-fetch > > 2.0.0 prebuilt: > > empty sky: 190 fps > with 3d clouds: 128 fps > with static cold sector tile: 90 fps when loaded, > 34 while loading > with dynamical cold sector tile: 45 fps when loaded, > 30 while loading > > (note that this is *not* a fair comparison between standard 3d clouds and > local weather clouds as the visibility and cloud view distance is rather > different - not the point of the exercise) > > GIT built against my self-compiled OSG 2.9.10: > > empty sky: 234 fps > with 3d clouds: 145 fps > with static cold sector tile: 95 fps when loaded, > 6 (!) while loading > with dynamical cold sector tile: 46 fps when loaded, >7 (!) while loading > > GIT build against the prebuilt OSG 2.9.6 coming with my 2.0.0 binary: > > empty sky: 230 fps > with 3d clouds: 128 fps > cold sector, static: 90 fps when loaded, > 6 while loading > cold sector dynamical: 48 fps when loaded, > 8 while loading > >> From this I conclude that what I'm seeing is not associated with OSG or > the way I compile OSG. I also conclude that it's not related to > performance issues of GIT in general - I get actually a better framerate > than in 2.0.0 with GIT once things are loaded. ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
