Board index FlightGear Development

Can FG computations be made more balanced?

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Can FG computations be made more balanced?

Postby chris_blues » Thu Apr 18, 2013 6:06 pm

Hi!
Not sure, if I'm right here in this forum (at least I hope Gijs doesn't have to worry about me tripping in the wrong one again ...) :roll:
I have been wondering several times and now I get around to it,to write it down!

Why do I have frame-rates of 8 - 60 sometimes, depending (mostly) on local weather and all settings to maxx. And here comes the part I mean to talk about: Why does my GPU jumps to 70°C in a minute or so, while my 2CPUs run gently with 50% usage each. (threading : auto)

I understand, much of the computations are purely for optical reasons, and that's what a GPU is there for. But why not take some of it, and put it to idle CPU's? I'm running on a dual-core machine, knowing of this, I'd expect on the same hardware, but with a 8core CPU the same results; just because I have 8 CPU's running on 12% instead of 2 running on 50% doesn't seem to take any load off the GPU. Theoretically - and as I understand things.

<sarcasm>I feel a bit like sitting in a Ferrari, but cant switch the gears to 4-6, because the notches aren't there. Which keeps me stuck at 150 kph, while ~300kph are possible...</sarcasm>
Seriously, not knowing what I'm talking about, I feel there's a lot of computing power unused... While its nice to have some little headroom on at least one CPU left, I'd rather see them all maxxed out! :twisted:

Is this a no-go, because of some architectural problems, or is it doable, but never has been put on any wishlist? If the latter, tell me where the wishlist is!!! :mrgreen:

Thanks for any information and feedback in advance!

Cheers
chris
Last edited by chris_blues on Fri Apr 19, 2013 7:44 am, edited 1 time in total.
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Can FG computations be made more balanced?

Postby Hooray » Fri Apr 19, 2013 4:51 am

Related/identical topic: viewtopic.php?f=18&t=15755&p=153298&hilit=#p153262

The current architecture is designed such that most things run in the main loop, which also determines frame rate in the end. Thus, frame rates become non-deterministic - not just because of Nasal scripting, but also because of C++ subsystems doing stuff that would be better done outside the main loop.

Despite contrary opinions, this was also noticed by some core developers - by comparing OSG/FG performance vs. performance of other OSG-based applications, which provide more reliable/deterministic frame rates, and overall better performance:
http://www.mail-archive.com/flightgear- ... 39030.html
Mathias Fröhlich wrote:I have really seen incredibly fast osg applications with stable framerates and nifty looking
models. But the way we use osg and put together models leaves osg and below
that the driver only little chance to be fast. Which leaves only little
headroom for sensible further development.

Getting back to components: Latencies are a critical part of running in
multiple threads/applications. This is not a particular problem of hla, this
is a generic problem when running real time applications in parallel. I know a
lot of really smart people who can even understand complex environments very
well, but have no clue about the problems introduced by round trips. Seen
this, this is the reason why I started that hla stuff, since this provides a
framework which supports and even encourages a programming model that is able
to hide latencies as good as possible. Anyway, there is a chance that you even
use this api in a way that really hurts in this corner. And this is actually
the really bad thing I want to avoid: If you are the first component that does
not get that right you might just notice little to nothing - especially if you
are running on extrem fast hardware.


Which is why some people (99.999% Mathias himself) have been working on decoupling the rendering/viewer side from the simulation side, through efforts like FGViewer and HLA:
http://wiki.flightgear.org/FGViewer
There is now a small tool in flightgear that can be used just like osgviewer. The huge difference is that it also works for btg and with some knowledge about the internals of the model loading process also for stg files. The tool is aimed at people working on scenery and willing to see how their scenery modifications will look like. The can do so now without starting flightgear. One of the main ideas behind the tool had been to create a lightweight viewer component without pulling in tons of inter-dependencies which are so omnipresent in FlightGear.
So the idea behind the 'fgviewer' tool is creating a distinct viewer component (yet still in the early stage of development) which, while still remaining compilant with the FlightGear environment, is trying to adopt as little dependencies from FlightGear as possible and therefore does not necessarily has to follow every rule of "how things are done in fgfs" in order to achieve its fine goal. It's a good idea to factor out the dependencies that the visual part of flightgear has on the whole flightgear implementation, a large fraction of the time that was spent for the OSG port was required simply to detangle a pile of quite obscure interdependencies between the former viewer code and the so-called FlightGear core.
Actually I'm convinced that carefully cutting some of the old ties (some call them "cruft"), for example by keeping the viewer part as independent from the FlightGear core as possible, might serve as a good platform for future development. It's obvious that FlightGear, as every visual simulation, has to depend on the viewer. But the opposite way of depending the viewer part heavily on core FlightGear components is certainly not going into the outlined direction.
This is a basic version of that tool that might grow it there is a need. I hope to include more flightgear internal scenery loading stuff so that you can at some time also load aircraft models an see if the static parts animations/transforms/postprocessing steps are as expected without the need to start the whole simulation.


