RE: [Flightgear-devel] Framerate drop
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Indeed, I esp like the super impostor i.e the 'distant' clouds are clumped together into a mosaic of clouds as an impostor where each cloud used to make the mosaic is an impostor itself :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
Norman Vine writes: Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Indeed, I esp like the super impostor i.e the 'distant' clouds are clumped together into a mosaic of clouds as an impostor where each cloud used to make the mosaic is an impostor itself :-) I wonder how well that would map into a hierarchical scene graph structure where a particular node could be rendered as an imposter of all it's children. (Not my original idea) :-) Curt. -- Curtis Olson 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] Framerate drop
Curtis L. Olson writes: Norman Vine writes: Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Indeed, I esp like the super impostor i.e the 'distant' clouds are clumped together into a mosaic of clouds as an impostor where each cloud used to make the mosaic is an impostor itself :-) I wonder how well that would map into a hierarchical scene graph structure where a particular node could be rendered as an imposter of all it's children. (Not my original idea) :-) If you have an Impostor Node type, It should 'just' work, even to the point of updating itself if an when needed due to lighting and or positional change :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Framerate drop
Norman Vine wrote: I noticed a *very* significant fps drop with the new scenry objects in San Francisco which may be due to having many small textures rather then having the small textures combined into one as is done with the Panel I use texture repetition for the buildings. Is it possible to achieve that when they are grouped in a single file ? - Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
Frederic BOUVIER writes: Norman Vine wrote: I noticed a *very* significant fps drop with the new scenry objects in San Francisco which may be due to having many small textures rather then having the small textures combined into one as is done with the Panel I use texture repetition for the buildings. Is it possible to achieve that when they are grouped in a single file ? Hmm, I don't really know but probably not, at least through PLIB Are there lower LOD models that are used when the buildings are distant ? If so can these be untextured ? It's disturbing that even at take off from KSFO that the FPS drops so dramatically when looking in the 'right' direction when these things are so far away Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Framerate drop
Norman Vine wrote: Frederic BOUVIER writes: Norman Vine wrote: I noticed a *very* significant fps drop with the new scenry objects in San Francisco which may be due to having many small textures rather then having the small textures combined into one as is done with the Panel I use texture repetition for the buildings. Is it possible to achieve that when they are grouped in a single file ? Hmm, I don't really know but probably not, at least through PLIB Are there lower LOD models that are used when the buildings are distant ? If so can these be untextured ? It's disturbing that even at take off from KSFO that the FPS drops so dramatically when looking in the 'right' direction when these things are so far away Ok, I will add another LOD level. But you'll have to wait 2 weeks because I am away for work. BTW, what are the good trade-off, performance wise ? - big texture vs small repeated texture, - texture vs geometry - colour vs texture Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Framerate drop
Norman Vine [EMAIL PROTECTED] wrote: It's disturbing that even at take off from KSFO that the FPS drops so dramatically when looking in the 'right' direction when these things are so far away In my opinion this is the only annoyance in FlightGear that really hurts noticeably. Even when you start at KHAF and look into the direction of SFO downtown or KSFO airport the framerate drops heavily - despite all the mountains that stand in between. FG would improve heavily if objects would get clipped out that can't be visible by any means. Especially when you're near ground at takeoff or touchdown all the currently employed LOD algorithms don't help very much in this case, 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] Framerate drop
Martin Spott writes: Norman Vine [EMAIL PROTECTED] wrote: It's disturbing that even at take off from KSFO that the FPS drops so dramatically when looking in the 'right' direction when these things are so far away In my opinion this is the only annoyance in FlightGear that really hurts noticeably. Even when you start at KHAF and look into the direction of SFO downtown or KSFO airport the framerate drops heavily - despite all the mountains that stand in between. FG would improve heavily if objects would get clipped out that can't be visible by any means. Especially when you're near ground at takeoff or touchdown all the currently employed LOD algorithms don't help very much in this case, Doing line of sight occlusion would help in this case only until you got airborne nor would it help in the case when there were no intervening mountains so I am not sure if the extra complexity would help all that much. I am much more interested in coming with a LOD scheme that helps in the general case before adding any extra overhead :-) If you want to play with the code IMO the easiest thing would be to restructure the SceneGraph during the tilemanager prepnode() call to reorder graph traversal so that tiles were rendered by increasing distance from the viewpoint. This can help somet, I experimented a bit in the old days before we switched to using SSG Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
Frederic BOUVIER writes: BTW, what are the good trade-off, performance wise ? - big texture vs small repeated texture, - texture vs geometry - colour vs texture Good questions ! Rule of thumb is fewer is better but it all depends on your GFX card and what else you are displaying :-) There are many papers on this here is one of the latest http://www-imagis.imag.fr/Publications/2003/DDSD03/bc03.pdf This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Framerate drop
Hi, Just moved house, having all kinds of problems... but I have still get a deep sense of curiousity about all this. Is the scene calculated in the main loop? - Do we check these buildings are there every cycle? Or is the implementation more along the lines of; calculated in advance and setting a variable to switch execution to recalculate at some predetermined point? On Tue, 2003-09-02 at 12:07, Frederic BOUVIER wrote: Norman Vine wrote: I noticed a *very* significant fps drop with the new scenry objects in San Francisco which may be due to having many small textures rather then having the small textures combined into one as is done with the Panel I use texture repetition for the buildings. Is it possible to achieve that when they are grouped in a single file ? - Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
Christopher S Horler writes: Just moved house, having all kinds of problems... but I have still get a deep sense of curiousity about all this. Is the scene calculated in the main loop? - Do we check these buildings are there every cycle? Or is the implementation more along the lines of; calculated in advance and setting a variable to switch execution to recalculate at some predetermined point? In the future Please bottom post http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html Almost all of the objects in FlightGear the HUD and Panel are two notable exceptions are 'just rendered' during the Scene Graph traversal if Scene Graphs are new to you see http://plib.sourceforge.net/ssg/index.html google( tutorial scene graph ) should yield lots of info too HTH Norman On Tue, 2003-09-02 at 12:07, Frederic BOUVIER wrote: Norman Vine wrote: I noticed a *very* significant fps drop with the new scenry objects in San Francisco which may be due to having many small textures rather then having the small textures combined into one as is done with the Panel I use texture repetition for the buildings. Is it possible to achieve that when they are grouped in a single file ? - Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Framerate drop
David Megginson writes: I've noticed a substantial (50%) framerate drop with the recent revisions to FlightGear. I'll try some profiling when I have time, but is it possible that some of the recent changes to airport handling have introduced some slow code into the main loop? It could also be a problem with the new nvidia drivers, of course. Please disregard -- Mozilla had left some big processes running in the background, hogging the CPU. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
David Megginson writes: I've noticed a substantial (50%) framerate drop with the recent revisions to FlightGear. I'll try some profiling when I have time, but is it possible that some of the recent changes to airport handling have introduced some slow code into the main loop? It could also be a problem with the new nvidia drivers, of course. Is this everywhere or just at KSFO ? I noticed a *very* significant fps drop with the new scenry objects in San Francisco which may be due to having many small textures rather then having the small textures combined into one as is done with the Panel Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
but 2.0 is in part a 'rconciliation' of the various 'propriatary' extensions and the inclusion of things that almost all of the manufacturers have done to support M$oft DX#. And this driver has more of these upcoming features then any of the previous ones. So this driver is Nvidia's tool to create facts how the upcoming OpenGL-2.0 standard should look like !? ;-) 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] FrameRate !!
moved to the devel list for general info WOW ! This appears to be a bug in the latest NVIDIA drivers Reverting to any of several of their earlier ones and the problem goes away. I'll have to investigate this some more at some point but for now I will just be happy that I know how to get around it :-)) FYI This 'bug' appears on Win2k using the NVIDIA 28.32 reference driver with a geForce2 GTS Bummer -- This driver has lots of neat new features OpenGL 2.0 that I wanted to experiment with :-( Hopefully this won't be a problem in the next release ! Norman -Original Message- From: Norman Vine [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 07, 2002 10:32 AM To: 'David Megginson' Cc: 'Curtis Olson' Subject: RE: [Flightgear-devel] FrameRate !! Curt David Something changed recently so that when the HUD is displayed the framerate drops dramatically when the Menu is hidden ~25% This is most easily seen when in the minimal HUD by toggling the Menu. I have looked for the cause but nothing obvious has popped out at me Any Ideas ?? Other then this it appears as if the FrameRate is back up to 'close' to what it was a month ago :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Norman Vine writes: This appears to be a bug in the latest NVIDIA drivers Reverting to any of several of their earlier ones and the problem goes away. Just for the benefit of everyone else, Norm means the latest NVIDIA *windows* drivers. I'm not aware of any similar problem with the Linux drivers, but I have not tested them hard. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
David Megginson writes: Norman Vine writes: This appears to be a bug in the latest NVIDIA drivers Reverting to any of several of their earlier ones and the problem goes away. Just for the benefit of everyone else, Norm means the latest NVIDIA *windows* drivers. I'm not aware of any similar problem with the Linux drivers, but I have not tested them hard. As I said in the original post This 'bug' appears on Win2k using the NVIDIA 28.32 reference driver with a geForce2 GTS But if anyone else sees the framerate when displaying the HUD much slower i.e. anything less then ~95% of the framerate of not displaying the HUD then I would suspect your driver if you have a NVIDIA card and I would REALLY APPRECIATE hearing about it. what's-wasting-a-couple-of-days'ly yrs Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
This driver has lots of neat new features OpenGL 2.0 Do they really implement the upcoming OpenGL-2.0 features in hardware or do they tend to rely on fallbacks ? It's somewhat astonishing that they already provide a driver for a still not really existent OpenGL standard. Do they create their own upcoming 'standard' ? 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] FrameRate !!
Martin Spott writes: This driver has lots of neat new features OpenGL 2.0 Do they really implement the upcoming OpenGL-2.0 features in hardware or do they tend to rely on fallbacks ? It's somewhat astonishing that they already provide a driver for a still not really existent OpenGL standard. Do they create their own upcoming 'standard' ? Well I lied a little :-) but 2.0 is in part a 'rconciliation' of the various 'propriatary' extensions and the inclusion of things that almost all of the manufacturers have done to support M$oft DX#. And this driver has more of these upcoming features then any of the previous ones. Specifically it has hardware friendly 'render to texture' which IMHO will be way Cool i.e. Dynamic texture ala Vertex Shaders Since these are NVIDIA unified drivers if your card doesn't support something in hardware it has a software fallback but at least you can get to play :-) Cheers Noman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: (fwd) Re: [Flightgear-devel] FrameRate !!
I think a series of demos would be a great idea. It would also be nice if there were demos for various terrain types (stress testing). I fly around the Seattle area simply because the mountains drastically impact frame rate. Not only the mountains. ATIS display has _heavy_ impact. I usually get around 100 fps inside a 800x600 window (BETA Radeon DRI driver, only 40 fps left at 1600x1024 ), at KSEA I only get 30-50 fps because of ATIS display (with today's current CVS). Unfortunately there is no command line switch to disable ATIS, 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: (fwd) Re: [Flightgear-devel] FrameRate !!
On Monday 08 April 2002 07:41 am, you wrote: I think a series of demos would be a great idea. It would also be nice if there were demos for various terrain types (stress testing). I fly around the Seattle area simply because the mountains drastically impact frame rate. Not only the mountains. ATIS display has _heavy_ impact. I usually get around 100 fps inside a 800x600 window (BETA Radeon DRI driver, only 40 fps left at 1600x1024 ), at KSEA I only get 30-50 fps because of ATIS display (with today's current CVS). Unfortunately there is no command line switch to disable ATIS, Martin. even if you flip the comm radio to the standby freq? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: (fwd) Re: [Flightgear-devel] FrameRate !!
On Monday 08 April 2002 07:41 am, you wrote: Not only the mountains. ATIS display has _heavy_ impact. I usually get around 100 fps inside a 800x600 window (BETA Radeon DRI driver, only 40 fps left at 1600x1024 ), at KSEA I only get 30-50 fps because of ATIS display (with today's current CVS). Unfortunately there is no command line switch to disable ATIS, even if you flip the comm radio to the standby freq? Aaaah, thanks for the hint. I usually fly without panel - and I'm lacking experience in operating these 'modern' ;-) communication techniques. When I flip frequencies at the upper left radio (c310u3a) ATIS display disappears and I get noticeable more fps - but not that much as I expected, 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] FrameRate !!
Jim Wilson wrote: Alex Perry [EMAIL PROTECTED] said: Gadds. I don't know...even with an almost completely idle cpu occaisonally I seem to have these weird performance discrepencies. It isn't heat, so who knows. Maybe its something weird about the kernel. Later without changing anything it looked much better, aproximately a 10% improvement over previous. Sorry about the confusion. Have you got a variable speed processor, like a notebook kind ? If you don't compile support for the feature into the processor, the system will run with whatever the BIOS thought you should use. On one of my machines, there is a 5/6 ratio, aka 16% performance loss. Well its a PIII 750 desktop. It isn't trying to save power. Suppose it could be heat related...but I don't really know if this system steps down speed or just halts when the heat hits threshold. I konw that the P4 reduces speed when it gets too hot. (the PIII might do it, too) It's nice to know that your CPU works slower under heavy load... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Norman Vine wrote: This profiling run might be enlightening time seconds secondscalls us/call us/call name 4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char const 3.49 2.57 0.12 2352563 0.05 0.05 fgGetDouble(char const 3.20 2.92 0.11 1617164 0.07 0.07 fgGetNode(char const 2.33 3.00 0.08 1222609 0.07 0.07 fgGetInt(char const *, 1.16 3.31 0.04 2109792 0.02 0.02 fgGetString(char const IT's very interesting to see that fgGetBool takes a significantly longer time to run (3x - 10x as long). Perhaps we can optimze the result by returning a int instead of a bool (afaik is int supposed to be the 'fastest' type for any system)? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Christian Mayer writes: Norman Vine wrote: This profiling run might be enlightening IT's very interesting to see that fgGetBool takes a significantly longer time to run (3x - 10x as long). Perhaps we can optimze the result by returning a int instead of a bool (afaik is int supposed to be the 'fastest' type for any system)? Things have changed considerably in 24 hours :-))) --preliminary profiling results from this AM-- % 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) 4.80 1.25 0.0640686 1474.71 1474.71 fgReshape(int, int) 0.00 1.25 0.00 15103364 0.00 0.00 FGColumnVector3::Debug(int) It seems to be worthwhile trying to get fgRehape() out of the loop This is only necessary for determining if the Panel display has been toggled or switched so we should be able to get this out of the main loop also :-) Folks might want to update their files for a 'plesant' surprise Good work David ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
From: Christian Mayer [EMAIL PROTECTED] Norman Vine wrote: This profiling run might be enlightening time seconds secondscalls us/call us/call name 4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char const 3.49 2.57 0.12 2352563 0.05 0.05 fgGetDouble(char const 3.20 2.92 0.11 1617164 0.07 0.07 fgGetNode(char const 2.33 3.00 0.08 1222609 0.07 0.07 fgGetInt(char const *, 1.16 3.31 0.04 2109792 0.02 0.02 fgGetString(char const IT's very interesting to see that fgGetBool takes a significantly longer time to run (3x - 10x as long). Perhaps we can optimze the result by returning a int instead of a bool (afaik is int supposed to be the 'fastest' type for any system)? CU, Christian MSVC emits a warning like this : c:\flightgear\cvs\flightgear\src\model\model.cxx(354) : warning C4800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance warning) This can be an hint that converting int to bool is not gratis ! Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Norman Vine wrote: Christian Mayer writes: Norman Vine wrote: This profiling run might be enlightening IT's very interesting to see that fgGetBool takes a significantly longer time to run (3x - 10x as long). Perhaps we can optimze the result by returning a int instead of a bool (afaik is int supposed to be the 'fastest' type for any system)? Things have changed considerably in 24 hours :-))) --preliminary profiling results from this AM-- % 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) 4.80 1.25 0.0640686 1474.71 1474.71 fgReshape(int, int) 0.00 1.25 0.00 15103364 0.00 0.00 FGColumnVector3::Debug(int) It seems to be worthwhile trying to get fgRehape() out of the loop This is only necessary for determining if the Panel display has been toggled or switched so we should be able to get this out of the main loop also :-) Folks might want to update their files for a 'plesant' surprise THat's nice, but the 'problem' with fgGetBool is still existant (and it's getting worse as we are using the property system more and more). CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Hello, How about a reproductible way to benchmark FlightGear ? Something like q1test or q2test in Quake. That is : an automated sequence of flight during, say 30s to 2mn, along a predetermined path from KSFO with different views. This could be presented has a demo and at the end, a summary on framerate and performance numbers will be displayed. This could be controlled by command line options ( --start-demo-mode=once|loop, --display-perf-summary ) Just a thought, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Hello, How about a reproductible way to benchmark FlightGear ? Something like q1test or q2test in Quake. That is : an automated sequence of flight during, say 30s to 2mn, along a predetermined path from KSFO with different views. This could be presented has a demo and at the end, a summary on framerate and performance numbers will be displayed. This could be controlled by command line options ( --start-demo-mode=once|loop, --display-perf-summary ) Just a thought, -Fred I think a series of demos would be a great idea. It would also be nice if there were demos for various terrain types (stress testing). I fly around the Seattle area simply because the mountains drastically impact frame rate. If I fly around where I live, I can get rates of upwards of 150 FPS, but Seattle gives me 35-50. I also like seeing what'e left of Mt. St. Helen ;). Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Christian Mayer writes: THat's nice, but the 'problem' with fgGetBool is still existant (and it's getting worse as we are using the property system more and more). fgGetBool may be taking longer because it's accessing a property that's not typed as a bool. If you have this in an init file my-propfalse/my-prop or this on the command line -prop:/my-prop=false the property is stored as a string with type 'unknown' until someone ties it to something or sets its value (either of which will change the type). That means that it will be converted from a char * string to bool every time it is accessed. The fix is to use my-prop type=boolfalse/my-prop to give a hint to the property manager that the value can be stored as a bool. It might be worth adding another optimization to the property manager to cache previously-converted values -- I'll have to think about that (it won't work at all with tied properties, of course). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Jim Wilson writes: Haven't had a chance to look through the changes, but umm...I'm seeing a 25% decrease in framerate after this mornings patches. Sorry. (Voodoo3/P3-750mhz/100mhz MB/384mb Ram) Ouch! Have you upgraded SimGear as well? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: Haven't had a chance to look through the changes, but umm...I'm seeing a 25% decrease in framerate after this mornings patches. Sorry. (Voodoo3/P3-750mhz/100mhz MB/384mb Ram) Ouch! Have you upgraded SimGear as well? Gadds. I don't know...even with an almost completely idle cpu occaisonally I seem to have these weird performance discrepencies. It isn't heat, so who knows. Maybe its something weird about the kernel. Later without changing anything it looked much better, aproximately a 10% improvement over previous. Sorry about the confusion. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Gadds. I don't know...even with an almost completely idle cpu occaisonally I seem to have these weird performance discrepencies. It isn't heat, so who knows. Maybe its something weird about the kernel. Later without changing anything it looked much better, aproximately a 10% improvement over previous. Sorry about the confusion. Have you got a variable speed processor, like a notebook kind ? If you don't compile support for the feature into the processor, the system will run with whatever the BIOS thought you should use. On one of my machines, there is a 5/6 ratio, aka 16% performance loss. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Alex Perry [EMAIL PROTECTED] said: Gadds. I don't know...even with an almost completely idle cpu occaisonally I seem to have these weird performance discrepencies. It isn't heat, so who knows. Maybe its something weird about the kernel. Later without changing anything it looked much better, aproximately a 10% improvement over previous. Sorry about the confusion. Have you got a variable speed processor, like a notebook kind ? If you don't compile support for the feature into the processor, the system will run with whatever the BIOS thought you should use. On one of my machines, there is a 5/6 ratio, aka 16% performance loss. Well its a PIII 750 desktop. It isn't trying to save power. Suppose it could be heat related...but I don't really know if this system steps down speed or just halts when the heat hits threshold. It does seem like it is happening after doing a full rebuild, which is 100% load for 15 minutes or more. Hehe...maybe it's just tired. I'm not too concerned about it. Just have to be careful about what I report on the list here :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] FrameRate !!
Norman Vine writes: all figures are for at rest no HUD or Panel Default location at Noon Brakes on MingW32 compiled on Win2k Geforce2 GTS No model shown ie. View[0] March 16 ~78 fps last week ~71 fps today ~66 fps this is a negative change of 15% :-((( You've been at this long enough that I don't have to ask about same date, time of day, view direction, etc. Is anyone else seeing a similar change? We're doing a lot of refactoring of the view code (Norm's skipping the model code), so some optimizations might have been lost temporarily. You can rule out FDM problems by testing with several FDMs, including the magic carpet. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
David Megginson writes: Norman Vine writes: all figures are for at rest no HUD or Panel Default location at Noon Brakes on MingW32 compiled on Win2k Geforce2 GTS No model shown ie. View[0] March 16 ~78 fps last week ~71 fps today ~66 fps this is a negative change of 15% :-((( You've been at this long enough that I don't have to ask about same date, time of day, view direction, etc. Is anyone else seeing a similar change? We're doing a lot of refactoring of the view code (Norm's skipping the model code), so some optimizations might have been lost temporarily. You can rule out FDM problems by testing with several FDMs, including the magic carpet. This profiling run might be enlightening time seconds secondscalls us/call us/call name 35.17 1.21 1.216391518.9329.20 fgRenderFrame(void) 14.53 1.71 0.5063915 7.8249.75 fgMainLoop(void) 11.63 2.11 0.4063899 6.2611.11 fgUpdateTimeDepCalcs(void) 5.81 2.31 0.20 3455357 0.06 0.06 FGGlobals::get_current_view(void) const 4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char const *, bool) 3.49 2.57 0.12 2352563 0.05 0.05 fgGetDouble(char const *, double) 3.49 2.69 0.12 128618 0.93 0.93 getVisibility(void) 3.49 2.81 0.1264303 1.87 2.26 fgReshape(int, int) 3.20 2.92 0.11 1617164 0.07 0.07 fgGetNode(char const *, int, bool) 2.33 3.00 0.08 1222609 0.07 0.07 fgGetInt(char const *, int) 2.33 3.08 0.0864302 1.24 1.26 fgUpdateDCS(void) 2.03 3.15 0.0764302 1.09 1.09 FGLogger::update(int) 2.03 3.22 0.0763915 1.10 1.10 fgIOProcess(void) 1.45 3.27 0.0564303 0.78 0.78 getTextures(void) 1.16 3.31 0.04 2109792 0.02 0.02 fgGetString(char const *, char const *) 1.16 3.35 0.0464303 0.62 0.62 fgUpdateProps(void) Anyone know how to count 'cache invalidations' ? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Norman Vine writes: This profiling run might be enlightening 4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char const *, bool) 3.49 2.57 0.12 2352563 0.05 0.05 fgGetDouble(char const *, double) OK, this jogs my memory. I took out the old path-caching code before, and didn't add a new hashtable yet. I'll try to do that early next week. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
On Sat, Apr 06, 2002 at 12:25:29PM -0500, Norman Vine wrote: Anyone know how to count 'cache invalidations' ? Under Linux, you can get this kind of thing from oprofile (http://oprofile.sf.net), if you have a motherboard with an IO-APIC interrupt controller. It's a very powerful profiling tool . . . I have no idea about windows. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg05082/pgp0.pgp Description: PGP signature
RE: [Flightgear-devel] FrameRate !!
David Megginson wwrites: Norman Vine writes: This profiling run might be enlightening OK, this jogs my memory. I took out the old path-caching code before, and didn't add a new hashtable yet. I'll try to do that early next week. Cool This might be a problem too time seconds secondscalls us/call us/call 5.81 2.31 0.20 3455357 0.06 0.06 FGGlobals::get_current_view(void) const Judging by the number of times this is called i.e 54 times per LOOP iteration this 'might' be a 'good' candidate for inlining fgMainLoop calls == 63915 Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Norman Vine writes: This might be a problem too time seconds secondscalls us/call us/call 5.81 2.31 0.20 3455357 0.06 0.06 FGGlobals::get_current_view(void) const Judging by the number of times this is called i.e 54 times per LOOP iteration this 'might' be a 'good' candidate for inlining It's a bad one for inlining, actually, because that forces globals.hxx to have a dependency on viewmgr.hxx, so all of FlightGear has to rebuild whenever Jim touches the viewer code. What we should do is find out why get_current_view is called so much -- almost no other part of FlightGear should care about it. Jim's already started uncoupling things, and we can look to see if it's used in a loop somewhere (where it could be assigned to a variable just once). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
David Megginson writes:
Norman Vine writes:
Judging by the number of times this is called
i.e 54 times per LOOP iteration
this 'might' be a 'good' candidate for inlining
It's a bad one for inlining, actually, because that forces globals.hxx
to have a dependency on viewmgr.hxx, so all of FlightGear has to
rebuild whenever Jim touches the viewer code.
So ???
--- globals.hxx
#ifdef SLOW_DEVELOPER_CONVENIENCE_CODE
FGViewer *get_current_view() const;
#else
FGViewer *get_current_view() const { return
viewmgr-get_current_view(); }
#endif
-- globals.cxx
#iifdef SLOW_DEVELOPER_CONVENIENCE_CODE
FGViewer *
FGGlobals::get_current_view () const
{
return viewmgr-get_current_view();
}
#endif
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Norman Vine writes: So ??? So it hurts development a lot. Developers have limited time to contribute to FlightGear, and if the program takes always takes 5 or 10 minutes to rebuild (and has to be rebuilt, say, 10 times to test and debug each change), we all suffer because a lot less code gets written and debugged. There's an easy solution here -- remove FGGlobals::get_current_view completely and have the callers use FGGlobals::get_view_mgr to get the current view. The right solution, though, is to find out *why* so many parts of the code are using this method. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
David Megginson [EMAIL PROTECTED] said: It's a bad one for inlining, actually, because that forces globals.hxx to have a dependency on viewmgr.hxx, so all of FlightGear has to rebuild whenever Jim touches the viewer code. What we should do is find out why get_current_view is called so much -- almost no other part of FlightGear should care about it. Jim's already started uncoupling things, and we can look to see if it's used in a loop somewhere (where it could be assigned to a variable just once). I think we'll weed some of these things out when we start implementing that FGLocus class (or whaterver it is called). It's hard to fix some of this stuff until the uncoupling is completed. When I get done viewer is only going to know about the view and nothing else. 54 times per frame is almost unbelievable considering the number of references to viewer data, so as David suggested a good start would probably be moving it to a variable. BTW IIRC that returns a pointer to the class...I think I remember seeing the code that was doing that over and over...maybe tilemgr? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
David Megginson writes: Norman Vine writes: So ??? So it hurts development a lot. Developers have limited time to contribute to FlightGear, and if the program takes always takes 5 or 10 minutes to rebuild (and has to be rebuilt, say, 10 times to test and debug each change), we all suffer because a lot less code gets written and debugged. SO developers can certainly use the preprocessor to help them around these kind of things rather then burning frame rate !! Use the Tool Luke :-)) There's an easy solution here -- remove FGGlobals::get_current_view completely and have the callers use FGGlobals::get_view_mgr to get the current view. OK same thing as my #ifdef The right solution, though, is to find out *why* so many parts of the code are using this method. Indeed :-) The main caller 75% is in the tile paging system fgRenderFrame makes 7 calls per loop or 13% for 13% of total I'm working on a patch of the affected files mostly in the low-level scenery stuff that I'll send to Curt 0.030.00 450114/3455357 fgRenderFrame(void) [3] 0.150.00 2527490/3455357 FGTileEntry::prep_ssg_node(Point3D const , float) [10] [5] 5.80.200.00 3455357 FGGlobals::get_current_view(void) const [5] Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
David Megginson [EMAIL PROTECTED] said: Norman Vine writes: So ??? So it hurts development a lot. Developers have limited time to contribute to FlightGear, and if the program takes always takes 5 or 10 minutes to rebuild (and has to be rebuilt, say, 10 times to test and debug each change), we all suffer because a lot less code gets written and debugged. There's an easy solution here -- remove FGGlobals::get_current_view completely and have the callers use FGGlobals::get_view_mgr to get the current view. The right solution, though, is to find out *why* so many parts of the code are using this method. That won't help, these calls are for the class pointer. I'd really like it if you guys just ignored this one until about a week from now. :-) It takes 20 minutes or close to it for me to do a rebuild sometimes, but it is only when changing headers, which usually doesn't happen all that much. Generally when I have to add something to a popular class, I try and organize what I'm doing around the inevitable rebuild. And then I remind myself of the days when this little communication program I wrote in 6502 assembler took 11 hours to build :-). In those days you worked harder to avoid bugs. And that was a good thing. So anyway, I think it is fine the way it is. There are far too many classes accessing the viewer for info that should be held elsewhere, and soon it'll be much better. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Jim Wilson writes: David Megginson [EMAIL PROTECTED] said: There's an easy solution here -- remove FGGlobals::get_current_view completely and have the callers use FGGlobals::get_view_mgr to get the current view. The right solution, though, is to find out *why* so many parts of the code are using this method. That won't help, these calls are for the class pointer. I'd really like it if you guys just ignored this one until about a week from now. :-) Jim FYI The vast majority of these calls for info from the CurrentView are to determine the up vector. I have a patch for the tile system already Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Norman Vine [EMAIL PROTECTED] said: It seems as if we are losing FrameRate rather quickly all figures are for at rest no HUD or Panel Default location at Noon Brakes on MingW32 compiled on Win2k Geforce2 GTS No model shown ie. View[0] March 16 ~78 fps last week ~71 fps today ~66 fps this is a negative change of 15% :-((( and there is no difference in what is being sent to the graphics card !!! Actually that's not exactly true. We're sending more since putting the model in a seperate scenegraph...although perhaps not more but better... Currently there's more math being done with the model and the viewer broken up and we know that there is lots of room for optimization. This is a likely source of trouble, depending on the system. As soon as someone decides on a name for that FGLoco class that'll be fixed. The view manager is also fatter than it should be at the moment, and should get better next week. Not sure how much effect it would have on what you are seeing though. On my system here frame rate it hasn't changed noticably at all over the last few weeks, but then again it never was much to begin with--voodoo3pci :-) Compared to a couple days ago though there is maybe about a 5% hit with the most recent changes. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FrameRate !!
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: It seems as if we are losing FrameRate rather quickly all figures are for at rest no HUD or Panel Default location at Noon Brakes on MingW32 compiled on Win2k Geforce2 GTS No model shown ie. View[0] March 16 ~78 fps last week ~71 fps today ~66 fps this is a negative change of 15% :-((( and there is no difference in what is being sent to the graphics card !!! Actually that's not exactly true. We're sending more since putting the model in a seperate scenegraph...although perhaps not more but better... Nope that's not relevant in that I am not displaying the model this is View[0] ie RPH scenery only so we should be sending exactly the same as before ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] framerate 1/s
Melchior FRANZ [EMAIL PROTECTED] said: The changes from yesterday turned my framerate at KSFO from about 10 to 1 per second. Ten is already painful enough, and that with clouds and panel turned off. But one is a bit weak and makes fgfs virtually unflyable. (I've only got a 266MHz processor and a V3 graphics card.) m. Are you using Linux? I'm using a V3 but its on a 100mhz motherboard (750 mhz processor) and I'm seeing an increase at KSFO. It slowed down to 10 to 15 fps a little while back and is now over 30. Other airports with less stuff around I'm much higher than that. Check for something taking resources in the background. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] framerate 1/s
Melchior FRANZ writes: The changes from yesterday turned my framerate at KSFO from about 10 to 1 per second. Ten is already painful enough, and that with clouds and panel turned off. But one is a bit weak and makes fgfs virtually unflyable. (I've only got a 266MHz processor and a V3 graphics card.) Which changes? I don't think we did anything major yesterday. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
