On Monday 03 Aug 2009, Curtis Olson wrote:
> I'll toss in a couple thoughts.  Running on 4 processors
> (quad-core AMD 64 bit machine) and 4 dual-head nvidia cards we
> split the render task up into a bunch of subthreads.  The overall
> CPU load was pretty balanced and each CPU ran at about 40-60%
> utilization.

That's interesting.  Could you elaborate on that a little more i.e. 
did you split a single scene into 'render boxes' or were you, in 
effect, running four discrete but 'collaborative' instances, each 
just looking in a different direction?
> I don't know all the solid conclusions we can derive from this,
> but it seems to me that until we have a single CPU that is fully
> saturated, adding cores and adding threads will not buy us
> anything in terms of end-to-end performance.  Drawing the scene
> still is (and always has been) our main bottleneck by far.

What proportion of the drawing task is occupied with assembling the 
scene objects, compared with passing the assembled data to the 
video card for display?  (I'm just wondering about the scope for 
box-rendering here)

One of the big problems I had with FG was its pseudo asynchronous 
operation, which still meant that the rates at which you could run 
things like the FDM, autopilot and Nasal were effectively limited 
by the frame rate and which could lead to an aircraft being stable 
on one system but unstable on another.  I would really like to see 
these subsystems running on their own cores, or even more 
preferably, on their own networked hardware, so that I could run 
them at much higher and guaranteed rates.

I think the bottom line is that FG is simply going to have to face 
up to this issue at some point.  A few people here have been 
bringing this topic up for a few years and now that multicore 
processors are the norm it's clear that the issue isn't going to go 
away.  Like it or not, and I mean no offence or criticism by this, 
the current FG architecture is now obsolete.  While single core and 
single processor systems were the norm it was fine - the software 
design was well fitted to the systems on which it ran - but 
parallel processing has always been the way things were going to 
go.  It has been inevitable ever since super-computer designers 
realised that the only way that ever increasing performance could 
be achieved was by parallelism and now it's well and truly on the 

Of course, it's not going to be easy, but denying it won't make the 
issue go away.

Tied in with this, I think, is that FG is still very much a 
developer-led project, so the developers, by and large, only work 
on things that interest them.  However, the FG user base is 
constantly growing, and will continue to grow, and at some point FG 
will have to become user-led if it is to become more than just a 
stage for its developers to perform upon.  FG will, if it has not 
already, reach the point where it is bigger than its developers and 
the project should dictate what the developers do, rather than the 
other way around.

I think its a sad fact of reality but I think that FG has reached 
the point where FG development needs to be actively managed and 
directed, and not just left to the whims and desires of its 

Like I said, I mean no criticism of the developers by this; they 
have achieved an immense amount by getting FG to this point, but in 
getting FG this far they've made FG into a bigger thing that needs 
handling differently if it isn't going to stagnate and be left 


Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Flightgear-devel mailing list

Reply via email to