http://wiki.flightgear.org/FlightGear_H ... chitecture)
Although the FlightGear design fairly modular it's provided as a single binary. Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive.
Basically, better HLA support will make it possible for FlightGear to be split into "components" (each running in a dedicated process or in separate thread within the main FlightGear process), making better use of multi-core architectures (SMP), while decouple the flight simulation from the "viewer" part (i.e. visualization), so that steady/reliable frame rates can be achieved (see FGViewer).


You will see that what you are raising now is a long-standing issue and pretty well-known, discussed for over a decade already, by some of the most seasoned developers and key contributors: http://wiki.flightgear.org/Modularizing ... ear#Issues

Basically, FGViewer is all about coming up with a self-contained viewer component, that talks to the rest of FG through HLA, without running any simulation stuff itself, to ensure that frame rates are HIGH, and without LAG.

HLA will make it possible to move more and more main loop stuff into separate components, that do not need to run inside the FG main loop, but can be run in other threads/processes - which means, that your idle cores can be better used, without having an impact on your frame rate.

Basically, FlightGear will stop being a single "process", but instead FG will look to your computer like a "team" of programs that work together - your OS will then assign different cores (CPUs) to each team member and let them communicate through HLA. That's how professional simulators tend to work, too.

Some core developers are hoping to get this started as early as summer 2013:
http://www.mail-archive.com/flightgear- ... 39693.html
Zakalawe wrote:There's a larger issue here, that 'soon' (likely during the summer) I want to
start restructuring the codebase into multiple processes, so we can support
different rendering architectures (and use multiple CPUs) better. That's
Mathias Fröhlich's HLA/RTI work, and indeed he has done the recent work on
extending fgviewer to test changes to the current terrain system.


In addition, HLA will also be a viable option to modernize our MP system, but also to factor out the AI traffic system, such that the AI/MP experience becomes consistent across multiple instances/clients, and even in distributed setups that use many computers/screens for a single simulator (think LinuxTag/FSWeekend):
http://wiki.flightgear.org/Decoupling_t ... fic_System
http://wiki.flightgear.org/Distributed_ ... Simulation
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Can FG computations be made more balanced?

Postby Thorsten » Fri Apr 19, 2013 6:03 am

I understand, much of the computations are purely for optical reasons, and that's what a GPU is there for. But why not take some of it, and put it to idle CPU's? I'm running on a dual-core machine, knowing of this, I'd expect on the same hardware, but with a 8core CPU the same results; just because I have 8 CPU's running on 12% instead of 2 running on 50% doesn't seem to take any load off the GPU.


If you have a halfway decent GPU, when you ask a rendering task (texture lookups, vector transformations, matrix multiplications,...) , the additional performance of 8 CPUs is pretty negligible. The GPU does these tasks in lightning speed.

Just to give you a sense of scale, some colleagues of mine run relativistic fluid-dynamics computations (which needs vector transformations, matrix multiplications,...) and have started to move these computations from CPUs to GPU clusters - which according to their benchmarks makes it 100 times faster. GPUs are massive parallel machines with hard-wired support for what is needed for rendering. The most powerful supercomputing machines in the world use arrays of graphics cards.

So it's unlikely that utilizing your idle CPUs for rendering would make more than a dent - especially if you imagine the data flow back and forth you create. Just try running FG with software rendering only and see how your 8 cores keep up with the performance of the GPU :-) Or, if the above benchmark is true, you could run at 108% max. instead of 100% - not really that impressive, is it?

Why do I have frame-rates of 8 - 60 sometimes, depending (mostly) on local weather and all settings to maxx.


