[Flightgear-devel] Multithreading pattern and frame rate

2010-11-20 Thread fierst42
Hi All

I rebuilt from GIT this morning. I am sitting on the runway at a quiet 
airport, doing absolutely nothing. No AI traffic, no other multiplayers 
around. Global weather. I have no other applications running, except 
fgrun. And I am waiting until terrasync has updated all it wants to 
update and the log window is showing no more activity. I have done two 
tests, directly after eachother. Same conditions, same METAR.


Compared to a version of one week ago, there seems to be a different 
pattern in CPU usage.

The older GIT version had one thread 75% busy and two more threads of 
about 30% busy and a frame rate of a little over 40 FPS.
In the version of today, I have one thread 85% busy and one other thread 
about 20% busy and the frame rate is about 20 FPS.

When I take off and during flight, I have one thread 100% busy all the 
time, where in the previous versions there were only brief moments that 
one of the threads was running at 100%.

I know there has been done some work on caching and loading of 3D 
elements... perhaps it is related...

Has anyone else noticed a difference?

m


--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multithreading pattern and frame rate

2010-11-20 Thread Tim Moore
Lots of variables. It sounds like you're using up-to-date scenery, so there
could have been a change there. New code has also been checked in that deals
with paging in the scenery, though I doubt that's causing the problems you
are seeing.

Can you check out of git the source code from a week ago, compile it, run
it, and see if you still see the same performance difference?

FPS is not a good performance metric. If you have vsync turned on in your
driver, a very tiny change in the time of an operation can make a big fps
difference. Also, everyone has different hardware... It's more useful to
look at the OSG statistics (choose Cycle On-Screen Statistics twice) and
report the times reported for each traversal. Or include a screenshot of
them.

Did you update anything else, like OSG?

Tim

On Sat, Nov 20, 2010 at 11:33 AM, fiers...@zonnet.nl wrote:

 Hi All

 I rebuilt from GIT this morning. I am sitting on the runway at a quiet
 airport, doing absolutely nothing. No AI traffic, no other multiplayers
 around. Global weather. I have no other applications running, except
 fgrun. And I am waiting until terrasync has updated all it wants to
 update and the log window is showing no more activity. I have done two
 tests, directly after eachother. Same conditions, same METAR.


 Compared to a version of one week ago, there seems to be a different
 pattern in CPU usage.

 The older GIT version had one thread 75% busy and two more threads of
 about 30% busy and a frame rate of a little over 40 FPS.
 In the version of today, I have one thread 85% busy and one other thread
 about 20% busy and the frame rate is about 20 FPS.

 When I take off and during flight, I have one thread 100% busy all the
 time, where in the previous versions there were only brief moments that
 one of the threads was running at 100%.

 I know there has been done some work on caching and loading of 3D
 elements... perhaps it is related...

 Has anyone else noticed a difference?

 m



 --
 Beautiful is writing same markup. Internet Explorer 9 supports
 standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
 Spend less time writing and  rewriting code and more time creating great
 experiences on the web. Be a part of the beta today
 http://p.sf.net/sfu/msIE9-sfdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multithreading pattern and frame rate

2010-11-20 Thread ThorstenB
From: fiers...@zo... - 2010-11-20 10:33
 I have done two  tests, directly after eachother. Same conditions, same METAR.

One thing to note here is that, prior to yesterday's update, the size
of the scenery area loaded/rendered at start-up did _not_ depend on
the visibility (weather/METAR), neither on any visibility configured
manually (command-line etc). FG would always load the same number of
tiles at start-up - no matter what the weather/configuration was. This
was a bug, since the tile manager didn't bother about visibility
changes - and METAR/manually configured visibility was only set
_after_ the initial scenery was already scheduled.
This has changed yesterday: now, once visibility increases
considerably (METAR is received, weather configured) this, as
expected, causes an immediate update and loading of all required
scenery.

So, even if you have configured the same conditions/METAR, this may
not be a fair comparison. It's possible that METAR specifies 10nm
visibility, but an older FG build would still render only 5nm at
start-up (meaning only a quarter of the actually required scenery
tiles). With older FG builds, you should wait for METAR to be
received, then fly (or reposition) your plane several miles away from
the initial location. This location change triggers the scenery
scheduler which only then takes the correct visibility into account.
I doubt though that this could cause such a severe drop of framerate.
And which plane are you using for this comparison?

cheers,
Thorsten

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel