Re: [Flightgear-devel] Multi core discussion
Aloha List, as owner of an Intel Q6600 I followed this discussion with much interest and checked thhe below mentioned option right away on Vista x64 with GIT binaries and data of June, 26. No matter which option I use or how I modify the start settings, FG crashes back to desktop right after loading cloud layers. See the following output of my last lines in log level debug: [...] Splash screen progress generating sky elements Adding subsystem ephmeris Loading stars from D:/dev/FlightGear/data/Astro/stars Loaded 3141 stars initializing cloud layers Cheers, Mike [...] Have you tried telling OSG to use more threads? Edit the following in your preferences.xml file: rendering !-- Threading modes: AutomaticSelection DrawThreadPerContext CullDrawThreadPerContext CullThreadPerCameraDrawThreadPerContext -- !-- multithreading-modeAutomaticSelection/multithreading-mode -- ... /rendering Note that enabling concurrency here currently breaks the built in screenshot mechanism. IMHO we need to proceed carefully with parallelization - to my knowledge there are only a few subsystems that use (or could with in reason be expected to use) enough CPU time to warrant the effort to move them into separate threads. [...] Cheers, Anders --- If you want to be understood, you first have to listen --- -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
For me it worked, but I am on Ubuntu 10.04 64bit. Perhaps this has only been tested on Linux systems before...? m Op 06-07-10 23:49, Mike schreef: as owner of an Intel Q6600 I followed this discussion with much interest and checked thhe below mentioned option right away on Vista x64 with GIT binaries and data of June, 26. No matter which option I use or how I modify the start settings, FG crashes back to desktop right after loading cloud layers. See the following output of my last lines in log level debug: [...] Splash screen progress generating sky elements Adding subsystem ephmeris Loading stars from D:/dev/FlightGear/data/Astro/stars Loaded 3141 stars initializing cloud layers -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
Hi I do not know if this has been discussed in this group before... (I am guessing it is...) Many modern computers are running multicore CPU's. I have noticed that FGFS only uses one thread in one core. And FGFS appears to be processor bound on my Core-I7, because the one core thread is 100% busy while my FPS are dropping in areas with a lot of scenery details (like Paris, for instance) and lots of rendering goodies switched on. I do understand that in the main loop of FGFS many subsystems are related. But would it be possible to identify subsystems that can be grouped to run on other cores, when available? I am thinking about weather and clouds, drawing the dials on the dashboard and things like that. It would be neat if more of the computing power that is available could be used. m http://wiki.flightgear.org/index.php/FlightGear_Newsletter_June_2010 --Linuxtag! -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On 6 Jul 2010, at 12:45, fiers...@zonnet.nl wrote: It would be neat if more of the computing power that is available could be used. Yes, it would :) I do understand that in the main loop of FGFS many subsystems are related. But would it be possible to identify subsystems that can be grouped to run on other cores, when available? Some of that work, I've been doing recently - it's sometimes complex to untangle the related subsystems, and unfortunately there's many pieces that can only run on the main thread (especially, anything that interacts with the rendering/OSG code). I've grouped some systems that should be able to run in a separate thread, but no one is really sure yet if the overhead of moving data between threads, will make this approach worthwhile. The steps to find out are known, just require a spare week or two of hacking - unfortunately life is busy! Summary - yes, it should be possible, yes it has been discussed, the issue is about finding the time to try it, and see what breaks, and what the potential gains are. James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, Jul 6, 2010 at 1:45 PM, fiers...@zonnet.nl wrote: Hi Many modern computers are running multicore CPU's. I have noticed that FGFS only uses one thread in one core. And FGFS appears to be processor bound on my Core-I7, because the one core thread is 100% busy while my FPS are dropping in areas with a lot of scenery details (like Paris, for instance) and lots of rendering goodies switched on. I find it hard to believe that you have performance problems with a core i7, assuming you got a halfway decent graphics card to go with it. FG itself isn't CPU limited, we barely use any processing power :) As such, parallelizing FG subsystems, while a good thing in theory and certainly for the future, wouldn't help much in your case. What you are seeing must be graphics related - you even say so yourself. Have you tried the menu option for the on-screen OSG stats to see what is taking long? Also note that if you don't run with an FPS limit (either in FG or the sync to vblank option in your graphics driver) we will use all available power to push out frames as fast as possible. -- Csaba/Jester -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
Op 06-07-10 14:01, James Turner schreef: Summary - yes, it should be possible, yes it has been discussed, the issue is about finding the time to try it, and see what breaks, and what the potential gains are. Great! I will not bother you ;-) m -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
Op 06-07-10 14:12, Csaba Halász schreef: I find it hard to believe that you have performance problems with a core i7, assuming you got a halfway decent graphics card to go with it. I am not having performance problems. All is well, but I noticed that only one core thread is used while my Linux reports 8 available (4 cores times 2 threads). FG itself isn't CPU limited, we barely use any processing power :) As such, parallelizing FG subsystems, while a good thing in theory and certainly for the future, wouldn't help much in your case. What you are seeing must be graphics related - you even say so yourself. Have you tried the menu option for the on-screen OSG stats to see what is taking long? I have not. I am looking at the Debug menu option... where are the OSG stats? I can dump the Scene Graph (442MB, by the way), and I can look at the frame rate... I have searched the wiki, but cannot find an option for on-screen OSG stats. Which on screen OSG stats option do you mean? Also note that if you don't run with an FPS limit (either in FG or the sync to vblank option in your graphics driver) we will use all available power to push out frames as fast as possible. Yep. I know. When I start, I get 160 fps or something like that with 100% cpu. When I switch on rendering options it remains more or less the same. Depending on the weather, I guess. Now I reposition to LFPO, which has a lot of detailed scenery, and my frame rate drops to 25-33. Still, no problems to fly happily. I agree it remains to be seen if anything improves by a multithreaded approach. I probably should not have started this topic, esspecially since it has been a subject of debate at Linux TAG. Sorry. m -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, 6 Jul 2010, fiers...@zonnet.nl wrote: Op 06-07-10 14:12, Csaba Halász schreef: I find it hard to believe that you have performance problems with a core i7, assuming you got a halfway decent graphics card to go with it. I am not having performance problems. All is well, but I noticed that only one core thread is used while my Linux reports 8 available (4 cores times 2 threads). Hi, Have you tried telling OSG to use more threads? Edit the following in your preferences.xml file: rendering !-- Threading modes: AutomaticSelection DrawThreadPerContext CullDrawThreadPerContext CullThreadPerCameraDrawThreadPerContext -- !-- multithreading-modeAutomaticSelection/multithreading-mode -- ... /rendering Note that enabling concurrency here currently breaks the built in screenshot mechanism. IMHO we need to proceed carefully with parallelization - to my knowledge there are only a few subsystems that use (or could with in reason be expected to use) enough CPU time to warrant the effort to move them into separate threads. AFAIK the really big CPU time consumer is rendering. Various AI systems could be as well if they are used for a large number of AI entities (though computation of AI behaviour is probably still much cheaper than handling the 3d models for them). Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/-- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, Jul 6, 2010 at 2:58 PM, fiers...@zonnet.nl wrote: I have searched the wiki, but cannot find an option for on-screen OSG stats. Which on screen OSG stats option do you mean? debug - cycle on screen stats or somesuch, can't say right now. Looks like this: http://www.turboimagehost.com/p/1582270/fgfs-screen-285.jpg.html Also, OSG does support multithreading, but mostly useful if you have more than one screen and GPU. I probably should not have started this topic, esspecially since it has been a subject of debate at Linux TAG. Sorry. Nothing to be sorry for, this list is intended for such discussions :) -- Csaba/Jester -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
Hi Anders, Thanks. Very interesting. I added multithreading-modeAutomaticSelection/multithreading-mode to my preferences.xml file under rendering. At LFPO I am getting 50 FPS (25-30 before). There are two core threads each 50-60% busy. The rest is up to the graphics card probably. m Op 06-07-10 15:26, Anders Gidenstam schreef: On Tue, 6 Jul 2010, fiers...@zonnet.nl wrote: Op 06-07-10 14:12, Csaba Halász schreef: I find it hard to believe that you have performance problems with a core i7, assuming you got a halfway decent graphics card to go with it. I am not having performance problems. All is well, but I noticed that only one core thread is used while my Linux reports 8 available (4 cores times 2 threads). Hi, Have you tried telling OSG to use more threads? Edit the following in your preferences.xml file: rendering !-- Threading modes: AutomaticSelection DrawThreadPerContext CullDrawThreadPerContext CullThreadPerCameraDrawThreadPerContext -- !-- multithreading-modeAutomaticSelection/multithreading-mode -- ... /rendering Note that enabling concurrency here currently breaks the built in screenshot mechanism. IMHO we need to proceed carefully with parallelization - to my knowledge there are only a few subsystems that use (or could with in reason be expected to use) enough CPU time to warrant the effort to move them into separate threads. AFAIK the really big CPU time consumer is rendering. Various AI systems could be as well if they are used for a large number of AI entities (though computation of AI behaviour is probably still much cheaper than handling the 3d models for them). Cheers, Anders -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
Op 06-07-10 15:44, Csaba Halász schreef: debug - cycle on screen stats or somesuch, can't say right now. Did that, but it only shows framerate and not the other stuff that is in your picture. I probably need to set an option in preferences or something like that. m -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, Jul 6, 2010 at 3:58 PM, fiers...@zonnet.nl wrote: Op 06-07-10 15:44, Csaba Halász schreef: debug - cycle on screen stats or somesuch, can't say right now. Did that, but it only shows framerate and not the other stuff that is in your picture. I probably need to set an option in preferences or something like that. You just need to click it more times, it cycles through different detail levels. -- Csaba/Jester -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
Hi Csaba, Csaba Halász wrote: FG itself isn't CPU limited, we barely use any processing power :) During preparations for some public show last year (maybe LinuxTag) I replaced the two Opteron 2 GHz CPU's by their respective 2.8 GHz counterparts and the result was an almost proportional (to the CPU frequency) framerate improvement in various test cases - no matter wether I was running NVidia's 7950GT or 8800GTX cards. Even though a 2.8 GHz Socket 940 Opteron is by far not state of the art in these days, I think this scenario is a sufficient proof that the statement FG itself isn't CPU limited doesn't hold. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tuesday 06 July 2010 16:15:36 Martin Spott wrote: Even though a 2.8 GHz Socket 940 Opteron is by far not state of the art in these days, I think this scenario is a sufficient proof that the statement FG itself isn't CPU limited doesn't hold. As are the 100%. If the application is bound by the graphics card's performance, the CPU cannot reach 100% utilization, since it would wait for the graphics card to finish drawing. 100% CPU load show, that the graphics card can execute drawing instructions faster than the CPU can generate them. Thus the application is CPU limited. Stefan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
A right. Hence the Cycle. I feel stupid now :-[ m Op 06-07-10 16:06, Csaba Halász schreef: On Tue, Jul 6, 2010 at 3:58 PM,fiers...@zonnet.nl wrote: Op 06-07-10 15:44, Csaba Halász schreef: debug -cycle on screen stats or somesuch, can't say right now. Did that, but it only shows framerate and not the other stuff that is in your picture. I probably need to set an option in preferences or something like that. You just need to click it more times, it cycles through different detail levels. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, Jul 6, 2010 at 4:50 PM, Stefan Seifert n...@detonation.org wrote: On Tuesday 06 July 2010 16:15:36 Martin Spott wrote: Even though a 2.8 GHz Socket 940 Opteron is by far not state of the art in these days, I think this scenario is a sufficient proof that the statement FG itself isn't CPU limited doesn't hold. As are the 100%. If the application is bound by the graphics card's performance, the CPU cannot reach 100% utilization, since it would wait for the graphics card to finish drawing. 100% CPU load show, that the graphics card can execute drawing instructions faster than the CPU can generate them. Thus the application is CPU limited. You are assuming that - the graphics driver uses something other than busy waiting. - the graphics driver doesn't need CPU power. - OSG doesn't need CPU power. Frame rates don't mean much, when talking about FG itself (that is, not the graphics/rendering). I was arguing that parallelizing whatever processing FG proper is doing (ie. FDM, nasal, etc) is not gonna give a significant FPS boost in the general case. Of course, for future scalability it is a good idea. Could also be a good idea for certain cpu intensive nasal tasks, such as wildfire. -- Csaba/Jester -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, Jul 6, 2010 at 5:12 AM, Csaba Halász csaba.hal...@gmail.com wrote: On Tue, Jul 6, 2010 at 1:45 PM, fiers...@zonnet.nl wrote: Many modern computers are running multicore CPU's. I have noticed that FGFS only uses one thread in one core. And FGFS appears to be processor bound on my Core-I7, because the one core thread is 100% busy while my FPS are dropping in areas with a lot of scenery details (like Paris, for instance) and lots of rendering goodies switched on. I find it hard to believe that you have performance problems with a core i7, assuming you got a halfway decent graphics card to go with it. Most of the _non-minimal rendering options use considerable CPU power on any GPU that is routinely available in a mobile form factor. If we want to be able to support non-desktop users (as well as simplify demonstrations at trade shows), we need to make sure that the main thread (and in fact that whole core) are entirely dedicated to rendering. FG itself isn't CPU limited, we barely use any processing power :) As such, parallelizing FG subsystems, while a good thing in theory and certainly for the future, wouldn't help much in your case. The reason why FG itself doesn't use any CPU power is that, whenever any of the subsystem developers tries to implement an underlying simulation improvement that requires non-trivial amounts of CPU, there is massive complaint from the eye candy side of the community. This appears as a tradeoff precisely because FG doesn't support multithreading. If we had threading working safely, any simulation subsystem could choose to run in its own thread and eat an entire core as needed. The single threaded limitation currently impacts the implementation of real time weather, microcell airmass, AI operations, non-steam instruments, as well as radio navigation realism. That I'm aware of ... there are presumably others too. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi core discussion
On Tue, 6 Jul 2010, Alex Perry wrote: Most of the _non-minimal rendering options use considerable CPU power on any GPU that is routinely available in a mobile form factor. If we want to be able to support non-desktop users (as well as simplify demonstrations at trade shows), we need to make sure that the main thread (and in fact that whole core) are entirely dedicated to rendering. Or hope that the OSG and driver developers find good ways to parallelize the CPU part of the rendering process. The reason why FG itself doesn't use any CPU power is that, whenever any of the subsystem developers tries to implement an underlying simulation improvement that requires non-trivial amounts of CPU, there is massive complaint from the eye candy side of the community. This appears as a tradeoff precisely because FG doesn't support multithreading. If we had threading working safely, any simulation subsystem could choose to run in its own thread and eat an entire core as needed. The single threaded limitation currently impacts the implementation of real time weather, microcell airmass, AI operations, non-steam instruments, as well as radio navigation realism. That I'm aware of ... there are presumably others too. My suggestion would be to rather look into parallelization inside the subsystems that need a lot of computation (think worker threads) - not least since things like microcell airmass simulation may well need more than one thread/core/CPU - and the problem itself could be of a type that is easy to parallelize. This would keep the top level main loop integration simple too. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