Because on a high-end GPU (which I assume you have), the single determining factor for the framerate seems to be the vertex count of clouds, buildings and trees (in this order). So rendering overcast sky makes a huge difference to rendering clear sky, rendering a city worth of random buildings makes a huge difference to rendering a desert, and rendering dense forests makes a difference to rendering a few patches of green. With all details to max, we probably burn 99% of the total computational load in rendering (it's about 1200 lines of instructions per pixel 30-60 times per second), all other flight related tasks like computing aerodynamics are small in comparison.

I don't see how HLA or any other scheme is going to improve that, it would seem one needs a LOD scheme to reduce the vertex count or a larger vertex pipeline - but then, that's just my opinion and Mathias thinks I have no clue anyway, so there's that.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Can FG computations be made more balanced?

Postby Hooray » Fri Apr 19, 2013 6:20 am

Thorsten wrote in Fri Apr 19, 2013 6:03 am:I don't see how HLA or any other scheme is going to improve that, it would seem one needs a LOD scheme to reduce the vertex count or a larger vertex pipeline - but then, that's just my opinion and Mathias thinks I have no clue anyway, so there's that.


I think we have to keep in mind that we all have different backgrounds here, and it's pretty safe to say that before anybody here starts working on something (spending hundreds and even thousands of hours on it), that we make sure that we understand the problem - no matter if it's FDM, weather or efforts like HLA obviously, our understanding of the problem domain evolves during that process.

You once said "looking at my own postings, I can't help but noticing, that I now have a different opinion - it's a process called learning". So, I'd suggest that different people have to learn different things, and opinions changing is not a bad thing. If you remember, we once had a pretty heated discussion about benchmarking approaches, and determining the limiting factor (CPU/GPU-wise) where the two of us didn't quite agree, up to an "ad hominem" degree, right? :lol:

The point of the whole FGViewer/HLA effort is having a pure renderer and moving everything not rendering related to separate entities, that may run in separate threads or processes, without affecting the visualization of the simulation. That is a key technique used in professional full motion simulators, and in the simulation industry in general. Even without fully understanding the benefits, you will certainly come to appreciate the fact that you will be able to run many computations that don't directly affect frame rate or frame spacing/latency anymore.

At the moment, we simply have unused optimization potential because of the way FG uses OSG/OpenGL, i.e. not following the proper coding patterns.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Can FG computations be made more balanced?

Postby Thorsten » Fri Apr 19, 2013 6:40 am

The point of the whole FGViewer/HLA effort is having a pure renderer and moving everything not rendering related to separate entities, that may run in separate threads or processes, without affecting the visualization of the simulation.


But you see, the only thing that I can identify as affecting my framerate is the vertex pipeline. Currently, with the rest I can pretty much do what I like. The Concorde with it's gazillions of systems runs as fast as a glider. The high-fideltity (or at least quite complex FDM) T4T Spitfire runs as fast as any other plane. Switching background Nasal on and off makes no bloody difference for anything. Only what enters the vertex pipeline does. Or lots and lots of semi-transparent stacks in the fragment pipeline - they can eventually kill as well.

So you can move the rest wherever you want - since it's not determining my framerate in its 'bad' structure now, it will not determine my framerate in an optimized structure either. That may not be the situation on the machine Mathias is on, and Mathias may not be interested in the same rendering setup as I am - but that's how it works on my machine right now, and presumably that's how it works for Chris.

I'm sorry, but I go for evidence here.

Just to avoid misunderstandings: I think HLA is a great idea for many reasons, because it addresses many unnecessary sources of bottlenecks. But I don't think it addresses all bottlenecks, in particular I don't think it addresses mine. Mathias has made it abundantly clear that he's not interested in high-end shader effects, but that he cares for multiple display setups and similar things. It's also become quite apparent to me that he doesn't really follow how our high-end effects actually are implemented and what they do. So my impression is that HLA will be a good thing for many purposes - when you're CPU limited for any reason, for MP, for multi-display setups,..., but I don't see how it will address situations where the bottleneck is shader code.
Last edited by Thorsten on Fri Apr 19, 2013 6:59 am, edited 1 time in total.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Can FG computations be made more balanced?

Postby chris_blues » Fri Apr 19, 2013 6:56 am

:shock:
Very enlightening! Big Thanks!!!

Well, I sure wasn't aware, that a GPU is THAT much faster than a CPU, when it comes to the rendering / parrallel computing. Unfortunately, I don't have 8 CPU's sitting around here, so I can't tell about any differences... :)

Thanks anyway!
Cheers
chris
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Can FG computations be made more balanced?

Postby chris_blues » Fri Apr 19, 2013 7:00 am

Thorsten wrote in Fri Apr 19, 2013 6:40 am:... and presumably that's how it works for Chris.

dead right! Blue sky, not much scenery fps=60 constantly - overcast local weather, KSFO dowtown with many many random buildings + multiplayer fps= 8 constantly...
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Can FG computations be made more balanced?

Postby Hooray » Fri Apr 19, 2013 7:23 am

Basically, your GPU is a massively parallel special-purpose cluster of "CPUs" (depending on the hardware, hundreds of tiny cores) that can do certain mathematical computations extremely well/fast by partioning the task at hand and handing each job to another work queue, which may be processed by hundreds of "dedicated cores sitting on the GPU" in parallel. Basically, your GPU is super computer (certainly when compared to the computing power of the 80s or 90s).

On the other hand, not all things can be easily run on a GPU (GPGPU aside for now) - and many parts of FG are simply not rendering-related, and cannot easily be moved to the GPU.

So your CPUs and idle cores are still relevant to handle all non-rendering related jobs, and other computations that are not appropriate for the GPU (ATM). Things like AI traffic, the FDM, autopilot computations, Nasal code - these all run in the main loop, before the final frame is created and rendered. So depending on how long each step takes, frame rate/spacing may fluctuate - which is less likely to show up on really fast systems like Thorsten reported.

Thus, the idea is not to use idle CPU cores for rendering related stuff - but rather optimize the FG<->OSG pipeline such that more main loop resources become available, so that certain tasks can be offloaded onto other cores. For example, OSG is able to run certain rendering-related optimizations asynchronously, outside the main loop. But that requires a paradigm change, because of the way FG makes currently use of OSG in a fairly sub-optimal fashion, even though Thorsten is right in saying that this particular issue doesn't show up on extremely fast systems with high-speed CPUs.

So Thorsten's system is unfortunately not representative of the overall situation for all users - because not everybody has a $ 3k workstation-style laptop at home with 8 64 bit cores (hyperthreading included), 16gb of RAM and a NVIDIA 670M 2gb SLI configuration. We need to be careful not to compare apples and oranges here, I have no doubt that Nasal code or poorly coded C++ code doesn't really show up on such a system.

Which doesn't really mean that anybody in particular would be wrong here, but originally the FG main loop was designed to be a single sequential loop that scaled roughly with the frequency of the CPU - which is why someone running FG on a "high-end" gaming computer today may very well have the impression that FG's architecture is not the problem, especially because of the number of background threads already added over time and now working behind the scenes, which ALREADY make use of additional cores to reduce the footprint of the main loop.

Again, performance issues like these are not obvious on high-end machines, no matter if it's framerate, frame spacing or the Nasal garbage collector - on a 3-4 ghz multicore system, there's usually enough horsepower available to make up for architectural shortcomings - but that only hides the real problem. And it's a well-known issue that computers used by developers are usually high-end machines, which end up masking problems encountered by end users, who may very well use much less powerful hardware.

If we all had access to 10ghz machines, we would all be having the impression that FG's architecture is rock-solid and that GPUs are the main problem :lol:

There's a reason why software companies tend to keep lots of hardware around, to do tests and benchmarks on old/common hardware.

Keep in mind that we still have many people here reporting that Rembrandt wouldn't work too well for them, which really isn't a totally different issue.

Blue sky, not much scenery fps=60 constantly - overcast local weather, KSFO dowtown with many many random buildings + multiplayer fps= 8 constantly...

I suggest to move that to a different thread (or even the issue tracker), but it would seem like a good idea to also post the OSG stats: http://wiki.flightgear.org/Howto:Use_th ... reen_stats
That should tell you directly where the bottleneck is under those circumstances.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Can FG computations be made more balanced?

Postby chris_blues » Fri Apr 19, 2013 7:42 am

That damned forum just ate my reply! :evil:

I'll go and try to make some sense of the OSG-stats...
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Can FG computations be made more balanced?

Postby Thorsten » Fri Apr 19, 2013 8:35 am

We need to be careful not to compare apples and oranges here, I have no doubt that Nasal code or poorly coded C++ code doesn't really show up on such a system.


Yes, I certainly agree here.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Can FG computations be made more balanced?

Postby chris_blues » Fri Apr 19, 2013 8:57 am

I have no idea, what this is trying to tell me. I have done, like described on the wiki page. First shot is standing still, frame-space corresponding to frame-rate, then flying a straight line in the second shot and the ones after are cruising over SanFrancisco in not such a staight line... the last one is standing still again.

I should add; not much MP traffic at that time of day! 2 others were there...

On the wiki, it also said, when the yellow line(CPU) is longer than the orange one(GPU) it means, that the CPU is too slow to get the data to the GPU, that clearly doesn't seem to be the case here. In fact, when cruising very fast the orange line didn't fit on the scale for splitseconds, while yellow, more or less stayed around 1/5 to 1/3 of the scale...

Image
Image
Image
Image
Image
Image
Image

Well, I hope this tells you guys something that might help add to this discussion...
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Can FG computations be made more balanced?

Postby Hooray » Fri Apr 19, 2013 9:10 am

Is the performance much better without AI/MP being used/enabled ?

Maybe you could use the flight recorder to record a flight, so that more people could try the same flight, recreating your settings ? That would basically be a simple benchmark.

Overall, that doesn't look too bad actually - completely interpreting this is a little difficult without also seeing the others modes (you can cycle through the OSG stats by selecting them again in the menu). Also, the system monitor itself will tell you if there is any particular subsystem eating up lots of resources. The GPU aside, you can also use the profiling fgcommands to identify code that is using lots of CPU resources: http://wiki.flightgear.org/Built-in_Profiler
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Can FG computations be made more balanced?

Postby chris_blues » Fri Apr 19, 2013 9:36 am

Hooray wrote in Fri Apr 19, 2013 9:10 am:Maybe you could use the flight recorder to record a flight, so that more people could try the same flight, recreating your settings ? That would basically be a simple benchmark.

Good idea!

But...
are we still on topic? I get the feeling we are moving to sth like improving framerate or sth...?

Still, the idea of creating a simple, easily recreatable benchmark flight, sounds good to me! What aircraft would be suitable? Is the UFO in the standard installation? I don't know, since I use the fgdata from git for years...
Then I would make some flight over KSFO, which should be on every FG installation, and then? What would I do with the recorder tape? upload it somewhere?

Edit:
Gee, I'm not sure I know, how to read this... I'll try to get this gperftools going...
BTW, only FG needs to be recompiled or OSG, SimGear as well?

Edit2:
To use the profiler FlightGear has to be compiled with gperftools and the CMake variable ENABLE_PROFILE set to ON (OFF is the default).

This is a bit confusing! I cannot compile fgfs WITH gperftools! or can I? But I can add to the cmake command -D "ENABLE_PROFILE=ON"...
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Can FG computations be made more balanced?

Postby Hooray » Fri Apr 19, 2013 10:24 am

Still, the idea of creating a simple, easily recreatable benchmark flight, sounds good to me! What aircraft would be suitable? Is the UFO in the standard installation? I don't know, since I use the fgdata from git for years...
Then I would make some flight over KSFO, which should be on every FG installation, and then? What would I do with the recorder tape? upload it somewhere?

Yes, the ufo or c172p should both work - you'd then share the file with us, including your rendering settings, so that we can recreate them. For example, Thorsten has a rather powerful system and it would be interesting what his performance stats look like.

I cannot compile fgfs WITH gperftools! or can I? But I can add to the cmake command -D "ENABLE_PROFILE=ON"...

right, you only need to rebuild FG from source - which only touches a single file, so that will be pretty fast, and it doesn't affect anything else. But building a debug binary makes sense.
Before you actually re-configure with ENABLE_PROFILE=ON, you need to install the google perftools, for ubuntu-based distros, see Tom's instructions at: http://wiki.flightgear.org/Built-in_Pro ... n.2FUbuntu

Afterwards, you should be able to normally run FG again, just with two more functional fgcommands - so that you can create your benchmark flight, and then use the Nasal console to collect profiling info while replaying it: http://wiki.flightgear.org/Built-in_Profiler#Nasal

Code: Select all
fgcommand("profiler-start");


Ideally, that should be kept running for a while (like 10-20 minutes), to gather enough data - you could for example use the ufo and circle around the KSFO region at 3000 ft AGL - or use the autopilot/route manager to set up a simple pattern.

Once you exit fgfs, a file named "fgfs.profile" can be found in your working directory - which can be easily visualized: http://wiki.flightgear.org/Built-in_Pro ... he_Results

Finally, note that this is only really useful in the context of CPU-related lag - it will not be useful to identify GPU bottlenecks like the ones Thorsten was talking about.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Can FG computations be made more balanced?

Postby chris_blues » Fri Apr 19, 2013 10:38 am

Hooray wrote in Fri Apr 19, 2013 10:24 am:Afterwards, you should be able to normally run FG again, just with two more functional fgcommands - so that you can create your benchmark flight, and then use the Nasal console to collect profiling info while replaying it: http://wiki.flightgear.org/Built-in_Profiler#Nasal
Code: Select all
fgcommand("profiler-start");

So, I put this command in the NASAL-console... that explains it, why I can't find no fgfs.profile anywhere... :)
Going for another round!
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1533
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Next

Return to Development

Who is online

Users browsing this forum: Honu4 and 14 guests