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
