Re: [Flightgear-devel] Again: Threaded FlightGear ?
you are doing yourself a ***HUGE*** favor if you keep all the opengl calls caged in a single thread. OK, this is obvious. I obviously misinterpreted the original statement: Threading *within* *an* OpenGL context. I wanted to point out that threading goes well with OpenGL as long as all OpenGL calls come from the same thread, which is exactly what you're saying above. Apart from this, I'd go even further: Most stuff can be decoupled so that the computation can even be split between different processes, which may even run on different machines. Take again visualization (OTW) for example: It's (dynamic) input is position and orientation of the aircraft(s), output is altitude above ground. These are rather minor amounts of data which can easily go across a network. Most commercial FTDs and FNPTs (including these of the company I used to work for) do it that way. It pays to identify and separate the involved concepts using well-defined interfaces. Doing so leads to clean, extensible and efficient design. Best regards, -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
I know that threading inside an OpenGL context is considered to be a no-no, Why? References? A problem I see is that threading isn't implemented in a standard compliant way on Linux (probably one of the more important platforms), but maybe one can work around that problem. -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Gerhard Wesp writes: I know that threading inside an OpenGL context is considered to be a no-no, Why? You can think of OpenGL as a state machine. The sequence of calls you feed into it determines the path that the state machine takes. And that determines what get's rendered. An analogy would be following directions from city A to city B. You are fed a seqence of commands turn left, turn right, go straight, etc. If you follow these commands in the exact sequence you recieve them, you will end up at the correctly place. So imagine if you are getting your city to city directions from two threads (or two people sitting in the back seat.) If these two people are *very* carefully working together to give you directions to the same place, you could be successful. But if these two people are giving you directions to two different destinations, and worse, they are interleaving their commands with each other, and you have no choice but to honor them in the order you receive them, imagine the chaos that could ensue. You will most likely crash in the ditch when you get a turn left at a place where there is no road going left, and the best case scenario is that you don't arrive at either destination. It's very much like that in OpenGL. If you have two threads sending the card opengl commands to do different things, and these commands get interleaved, who knows what you get as the end result, and more likely you'll crash in the ditch before you get to any destination at all. Given all the complexities of threading, you will soon discover that you are doing yourself a ***HUGE*** favor if you keep all the opengl calls caged in a single thread. References? Personal experience and advice from the experts. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Curtis L. Olson [EMAIL PROTECTED] wrote: An analogy would be following directions from city A to city B. You are fed a seqence of commands turn left, turn right, go straight, etc. If you follow these commands in the exact sequence you recieve them, you will end up at the correctly place. So imagine if you are getting your city to city directions from two threads (or two people sitting in the back seat.) which is quite a common situation :-))) _But_, you could still split the whole stuff into parts ! Part one: Sound synthesis; Part two: Audio output. If you have to render the sound fonts in software (brain work) and you have a SMP machine (guys on backseat) you'd be well advised to separate the synthesis of the different words that have to be spoken into several threads - I assume that the guys are a bit dumb, like the computers are. The missing bit is the job to serialize the output of the prebuild wave files. This would heavily improve the output of spoken commands as long as you have multiple guys available dealing with the task of synthesizing the sound. You have to take into account the overhead for the serialization. I guess with increasing complexity/feature-richness of FlightGear it will some day be inevitable to employ such a serialization machine, scanning the list of objects to be rendered on screen. As far as I know from reading this list the serialization is currently done by arranging several jobs in the program main rendering loop. I can understand that Curt avoids this restructuration like a plague because it involves a large rewrite of now well proven, difficult part of the code. _Very_ nice analogy ! Thanks to Curt, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
On Wednesday, July 2, 2003, at 01:00 PM, [EMAIL PROTECTED] wrote: Message: 3 Date: 2 Jul 2003 16:30:37 GMT From: Martin Spott [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Again: Threaded FlightGear ? To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Curtis L. Olson [EMAIL PROTECTED] wrote: Just my two cents... OpenGL can be multi-threaded on some implementations. Apple, (who by no coincidence sells lots of MP machines), has the GL_APPLE_FENCE extension for inserting synchronization primitives into the OpenGL pipeline. Of course, one has to use these carefully (avoid stalling the pipeline) to see the benefits, but there are real benefits and I've seen the proof. BUT (and this a big but), as far as FlightGear is concerned, you'd be *much* better off focusing your energy on optimizing for single processor case first. There is *tons* of room for improvement in the rendering of static geometry. The current system is extremely inefficient, and this will only get worse as the performance gap between CPU's and GPU's continues to grow. To rehash what I've shown before, the average number of triangles per node in the current scene graph is about 5. When you add up the state changes, culling, and other overhead, (keeping in mind that drivers/cards tend to perform best with large pieces of data and few state changes), you begin to get an idea about how inefficient the geometry rendering is. Another example: I get about 50 fps with geometry enabled, and 100fps with it disabled (comment out draw_geometry() in ssgVtxTable to see what I mean). You'd think it would be much more than that, but the culling operations keep it from going any higher - and this is on a 1Ghz CPU. In short, rendering is CPU-bound, not GPU-bound. To fix this, we need more triangles per scene graph node, and probably should sort our nodes (by state) to get even fewer state changes. That this may require completely redoing the scenery subsystem, I will ignore ;-) I don't really know how to go about fixing these things, I'm just reporting on what I think needs work - not that this needs to be done now, of course (optimization comes last in my book). I just anticipate it becoming more of a headache in the future when we try to increase scene complexity. Of course, it will need to be fixed to be able to compare visually with GPU-optimized sims. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine wrote: Norman Vine wrote: Ummm. 533 math $ c++ -O3 -o test test.cxx fastmath.cxx Ooops pardon the line noise Pfew, you scared me :-D I didn't reinitialize the clock in my test program Here are the updated test results *NICE* win on the log() call And quite accurate also, error around 0.01% 537 math $ ./test log3014 fast_log 120 exp3996 fast_exp 2634 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Erik Hofman writes:
Yes, I mean 250% increase. But I doubt many others would see such an
increase because my framerates were already close to freezing point...
Ummm.
533 math
$ c++ -O3 -o test test.cxx fastmath.cxx
534 math
$ ./test
log3044
fast_log 3164
exp7150
fast_exp 9764
cut -- test.cxx
#include fastmath.hxx
#include stdio.h
#include time.h
int main(int argc, char **argv)
{
float a = 1.2;
float b;
int i;
int n=1000;
int start = clock();
for( i=0; in; i++ )
{
b = log(a);
a += 0.1;
}
printf(log%d\n,clock()-start);
for( i=0; in; i++ )
{
b = fast_log(a);
a += 0.1;
}
printf(fast_log %d\n,clock()-start);
for( i=0; in; i++ )
{
b = exp(a);
a += 0.1;
}
printf(exp%d\n,clock()-start);
for( i=0; in; i++ )
{
b = fast_exp(a);
a += 0.1;
}
printf(fast_exp %d\n,clock()-start);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine wrote: Ummm. 533 math $ c++ -O3 -o test test.cxx fastmath.cxx Ooops pardon the line noise I didn't reinitialize the clock in my test program Here are the updated test results *NICE* win on the log() call 537 math $ ./test log3014 fast_log 120 exp3996 fast_exp 2634 Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Christopher S Horler wrote: Erik, Can you confirm exactly what you mean - 2.5x existing frame rate? Yes, I mean 250% increase. But I doubt many others would see such an increase because my framerates were already close to freezing point... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
So what frame rate are you actually getting and on what hardware? On Sat, 2003-06-28 at 09:23, Erik Hofman wrote: Christopher S Horler wrote: Erik, Can you confirm exactly what you mean - 2.5x existing frame rate? Yes, I mean 250% increase. But I doubt many others would see such an increase because my framerates were already close to freezing point... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Christopher S Horler wrote: So what frame rate are you actually getting and on what hardware? If you promise not to laugh at me: 3~4 fps on a sgi O2 (default Cessna, I get 7~10 fps when selecting models without 3D panel). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Nice box On Sat, 2003-06-28 at 11:00, Erik Hofman wrote: Christopher S Horler wrote: So what frame rate are you actually getting and on what hardware? If you promise not to laugh at me: 3~4 fps on a sgi O2 (default Cessna, I get 7~10 fps when selecting models without 3D panel). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Martin Spott [EMAIL PROTECTED] wrote: I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run FlightGear on this machine. This won't work out as long as most of the processing in FlightGear is done in a single thread because each of the CPU's is not that fast. O.k., I actually bought that machine. It's a 7015 R50 with 4 GByte of RAM. As it is not the appropriate platform for FlightGear, maybe I can offer some horsepower for Scenery generation when the next round comes near. I think it is probably well suited for this job ;-) Thanks for your commitment to this discussion, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Erik Hofman writes:
Norman Vine wrote:
http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz
You have to let the process run much longer
until things like ssgMakeMipMaps don't show up in the top 100 :-)
There is a new file after running FlightGear for about 23 minutes.
Hmm
[40] 24.060 1.7% 29.3% 61.140 4.3% 2038 __powf (libm.so:
fpow.c, 145)
[96] 19.500 1.4% 35.3% 19.500 1.4%650 __exp (libm.so:
exp.c, 103)
[102] 17.460 1.2% 37.8% 17.460 1.2%582 __log (libm.so:
log.c, 207)
I don't think these ever showed up before :-(
Maybe this will help show how not to have pow() show up anyway
The others often have work arounds too.
Norman
#include math.h
#include stdio.h
#include time.h
int main(int argc, char **argv)
{
double color[3];
double sun_factor = 1;
int i;
int n=100;
int start = clock();
for( i=0; in; i++ )
{
color[0] = pow(sun_factor, 0.25);
color[1] = pow(sun_factor, 0.50);
color[2] = pow(sun_factor, 4.0);
}
printf(%d %f %f %f\n,clock()-start, color[0],color[1],color[2]);
start = clock();
for( i=0; in; i++ )
{
color[1] = sqrt(sun_factor);
color[0] = sqrt(color[1]);
color[2] = sun_factor * sun_factor;
color[2] *= color[2];
}
printf(%d %f %f %f\n,clock()-start, color[0],color[1],color[2]);
start = clock();
for( i=0; in; i++ )
{
//if( sun_factor == 1 )
//{
color[0] = 1;
color[1] = 1;
color[2] = 1;
//}
//else if( sun_factor == 0 )
//{
//color[0] = 0;
//color[1] = 0;
//color[2] = 0;
//}
}
printf(%d %f %f %f\n,clock()-start, color[0],color[1],color[2]);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine wrote: Hmm [40] 24.060 1.7% 29.3% 61.140 4.3% 2038 __powf (libm.so: fpow.c, 145) [96] 19.500 1.4% 35.3% 19.500 1.4%650 __exp (libm.so: exp.c, 103) [102] 17.460 1.2% 37.8% 17.460 1.2%582 __log (libm.so: log.c, 207) I don't think these ever showed up before :-( Maybe this will help show how not to have pow() show up anyway The others often have work arounds too. Thanks Norman, this gave a framerate boost of 2.5x on my system! I never thought using pow() would give such a performance reduction, but if I had know I would have optimized this before. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Again: Threaded FlightGear ?
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run FlightGear on this machine. This won't work out as long as most of the processing in FlightGear is done in a single thread because each of the CPU's is not that fast. As Curt is moving lots of code around to make FlightGear more versatile (I'm amazed that the programm still works after all this shuffling ;-) I'd like to ask if someone intends to subdivide the current tasks into different threads in future !? I know that threading inside an OpenGL context is considered to be a no-no, but probably there are already several sub-tasks that could be separated. Please don't consider this as a feature request, it's just me being curious. Sincerely there are more urgent jobs to do - enabling flying below bridges or through the Sutro tower, for instance ;-)) Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Martin Spott wrote: I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run FlightGear on this machine. This won't work out as long as most of the processing in FlightGear is done in a single thread because each of the CPU's is not that fast. Things that come in mind are: * Sound thread (should be fairly easy) * FDM thread/process * Maybe (just maybe) an I/O thread? But I guess that's about it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Martin Spott wrote: I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run FlightGear on this machine. This won't work out as long as most of the processing in FlightGear is done in a single thread because each of the CPU's is not that fast. Things that come in mind are: * Sound thread (should be fairly easy) * FDM thread/process Or even multiple FDM threads for when we get mulitple FDM support. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Erik Hofman writes: Martin Spott wrote: I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run FlightGear on this machine. This won't work out as long as most of the processing in FlightGear is done in a single thread because each of the CPU's is not that fast. Things that come in mind are: * Sound thread (should be fairly easy) * FDM thread/process * Maybe (just maybe) an I/O thread? But I guess that's about it. Personally, I'm not a huge fan of threading unless absolutely necessary. Threading adds a tremendous amount of complexity, it can hide extremely subtle bugs that are extremely difficult to track down and only show up under rare circumstances. I saw a lot of nifty looking examples of threading in school, but once you hit an application with the complexities of FlightGear, you have to be *really* careful, and *really* know what you are doing, or you end up making a *really* big mess. That is a pretty hefty price to pay. We put in a *huge* amount of work into the threaded tile pager and I spent many, many evenings staring at code, scratching my head, running flightgear for hours trying to track down subtle, rare gotchas. Think about this another way ... do a profile of flightgear. I bet you will find that the graphics rendering portion of FlightGear takes 90-95% of the entire application work load. If you can't find a way to split that up (which is nigh unto impossible since this is all involving opengl which inherently resists threading without a *huge* amount of effort and complexity[1]) then threading the other 5-10% of the work isn't going to gain you a whole lot. [1] The Performer scene graph has app-cull-draw threads, but you pay the price with an very large amount of complexity, bloat, and some performance loss for single CPU machines. On a single CPU machine, plib will almost always render the same model faster than performer. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Curtis L. Olson wrote: Erik Hofman writes: * Sound thread (should be fairly easy) * FDM thread/process * Maybe (just maybe) an I/O thread? But I guess that's about it. Personally, I'm not a huge fan of threading unless absolutely necessary. Threading adds a tremendous amount of complexity, it can hide extremely subtle bugs that are extremely difficult to track down and only show up under rare circumstances. I agree with this. That's why I prefer a FDM process rather than a FDM thread. But subtle changes (for example moving the sound into a thread) may eventually result in higher framerates even for single processor machines. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
On Tue, 24 Jun 2003, Erik Hofman wrote: Martin Spott wrote: I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run FlightGear on this machine. This won't work out as long as most of the processing in FlightGear is done in a single thread because each of the CPU's is not that fast. Things that come in mind are: * Sound thread (should be fairly easy) * FDM thread/process * Maybe (just maybe) an I/O thread? But I guess that's about it. Dunno if this is valid, but here's my thoughts. It would be interesting to profile fg and determine exactly where the time is spent. I'd guess that even a low spec machince could handle the simulation aspects of the program; is it not the the rendering that consumes the majority of the processing time? I'm not quite sure how threads can help, except possibly with the simulation of hundreds of aircraft at once? Although threading out scenery loading and sound both appear good ideas. It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
On Tue, 24 Jun 2003 07:46:39 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: [snip] Think about this another way ... do a profile of flightgear. I bet you will find that the graphics rendering portion of FlightGear takes 90-95% of the entire application work load. If you can't find a way to split that up (which is nigh unto impossible since this is all involving opengl which inherently resists threading without a *huge* amount of effort and complexity[1]) then threading the other 5-10% of the work isn't going to gain you a whole lot. For the record, the top 20 functions as reported by oprofile-0.5.3 are: Cpu type: PIII Cpu speed was (MHz estimation) : 807.98 Counter 0 counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 40 % symbol name 1.02981 ssgSelector::select(unsigned) 1.03343 FGHitList::IntersectBranch(ssgBranch*, double (*) [4], double*, double*) 1.07417 ssgEntity::dirtyBSphere() 1.10563 ssgEntity::getTraversalMask() 1.13437 FGInstrumentLayer::transform() const 1.15995 SGPropertyNode::hash_table::get(char const*) 1.35369 ssgLeaf::cull(sgFrustum*, float (*) [4], int) 1.47658 slEnvelope::applyToVolume(unsigned char*, unsigned char*, int, int) 1.53362 sgXformPnt3(float*, float const*, float const (*) [4]) 1.60288 ssgVtxTable::getNumColours() 1.77896 ssgBranch::recalcBSphere() 2.05825 sgdMakeNormal(double*, double const*, double const*, double const*) 2.1051 SGPropertyNode::hash_table::bucket::get_entry(char const*, bool) 2.2873 sgFrustum::contains(sgSphere const*) const 2.69288 SGPropertyNode::hash_table::hashcode(char const*) 3.03894 ssgVtxTable::getNumVertices() 3.16909 ssgSimpleState::apply() 3.2234 ssgVtxTable::draw_geometry() 4.77468 ssgBranch::cull(sgFrustum*, float (*) [4], int) 4.77513 ssgEntity::cull_test(sgFrustum*, float (*) [4], int) Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
On Tue, 24 Jun 2003, Curtis L. Olson wrote: I'm not quite sure how threads can help, except possibly with the simulation of hundreds of aircraft at once? In the case of simulating 100's of aircraft, threads might provide a convenient programming abstraction, but they would add the overhead of many context switches. User space threads are pretty quick, but still there is some overhead to switch to a new thread. Well, with threads you can spread the load across CPUs. So it is not just a convience for the programmer. Afterall, the original poster bought up the matter of big boxes with lots of slow processors. The only way to utilise those is with multiple threads and/or processes. But I'm definetly not suggesting that fg would gain alot through threads, because the biggest job (rendering) is not suitable. It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? By default, OpenGL will texture, light, and shade the lines of the wire frame so this might not necessarily run as fast as you'd hope... :-) LOL, okay. Stumped :) Hey how about no display at all... Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Bernie Bright wrote: For the record, the top 20 functions as reported by oprofile-0.5.3 are: The problem is that (as Norman pointed out in the past) optimizing may result in a much larger increas in framerate due to the way OpenGL can handle processor and graphics tasks simulataniously. Cpu type: PIII Cpu speed was (MHz estimation) : 807.98 Counter 0 counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 40 % symbol name 1.15995 SGPropertyNode::hash_table::get(char const*) 2.1051 SGPropertyNode::hash_table::bucket::get_entry(char const*, bool) 2.69288 SGPropertyNode::hash_table::hashcode(char const*) We need to use more pointers to property nodes instead of fgGetString type of function calls. 1.35369 ssgLeaf::cull(sgFrustum*, float (*) [4], int) 1.77896 ssgBranch::recalcBSphere() 1.07417 ssgEntity::dirtyBSphere() 4.77468 ssgBranch::cull(sgFrustum*, float (*) [4], int) 4.77513 ssgEntity::cull_test(sgFrustum*, float (*) [4], int) These are all Bsphere related functons. So the most time consuming functions really are SGPropertyNode::hash_table and ssgBranch:: BSphere Hmmm, this makes me wonder ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Lawrence Manning writes: It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? I think you wil find that wireframe mode is slower esp if you turn off the cloud textures Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Lawrence Manning [EMAIL PROTECTED] wrote: It would be interesting to profile fg and determine exactly where the time is spent. I'd guess that even a low spec machince could handle the simulation aspects of the program; is it not the the rendering that consumes the majority of the processing time? This was my initial thought when I bought an SGI Octane with bells 'n whistles. But I was proven to be wrong. Erik's O2 is definitely faster with FlightGear even though the O2's graphics subsystem is much slower. This is hardly texture-related, his machine simply has the faster CPU. Unfortunately the tax authorities prevented me from buying the desired CPU upgrade for the Octane It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? Is there a wireframe-mode in FlightGear ? I thought even the shaded terrain display has been removed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine writes: Curtis L. Olson writes: Think about this another way ... do a profile of flightgear. I bet you will find that the graphics rendering portion of FlightGear takes 90-95% of the entire application work load. FWIW here are my results from the last time I profiled FGFS trying to determine what percentage of time was actually spent drawing This was about a year ago, but I doubt if things have changed much % cumulative self self total time seconds secondscalls ns/call ns/call name 59.20 0.74 0.7440047 18478.29 19976.49 fgRenderFrame(void) 20.00 0.99 0.2539218 6374.62 6374.62 fgUpdateTimeDepCalcs(void) 16.00 1.19 0.20 fgMainLoop(void) Norman Also we need to be careful to consider that actual profiling numbers could vary drastically between platforms, video cards, cpus, operating systems, video drivers, profiling tools :-), etc. And also it should be pointed out that FlightGear has a *very* CPU/time expensive startup and initialization sequence. This also needs to be considered when interpretting the profiling numbers. The longer you run flightgear, the more the actual running app numbers will become dominant, and the less dominant the initialization numbers will be. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Martin Spott writes: This was my initial thought when I bought an SGI Octane with bells 'n whistles. But I was proven to be wrong. Erik's O2 is definitely faster with FlightGear even though the O2's graphics subsystem is much slower. This is hardly texture-related, his machine simply has the faster CPU. Unfortunately the tax authorities prevented me from buying the desired CPU upgrade for the Octane It would be interesting to do some tests in wireframe mode on a low spec machine and see how it performs? Is there a wireframe-mode in FlightGear ? I thought even the shaded terrain display has been removed, The wireframe mode got broke somewhere along the way, but I fixed it recently. I haven't tried lately to see if it's broke again, but last I checked it did work. It can be useful for debugging your models/terrain because it will show you the exact triangle layout ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Curtis L. Olson writes: Norman Vine writes: Curtis L. Olson writes: Think about this another way ... do a profile of flightgear. I bet you will find that the graphics rendering portion of FlightGear takes 90-95% of the entire application work load. FWIW here are my results from the last time I profiled FGFS trying to determine what percentage of time was actually spent drawing This was about a year ago, but I doubt if things have changed much % cumulative self self total time seconds secondscalls ns/call ns/call name 59.20 0.74 0.7440047 18478.29 19976.49 fgRenderFrame(void) 20.00 0.99 0.2539218 6374.62 6374.62 fgUpdateTimeDepCalcs(void) 16.00 1.19 0.20 fgMainLoop(void) Norman Also we need to be careful to consider that actual profiling numbers could vary drastically between platforms, video cards, cpus, operating systems, video drivers, profiling tools :-), etc. This is all very true, the above figures are on a 733mz machine with a geForce2 And also it should be pointed out that FlightGear has a *very* CPU/time expensive startup and initialization sequence. This also needs to be considered when interpretting the profiling numbers. The longer you run flightgear, the more the actual running app numbers will become dominant, and the less dominant the initialization numbers will be. Note fgUpdateTimeDepCalcs() and fgMainLoop() are *only* called after all initialization is done, so if anything, they actually consumed a bit more then their recorded usage time whereas fgRenderFrame is the opposite :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine writes: Note fgUpdateTimeDepCalcs() and fgMainLoop() are *only* called after all initialization is done, so if anything, they actually consumed a bit more then their recorded usage time whereas fgRenderFrame is the opposite :-) True ... what I was trying to communicate is that if something like a property string fetch shows up high in list of time consuming function calls, we don't necessarily know if most of those calls were made during initialization where it doesn't really matter, or during the main loop where it matters a lot more. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Curtis L. Olson wrote: True ... what I was trying to communicate is that if something like a property string fetch shows up high in list of time consuming function calls, we don't necessarily know if most of those calls were made during initialization where it doesn't really matter, or during the main loop where it matters a lot more. This is the top 20 of FlightGear CVS on my O2: http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz The nice thing is that it also contains OpneGL calls. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Martin Spott [EMAIL PROTECTED] wrote: Sincerely there are more urgent jobs to do - enabling flying below bridges or through the Sutro tower, for instance ;-)) I have to correct this statement: It _is_ possible to fly through the Sutro tower, but it's not that easy to view from inside the cockpit of a YF-23. Switching to chase-view in the last seconds before 'entry' makes it easier :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Lawrence Manning writes: Well, with threads you can spread the load across CPUs. So it is not just a convience for the programmer. Afterall, the original poster bought up the matter of big boxes with lots of slow processors. Right, but we should also bear in mind the a) typical flightgear platform, b) the fact that the bulk of the flightgear application work is in rendering the 3d display, c) the practical problems that things like opengl and our property system is not thread safe, d) the complexity and subtle bugs that threading *very* often introduces when added to large complex applications. I don't want to add a bunch of threads if the only reason is that threads looked cool and fun when we studied them in a computer science class, and there is one person with a machine that could benefit. If someone does want to go thread crazy, please do it in a fork of the source code. I'd be interested in hearing the results and any issues or problems that were encountered as well as any performance gains realized. The only way to utilise those is with multiple threads and/or processes. But I'm definetly not suggesting that fg would gain alot through threads, because the biggest job (rendering) is not suitable. Did anyone say if this multi-cpu machine had an accelerated opengl graphics system? If it doesn't then this whole discussion is pointless. :-) LOL, okay. Stumped :) Hey how about no display at all... You can almost do that ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Erik Hofman writes: Curtis L. Olson wrote: True ... what I was trying to communicate is that if something like a property string fetch shows up high in list of time consuming function calls, we don't necessarily know if most of those calls were made during initialization where it doesn't really matter, or during the main loop where it matters a lot more. This is the top 20 of FlightGear CVS on my O2: http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz The nice thing is that it also contains OpneGL calls. Does anyone have any ideas for factoring out the startup/initialization time from these performance reports? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Curtis L. Olson wrote: Did anyone say if this multi-cpu machine had an accelerated opengl graphics system? If it doesn't then this whole discussion is pointless. :-) Maybe not, threaded MESA? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Erik Hofman wrote: I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run FlightGear on this machine. This won't work out a Things that come in mind are: * Sound thread (should be fairly easy) * FDM thread/process * Maybe (just maybe) an I/O thread? Hmm, either an I/O thread would make a huge difference, or it makes no difference at all: http://www.a1.nl/~ehofman/fgfs/download/io.output.gz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Again: Threaded FlightGear ?
Curtis L. Olson writes: Erik Hofman writes: Curtis L. Olson wrote: True ... what I was trying to communicate is that if something like a property string fetch shows up high in list of time consuming function calls, we don't necessarily know if most of those calls were made during initialization where it doesn't really matter, or during the main loop where it matters a lot more. This is the top 20 of FlightGear CVS on my O2: http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz You have to let the process run much longer until things like ssgMakeMipMaps don't show up in the top 100 :-) The nice thing is that it also contains OpneGL calls. That is good and bad the bad part is that it takes time to instrument the profiling and since we can't do anything about speeding up the low level code why do we want it influencing the run time ?? Does anyone have any ideas for factoring out the startup/initialization time from these performance reports? Sure, just let FlightGear run for a minimum of 20 minutes when profilng Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
On Tue, 24 Jun 2003, Curtis L. Olson wrote: Lawrence Manning writes: Well, with threads you can spread the load across CPUs. So it is not just a convience for the programmer. Afterall, the original poster bought up the matter of big boxes with lots of slow processors. Right, but we should also bear in mind the a) typical flightgear platform, b) the fact that the bulk of the flightgear application work is in rendering the 3d display, c) the practical problems that things like opengl and our property system is not thread safe, d) the complexity and subtle bugs that threading *very* often introduces when added to large complex applications. Completely agree. I probably should have kept my mouth (fingers) shut. Only certain applications lend themselves strongly towards threading, and FlightGear obviosly isn't one of them. My sole expereince with threads is on Win32 (C/MFC stuff) and I never want to do it again, so understand completly where you are coming from. I don't want to add a bunch of threads if the only reason is that threads looked cool and fun when we studied them in a computer science class, and there is one person with a machine that could benefit. Definetly agree on that! Had the threads are cool, processes suck, from my OS Theory prof as well. I pointed out that its a nice theory, but dosn't work quite like that in the real world ;-) Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine wrote: You have to let the process run much longer until things like ssgMakeMipMaps don't show up in the top 100 :-) The nice thing is that it also contains OpneGL calls. That is good and bad the bad part is that it takes time to instrument the profiling and since we can't do anything about speeding up the low level code why do we want it influencing the run time ?? Sometimes you can avoid time consuming OpenGL calls this way. Does anyone have any ideas for factoring out the startup/initialization time from these performance reports? Sure, just let FlightGear run for a minimum of 20 minutes when profiling This is always a good excuse to use FlightGear ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine wrote: http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz You have to let the process run much longer until things like ssgMakeMipMaps don't show up in the top 100 :-) There is a new file after running FlightGear for about 23 minutes. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
On 24 Jun 2003 16:32:17 GMT, Martin Spott [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Martin Spott [EMAIL PROTECTED] wrote: Sincerely there are more urgent jobs to do - enabling flying below bridges or through the Sutro tower, for instance ;-)) I have to correct this statement: It _is_ possible to fly through the Sutro tower, but it's not that easy to view from inside the cockpit of a YF-23. Switching to chase-view in the last seconds before 'entry' makes it easier :-) ..uhmmm, does the tower model include the RL brace wiring? ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
