Re: [Flightgear-devel] Multithreading support

2009-08-05 Thread Curtis Olson
On Tue, Aug 4, 2009 at 1:21 PM, leee l...@spatial.plus.com wrote:

 Fair enough.  To be honest, the question was at the limits of my
 understanding.  What inspired it though is that when I'm rendering
 any of my 3D stuff the rendering process is distributed across
 several systems - the single scene is split into many separate
 boxes, and because the performance of the different systems in my
 render farm varies widely, I typically split the scene up into
 20x10 boxes.  Now this is all ray-traced software rendering, not
 hardware rendering, and there is an additional overhead because the
 scene needs to be split up and the subsequent results combined, but
 the bottom line is that this technique can allow much more
 processing power to be used and certainly enough to compensate for
 the overhead.  I've honestly no idea though, how far, or even if
 this technique can be applied to h/w rendering.


Ray tracing (based on my fading college experience) is an awesome example of
a task that can be parallelized very well.  If each node has the entire
scene definition, then the individual nodes can render individual pixels
with no need to communicate with other nodes. (That may not be quite
entirely true (?) if more advanced rendering techniques are being used, but
I'm just guessing.)  So at the start you just divide up the pixels amongst
your render farm and let the go.  Once all the pixels are rendered, you can
just assemble them into the completed image.


 I'm not really thinking in terms of 'threading' at all, which I
 think is a very limited and half-house sort of technique.  But
 neither though do I think it needs to be thought of as a pure real
 time system.  Rather, I'm thinking in terms of the external FDM
 mechanism already present in FG.  Running the FDM on it's own
 hardware system doesn't need to be any more real time than the FDM
 running within FG on the same system but because it's not going to
 be limited by the frame rate it could safely be run much faster and
 with proportionately more consistency than with FG.  If you're
 running it at say 100Hz within FG I would expect to be able to run
 it several times faster, if not tens of times faster if the system
 it was running on wasn't spending most of its time rendering.
 You'll still get a variation ...


Maybe a lot more variation than you would expect ... especially if other
things are running on that core at the same time...


 in the rate that the FDM runs at but I
 suspect that the variation would be about the same in absolute
 terms.  Let's say that if we get a variation of +/- 10 iteration
 difference per second running within FG it would probably be about
 the same running on its own system, but as we're running at a
 higher rate the difference is proprotionally smaller, perhaps down
 from 10% to 1%.


If you sync to the vblank signal in FlightGear (and have enough cpu/graphics
hp) you can run at a very solid 60hz (or whatever rate your display
refreshes at.)  If you don't quite have that amount of hp consistently for
all situations, there is a throttle-hz property you can set to force a
slower update rate (maybe 30 or 20 fps ... ideally you want an even divider
into your display update rate.)  If consistent frame rates are your goal,
there are ways to achieve that.  However, because of the variability of
systems and personal preferences, we don't turn a lot of this on by default.

Like I say, I don't think we need to achieve strict real time
 processing here, but we could achieve both higher rates and
 proportionally smaller variations in those rates using the existing
 timing techniques in FG.


And I would argue that this is a true statement, even without changing a
line of code within the project.  There are a lot of system configuration
and application configuration things a person can do to achieve these
goals.  I'm not sure you could improve on that by splitting the FDM off to a
separate core/task/process.

One issue you are probably seeing is that even though the FlightGear flight
dynamics engines are setup to run at a guaranteed fixed rate of 120hz
already, the autopilot update rate floats with the graphics update rate.
Ideally the autopilot would update at the same rate as the flight dynamics.
This was the case at one point in the project, but somehow that got lost
during some portion of some restructure project.

I absolutely agree with you - it's finding the parallelism that's
 the hardest part but things like the FDM, autopilot and Nasal do
 seem like obvious candidates.  Even if we can't precisely balance
 the load, we could still improve the performance of parts of FG.
 Sure, processors are getting faster, if not by increases in clock
 speed, which has largely reached or are rapidly approaching a
 plateau, then by improving performance per clock and VLIW, but that
 too can only be taken so far.  Barring quantum computing, which is
 still questionable, parallelism is really the only way to go.


We have been nervous that CPU 

Re: [Flightgear-devel] Multithreading support

2009-08-05 Thread leee
On Wednesday 05 Aug 2009, Curtis Olson wrote:
 On Tue, Aug 4, 2009 at 1:21 PM, leee wrote:
  Fair enough.  To be honest, the question was at the limits of
  my understanding.  What inspired it though is that when I'm
  rendering any of my 3D stuff the rendering process is
  distributed across several systems - the single scene is split
  into many separate boxes, and because the performance of the
  different systems in my render farm varies widely, I typically
  split the scene up into 20x10 boxes.  Now this is all
  ray-traced software rendering, not hardware rendering, and
  there is an additional overhead because the scene needs to be
  split up and the subsequent results combined, but the bottom
  line is that this technique can allow much more processing
  power to be used and certainly enough to compensate for the
  overhead.  I've honestly no idea though, how far, or even if
  this technique can be applied to h/w rendering.

 Ray tracing (based on my fading college experience) is an awesome
 example of a task that can be parallelized very well.  If each
 node has the entire scene definition, then the individual nodes
 can render individual pixels with no need to communicate with
 other nodes. (That may not be quite entirely true (?) if more
 advanced rendering techniques are being used, but I'm just
 guessing.)  So at the start you just divide up the pixels amongst
 your render farm and let the go.  Once all the pixels are
 rendered, you can just assemble them into the completed image.

I think you've pretty much got it right, except that I don't think 
there's any need for internode comms.  More advanced techniques 
seem to boil down to rendering different channels separately as 
separate passes i.e. you might render the specular, refelection and 
shadow channels in separate passes, but even then I don't think 
there's any need internode comms.  Other options are to render 
different frames on different nodes, or if you're doing 3D stuff, 
to render alternate fields, which in some ways is just a special 
case of box rendering.  Like I said, I've no idea as to just how 
these different techniques might be applied to h/w rendering, but I 
am sure that some solution will be found - perhaps the SLI and 
Crossfire solutions are a start on this, but it's just 
incomprehensible that h/w rendering is going to be limited to a 
single process forever.


  I'm not really thinking in terms of 'threading' at all, which I
  think is a very limited and half-house sort of technique.  But
  neither though do I think it needs to be thought of as a pure
  real time system.  Rather, I'm thinking in terms of the
  external FDM mechanism already present in FG.  Running the FDM
  on it's own hardware system doesn't need to be any more real
  time than the FDM running within FG on the same system but
  because it's not going to be limited by the frame rate it could
  safely be run much faster and with proportionately more
  consistency than with FG.  If you're running it at say 100Hz
  within FG I would expect to be able to run it several times
  faster, if not tens of times faster if the system it was
  running on wasn't spending most of its time rendering. You'll
  still get a variation ...

 Maybe a lot more variation than you would expect ... especially
 if other things are running on that core at the same time...

Well, I think that argument applies equally to running FG as a 
single process on any system.  Just as you wouldn't expect to run 
the current FG architecture on a system running other stuff too, 
and expect it to work well, you wouldn't expect to run the 
distributed subsystems on their own systems and not expect them to 
be impacted by other workloads.


  in the rate that the FDM runs at but I
  suspect that the variation would be about the same in absolute
  terms.  Let's say that if we get a variation of +/- 10
  iteration difference per second running within FG it would
  probably be about the same running on its own system, but as
  we're running at a higher rate the difference is proprotionally
  smaller, perhaps down from 10% to 1%.

 If you sync to the vblank signal in FlightGear (and have enough
 cpu/graphics hp) you can run at a very solid 60hz (or whatever
 rate your display refreshes at.)  If you don't quite have that
 amount of hp consistently for all situations, there is a
 throttle-hz property you can set to force a slower update rate
 (maybe 30 or 20 fps ... ideally you want an even divider into
 your display update rate.)  If consistent frame rates are your
 goal, there are ways to achieve that.  However, because of the
 variability of systems and personal preferences, we don't turn a
 lot of this on by default.

Heh - I can't help seeing that last sentence as a tacit admission 
that FG _is_ pushing the limits of commodity h/w.  It's great if 
people can afford the latest and greatest kit and dump their old 
stuff (to me, hopefully, so I can slot them into my render farm - 
I've 

Re: [Flightgear-devel] Multithreading support

2009-08-04 Thread leee
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 
desktop.

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 
developers.

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 
behind.

LeeE

--
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multithreading support

2009-08-04 Thread Curtis Olson
On Tue, Aug 4, 2009 at 11:05 AM, leee l...@spatial.plus.com wrote:

 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?


This was a single instance of FlightGear rendering to 8 separate windows.


 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)


I'm not sure I fully understand your question, but a lot of this is
dependent on how much of the opengl pipeline is implemented in hardware
versus libraries/drivers on a particular video card and operating system.
 (Quality and efficiency of the actual implementation also factors in here.)
 There can be huge variability here across systems.

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.


What you are referring to here is less of a threaded system and more of a
real time system. You want guarantees that a function will execute at a
specific fixed rate.  Threads don't automatically give you that, in fact
they don't give you that at all.  You need a real time system with some sort
of external timmer trigger and an interrupt service routine to get really
tight timings.

Personally I've seen several threaded applications that *thought* they were
getting their routines to run at a particular rate until they dug in and
actually timed what was going on and throught a bit more about how their
code was structured and what the thread primatives they were using actually
offered.


 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.


The only point I would make here is that threading and timing is an
extremely snakey area to deal with.  Most people I've talked to don't
understand the nuances of what's really going on nearly as well as they
imagine they do.  I certainly admit to gaps and weaknesses in my own
understanding.  And I certainly don't mean to imply that anyone
participating in this discussion falls under that same description.

Here's my question to you:

Once you've split the flight dynamics (for example) off into a separate
thread/process running on it's own dedicated core, what mechanism do you
propose to use to force it to run at a specific fixed and guaranteed rate?
 And this is an honest question, bucause the generic cross-platform timing
mechanisms I'm aware have few guarantees.  You might have the best luck with
a busy/wait type architecture, but then you are needlessly burning CPU most
of the time, since the flight dynamics will consume maybe 0.0001% of the
dedicated CPU.  Or do you somehow setup a counter and a compare register and
use that to trigger an interrupt at a fixed interval and run an iteration of
the flight dynamics out of the interrupt service routine?  But can you do
that in a cross-platform independent way?  Can you even get access to these
low level mechanisms from most modern operating systems?

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
 desktop.


And the big challenge with modern super computer clusters is to find the
parallelism in your task (as much that exists) or to redesign the task to
improve the parallelism.  (Well that and how to keep 2000 8-core machines
running at the same time in a closet from reaching temperatures so hot they
melt their way through to the earth's core.)  But you are faced with really
fast processors and in comparison, very slow interconnects between nodes ...
even with fast/low latency networks like myrinet and infiniband.

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


What I have always hoped to communicate is that we need solid justification
before adding more complex 

Re: [Flightgear-devel] Multithreading support

2009-08-04 Thread Anders Gidenstam
On Tue, 4 Aug 2009, leee wrote:

 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.

Moving these tasks into different threads would only bring you a cart load 
of indeterminism due to the whims of the OS scheduler, page faults, 
interrupts, bus contention or network latency etc etc..

The crucial observation you missed here is that these tasks need to run 
interleaved at high (120+ Hz) guaranteed rates in /simulated/ 
time not necessarily in real time. (Sampling pilot inputs needs to be done 
at what rate? 30Hz?).
Interleaving them in one thread is really the very best you can do 
assuming your processor core is fast enough (and I'd be surprised if it 
isn't, e.g. JSBSim needs in the order of 1% of the capacity of a 
not so current core to run a typical model in real-time).

IMHO the one important threading benefit is if we could get all of the 
rendering off the main simulation loop, meaning that the model runs 
independent of the presentation. (Ok, expensive environment eye candy 
like the traffic manager or wild fire CA would also be beneficial to move 
into threads - but they don't have tight synchronization needs wrt the 
main aircraft.)

Apart from that the potential for improvements with threading I can see is 
in the rendering system, and that's perhaps a more general OSG and OpenGL 
vendor playing field than a FlightGear one.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multithreading support

2009-08-04 Thread leee
On Tuesday 04 Aug 2009, Curtis Olson wrote:
 On Tue, Aug 4, 2009 at 11:05 AM, leee l...@spatial.plus.com 
wrote:
  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?

 This was a single instance of FlightGear rendering to 8 separate
 windows.

Ok - ta.

  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)

 I'm not sure I fully understand your question, but a lot of this
 is dependent on how much of the opengl pipeline is implemented in
 hardware versus libraries/drivers on a particular video card and
 operating system. (Quality and efficiency of the actual
 implementation also factors in here.) There can be huge
 variability here across systems.

Fair enough.  To be honest, the question was at the limits of my 
understanding.  What inspired it though is that when I'm rendering 
any of my 3D stuff the rendering process is distributed across 
several systems - the single scene is split into many separate 
boxes, and because the performance of the different systems in my 
render farm varies widely, I typically split the scene up into 
20x10 boxes.  Now this is all ray-traced software rendering, not 
hardware rendering, and there is an additional overhead because the 
scene needs to be split up and the subsequent results combined, but 
the bottom line is that this technique can allow much more 
processing power to be used and certainly enough to compensate for 
the overhead.  I've honestly no idea though, how far, or even if 
this technique can be applied to h/w rendering.

 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.

 What you are referring to here is less of a threaded system and
 more of a real time system. You want guarantees that a function
 will execute at a specific fixed rate.  Threads don't
 automatically give you that, in fact they don't give you that at
 all.  You need a real time system with some sort of external
 timmer trigger and an interrupt service routine to get really
 tight timings.

 Personally I've seen several threaded applications that *thought*
 they were getting their routines to run at a particular rate
 until they dug in and actually timed what was going on and
 throught a bit more about how their code was structured and what
 the thread primatives they were using actually offered.

I'm not really thinking in terms of 'threading' at all, which I 
think is a very limited and half-house sort of technique.  But 
neither though do I think it needs to be thought of as a pure real 
time system.  Rather, I'm thinking in terms of the external FDM 
mechanism already present in FG.  Running the FDM on it's own 
hardware system doesn't need to be any more real time than the FDM 
running within FG on the same system but because it's not going to 
be limited by the frame rate it could safely be run much faster and 
with proportionately more consistency than with FG.  If you're 
running it at say 100Hz within FG I would expect to be able to run 
it several times faster, if not tens of times faster if the system 
it was running on wasn't spending most of its time rendering.  
You'll still get a variation in the rate that the FDM runs at but I 
suspect that the variation would be about the same in absolute 
terms.  Let's say that if we get a variation of +/- 10 iteration 
difference per second running within FG it would probably be about 
the same running on its own system, but as we're running at a 
higher rate the difference is proprotionally smaller, perhaps down 
from 10% to 1%.

  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.

 The only point I would make here is that threading and timing is
 an extremely snakey area to deal with.  Most people I've talked
 to don't understand the nuances of what's really going on nearly
 as well as they imagine they do.  I certainly admit to gaps and
 weaknesses in my own understanding.  And I certainly don't 

Re: [Flightgear-devel] Multithreading support

2009-08-04 Thread Erik Hofman


Anders Gidenstam wrote:

 IMHO the one important threading benefit is if we could get all of the 
 rendering off the main simulation loop, meaning that the model runs 
 independent of the presentation. (Ok, expensive environment eye candy 
 like the traffic manager or wild fire CA would also be beneficial to move 
 into threads - but they don't have tight synchronization needs wrt the 
 main aircraft.)

This might actually be better left to a multiplayer-like client process 
that feeds one or more FlightGear servers, instead of placing it in it's 
own thread within FlightGear.

Erik

--
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multithreading support

2009-08-04 Thread Erik Hofman


leee wrote:

 I'm not really thinking in terms of 'threading' at all, which I 
 think is a very limited and half-house sort of technique.  But 
 neither though do I think it needs to be thought of as a pure real 
 time system.  Rather, I'm thinking in terms of the external FDM 
 mechanism already present in FG.  Running the FDM on it's own 
 hardware system doesn't need to be any more real time than the FDM 
 running within FG on the same system but because it's not going to 
 be limited by the frame rate it could safely be run much faster and 
 with proportionately more consistency than with FG.  If you're 
 running it at say 100Hz within FG I would expect to be able to run 
 it several times faster, if not tens of times faster if the system 
 it was running on wasn't spending most of its time rendering.  
 You'll still get a variation in the rate that the FDM runs at but I 
 suspect that the variation would be about the same in absolute 
 terms.  Let's say that if we get a variation of +/- 10 iteration 
 difference per second running within FG it would probably be about 
 the same running on its own system, but as we're running at a 
 higher rate the difference is proprotionally smaller, perhaps down 
 from 10% to 1%.

I agree here, putting the FDM in it's own process would be a good idea.

Erik

--
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multithreading support

2009-08-03 Thread Curtis Olson
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.

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.

If you do some profiling, I think you will find that the rendering tasks
consumes by far the largest percentage of the overall load.

The one class of tasks that can impact performance are tasks that take a
long time to complete and can cause a disruption in smooth continuous frame
rates.

Fetching weather is one such task because the network communication can take
several seconds if not more to complete.  It makes sense to split this off
into a separate thread and we have done this.

Scenery paging is another big candidate for threading.  However, the problem
with scenery paging is that it triggers opengl commands which cannot be
fully threaded.  So there will always need to be some tradeoff when loading
and paging models on the fly ... stuffing a big texture a big chunk of
geometry over the bus onto a video card (or video cards) can disrupt the
render pipeline and can cause a break in frame rates.  There are ways to
alleviate some of these problems, and we do some of them already, and
probably there are more things we could do to interleave opengl work into
the main render task.  But this is the biggest current disruption to frame
rates and it's not something that can be fixed by throwing more cores or
more threads at the problem.

I'm definitely not anti-threads, however threads do impose a lot of extra
complexity, they can hide bugs that are very difficult to reproduce and
track down, very hard to spot by just reading the code, etc.  So in my view,
I like to keep the brakes on adding new threads unless there is a
demonstratable advantage or clear problem that is being fixed.  Adding
threads for the sake of adding threads because that is a cool way to
architect the system, is in most cases just asking for a lot of extra
trouble.  The exception might be with smaller systems written by a single
highly skilled developer who can keep the whole threading and timing
architecture in their head, and who is very experienced at designing and
debugging threaded applications.  One thing we need to be aware of with
FlightGear is that we have people from all ranges of backgrounds diddling in
the code and submitting patches.  Things like threading architectures fall
down *very* quickly when someone touches them who isn't skilled with threads
and also very familiar with our particular threaded architecture and all the
nuances and interactions between data values and timing issues ... and these
are *very* complex in an application of the scope of FlightGear.

Best regards,

Curt.


On Mon, Aug 3, 2009 at 11:44 AM, Johnathan Van Why  wrote:

 With much of our increasing processing power coming from multiprocessing,
 it seems to be a good idea to make FlightGear fully multithreading-capable.
 However, I have not found any one thread of discussion about this.

 We have been going through a major change in the graphics system, namely
 the change from OpenGL to Open Scene Graph. Since we have accomplished (most
 of) this change, I believe we can do other major rewrites, such as is needed
 for multiprocessing support.

 There are many ways we could design FlightGear with multiprocessing
 support. Thus, there needs to be a discussion as to how to do it best.

 Personally, I think we should continue the separation of the loading
 thread we already have separated (I recall it helped reduce multiplayer lag)
 by delegating all tasks likely to block to separate threads (if we haven't
 already done so with the loading thread.) We can then have one compute
 thread for each processing core.

 Within the compute threads, I think we could cooperatively schedule the
 various subsystems. Some subsystems, namely graphics, may have
 multiprocessing support built in and can be run by multiple threads at once
 (eventually this could become all the subsystems.)

 However, there are other ways. The last two paragraphs are my thoughts on
 it, but I do not understand the code well. There are other options, such as
 using the OS to schedule them for us (that seems it might be a little
 OS-specific, requiring several implementations of varying performance.)

 I hope we can come up with some way to do this that everyone is happy with,
 and implement the change in the near future.

 Any thoughts appreciated,
 --Johnathan


 --
 Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
 trial. 

Re: [Flightgear-devel] Multithreading support

2009-08-03 Thread Torsten Dreyer
 Fetching weather is one such task because the network communication can
 take several seconds if not more to complete.  It makes sense to split this
 off into a separate thread and we have done this.
And it allready does it that way.

Torsten

--
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel