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. 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
>
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
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
