Board index FlightGear Support Hardware

System Requirements for Flightgear

Joysticks, pedals, monitors.

Re: System Requirements for Flightgear

Postby Richard » Tue Nov 24, 2020 2:49 pm

Hooray wrote in Sat Nov 21, 2020 5:00 pm:the key people who were originally opposed to multi-threading and who have spoken up against it for many years, are no longer actively involved in core development.

Thus, the current situation with regard to multi-threading is likely to improve considerably over the course of the next 36-60 months.


The thing that is most likely to improve performance over the next 1-3 years is WS3.0 (virtual planet builder and LOD support).

Richard wrote in Wed Feb 19, 2020 11:53 am:As I've previously said there is very little to be gained in terms of frame rate from any extra use of the CPU with more threads; and I've proved this by implementing multi-threaded rendering. Using multi-threaded rendering on the F-15 does result in a slightly higher frame rate because the multi-threading saves around 4ms per frame however the rendering is still taking 18.68ms and that is at a location without that much terrain.


Pretty much all of my experiments thus far with multithreading has proved that probably the original key people were probably right to have spoken against the idea; maybe in the next 5 years someone might figure out how to make more use of threads - but mostly I'm out of ideas now.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: System Requirements for Flightgear

Postby GinGin » Tue Nov 24, 2020 2:55 pm

V12 wrote in Mon Nov 23, 2020 1:20 pm:BTW, where in the FG documentation is notice about large amount of custom sceneries can negatively affect performance ?


And now, you can then add it somewhere in the wiki or somewhere to inform the others instead of going back and forth with your P3D screens and performances ;)
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: System Requirements for Flightgear

Postby Hooray » Wed Nov 25, 2020 4:13 pm

Richard wrote:Pretty much all of my experiments thus far with multithreading has proved that probably the original key people were probably right to have spoken against the idea; maybe in the next 5 years someone might figure out how to make more use of threads - but mostly I'm out of ideas now.


No matter if people like it or not, there is the long-standing idea to use HLA/RTI to make FlightGear distributed (and originally there was actual work using DIS), i.e. in the form of separate processes that may run on separate processors/machines- and while it's correct that the initiators of that work seem no longer actively involved in FlightGear matters, there is at least /some/ existing code, and a number of senior contributors seemed in favor of the idea for several years and were widely promoting it - even those originally opposed to conventional multi-threading (e.g. look at Curt's threading comments versus his announcement to go all in on HLA/RTI in one of his interviews) .

That being said, as you know, multi-threading has already been increasingly adopted by the FlightGear project thanks to the use of OSG and, in the process, by FlightGear itself being increasingly adapted to make use of OpenSceneGraph's built-in multi-threading support.

And given that people have been moving towards a PagedLOD-based scenery subsystem, multi-threading is already increasingly in use - despite FlightGear itself, and primarily its main loop/property tree, being obviously single-threaded "by design". For many years the single-core assumption was obviously valid, and even today it is hard to actually saturate a single core.

Still, there are potential candidates for being split off, i.e. moved outside the main loop - some of which have been identified years ago (and where even all senior core devs agreed), e.g. things like the AI traffic subsystem, which could conceptually interface with FlightGear via the multiplayer system (or a customized variant of it), while also providing the benefit of making it straightforward to synchronize/replicate MP traffic across multiple inter-linked fgfs instances (which used to be the primary means for FlightGear to support multiple screens, i.e. prior to the OSG migration).

Durk himfself, as the primary developer of the AI traffic system, has in fact shared his views on the devel list ("FGTraffic"), and he kept pointing out all the shortcomings of the existing system, and specifically encouraged people to help with using a MP-based approach to "inject" traffic feeds into fgfs via the fgms pathway: http://wiki.flightgear.org/FGTraffic#The_Future

And Mathias, as the initiator of the OSG and HLA/RTI efforts, pointed out how a handful of systems could/should be moved outside the main loop via HLA/RTI, and how his approach would not only support a process-based modularization, but also using a SGThread-based wrapper to run such SGSubsystems in a standalone fashion inside the main process in dedicated worker threads:

https://www.mail-archive.com/flightgear ... 32973.html
Mathias Fröhlich wrote:The trick is that each of these threads must be done in a way that you
can just compile that alternatively in a single standalone binary and run the
same component in a networked rti - the LinuxTag booth for example.


More recently, a number of aircraft developers have run into performance issues on Canvas-heavy aircraft, i.e. those featuring multiple independent Canvas MFDs - and in fact, complex Canvas avionics like the FG1000 may take several seconds to initialize on lower-end systems.

But given that a Canvas-based display has usually a well-defined set of inputs (e.g. properties, nav DB queries, I/O state) and outputs (usually a single texture/osg::Image), it would not be that far-fetched to increasingly move towards an optional Canvas execution model, where these inputs are provided by an input vector, processed by a Nasal background thread (using a private, non-globale, props.Node/SGPropertyNode object).

Some of the more sophisticated MFD wrappers/frameworks already tend to use property memoization/caching to reduce the amount of redundant property accesses, i.e. where a wrapper overloads setprop/getprop / props.Node and merely updates a Nasal-space data structure, instead of actually forwarding that I/O every time to the underlying C++ data structure - such a setup could serve as the foundation for a per-frame "ready-only state vector" that is then used by the background thread to do its computations, before updating the /canvas texture in the private property tree.

At that point, the main synchronization points required for such a setup would be the beginning of a frame to fetch/copy all relevant state into the Nasal data structure, and then at the end of the frame, update/unlock the actual osg::Texture or osg::Image (since OSG has built-in support for using an osg::Image provided by an OSG thread).

Obviously, this won't be of much interest to existing Canvas avionics, because it would be a pain to update those (and probably very fragile) - but thinking about how future avionics are to be structured, does make sense since they're are likely to become increasingly complex over time, and maybe refine the underlying frameworks/APIs to provide the foundation for a future where Nasal may only operate on a read-only copy of state retrieved from the main loop, and only have write-acess to a private property tree instance for a single canvas texture.

With the recent work on CompositeViewer support it's actually becoming increasingly likely that we will end up with support to provide Canvas avionics with their own OSG window, which also means that they can use their own private scene graph, completely unrelated to the main scene graph used by FlightGear, which is also in line with plans orginally discussed by Tim and Mathias:

https://sourceforge.net/p/flightgear/ma ... /20014126/
Tim Moore wrote:A moving map is a different beast. It would make sense to implement that as a
scene graph in its own right with its own pager. That would require a change in
current fg architecture to use a CompositeViewer instead of a single Viewer, but
we're contemplating that anyway.


https://sourceforge.net/p/flightgear/ma ... /19718354/
Mathias Fröhlich wrote:What we just need is the ability to still redirect some windows to an other
display/screen.

What would be good to have is the specify a completely different scenegraph in
some subcameras. I think of having panel like instruments on an additional
screen/display for example.


[...]
I have an animation that I call rendertexture, where you can replace a
texture on a subobject with such a rtt camera. Then specify a usual
scenegraph to render to that texture and voila. I believe that I could finish
that in a few days - depending on the weather here :)

The idea is to make mfd instruments with usual scenegraphs and pin that on an
object ...



So I don't think we're running out of ideas for quite some time to come ... many of these have been laid out years ago, it's just that nobody kept track of what senior OSG contributors said in the context of improving FlightGear's rendering performance by moving well-defined functionality out of the main loop - look at the shelf life of the CompositeViewer idea, or the shelf life of supporting multiple renderers (Compositor) :wink:
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: System Requirements for Flightgear

Postby V12 » Thu Nov 26, 2020 7:11 am

What about NASAL ?
It is interpreted language. And all knows that all interpreted languages are too slow, because all executed lines must be "compiled" everytime when are executed. No buffers, no cache etc. All advanced weather is driven by NASAL, low speed of this solution is very visible when AW generates new cloud fields - we can see how NASAL script generates cloud after cloud and FG in this moment stuttering.
Another example of the NASAL poor speed in noticed canvas system is especially NAV display. You can recreate situation very simply - spawn on Lhasa in A320family (most advanced avionics and ND), start all systems and look around and observe framerate, probably You will not notice any stuttering. Then enter flightplan ZULS (any depart procedure) to VQPR STAR TASHI RNAV - Z rwy 15 and again look around. You will notice clearly visible heavy stuttering in high framerate. Check this video :



You will see abnormal heavy stuttering. IMHO, interpreted NASAL is responsible for that, because NASAL is behind canvas implementation of the NAV display and all avionics. If will be possible to move all NASAL things from main loop to dedicated thread out of the main loop, all that stuttering should be supressed.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: System Requirements for Flightgear

Postby Hooray » Thu Nov 26, 2020 11:25 am

If you read again carefully, you will notice that I did hint at Nasal and Canvas, too.

Your observations may seem obvious to you, but they're far from it. In FlightGear, you will typically want ~60 fps (hz).
Nasal standalone can easily provide ~1khz (1000 hz) - Nasal also supports threading in FlightGear, and those threads will typically run at >= 500 hz.

The real bottleneck is not due to Nasal being interpreted - Nasal has certain I/O requirements which are poorly formalized, i.e. any extension functions called by Nasal must be executed inside th main loop, because there is no thread-safety on the FlightGear side of things (Nasal itself is indeed designed to be thread-safe). So, it's primarily those extension functions (property tree accesses) and the GC (garbage collector)

This has been extensively discussed over the years, and you are unlikely to come up with a full picture of the situation unless you happen to be an experienced C++ developer familiar with the way Nasal is integrated in FlightGear (SGSubsystem really just being a shell), while most code is actually invoked via timers (events) and listeners (properties).

Even experienced aircraft developers continue to fail drawing the proper conclusions when it comes to Nasal and Canvas. And in fact, when it comes to the Canvas, you could even set up a Canvas and manipulate that using property rules, i.e. without using any Nasal.

For the Canvas specifically, it would pay off to come up with additional native primitives (so called elements) - and potentially primitives that have a data provider linked directly - e.g. a dedicated mapping element with support for navdb queries, where the type of query would be specified, the range, center and a few styling related attributes for the symbols to be drawn - that would get rid of tons of Nasal code in the main loop, which also means less GC/property I/O "pressure". We kinda started developing MapStructure that way, but that's obviously still using Nasal under the hood.

Also, things like the MFD framework would ideally become a native Canvas element - so that people actually structure their MFDs/avionics using a well-encapsulated design, basically sub-classing from a generic MFD element with pages and page elements - this would solve a ton of issues, especially when it comes to optimizing things internally, it will be much easier to do so in a holistic fashion if people use a common interface.

Either way, even if you were to find an approach to run Nasal scripts outside the main loop, that would almost certainly not be applicable to existing scripts/addons. There are too many implicit assumptions at work here, i.e. all the dependencies are not properly formalized - so that things would get really fragile quickly.

One option we do have is coming up with new "modes" to run certain Nasal modules outside the main loop, while using a well-defined interface to talk to FlightGear. However, that kind of coding would look very different compared to what aircraft developers are used to now. It would be more akin to message-based programming (think MPI or even Emesary use by the FG1000).

But that only makes sense on a strictly opt-in basis, i.e. for new features - the addon system would be an ideal candidate for this, i.e. a dedicated environment for addons that may run outside the main loop, while still being written in Nasal. And, in theory, that would also work for new canvas avionics - i.e. coming up with a new runtime environment, where the corresponding Nasal namespace has no access to any main loop resources other than sending/receiving messages and working with its own private property tree/canvas tree: http://wiki.flightgear.org/Howto:New_Ca ... tion_Model

Either way, for the time being, the main issue is the lack of proper diagnostics - most people (those without a core development background) cannot be expected to properly interpret Nasal related performance issues, and differentiate between the different causes (GC, property I/O, redundant callback invocation (timers/listeners), poor algorithms etc).

At this point, what would really go a long way, is adding additional diagnostics in the form of "live" properties, to look behind the scenes of the Nasal environment - i.e. in the form of samples taken to track GC internals (active/removed references/objects), property I/O (read/write accesses), listener invocations, timer calls, naPool reallocations etc

That's the kind of information that would ideally be provided by FlightGear in the form of live properties "per frame", so that people can use that to log such details to the console or a file, or even hook up the whole thing to the built-in OSG StatsHandler - and that's when people will realize that these findings will vary greatly, depending on startup/runtime settings (aircraft, scenery, environment etc) - so what's really missing is the equivalent of a "process monitor" for Nasal specifically, so that end-users and aircraft developers can make better bug reports, and provide actionable information to people able to fix up things internally.

Don't get me wrong, there clearly is plenty of optimization potential left when it comes to complex Canvas avionics (think FG1000), but that has little to do with Nasal being interpreted, and compiling Nasal to native code also doesn't magically solve the real problem. It is however unlikely that we will find a way to magically run existing Nasal modules outside the main loop without running into race conditions and synchronization bottlenecks - under the hood, the free-form nature of properties+Nasal makes FlightGear a rather chaotic petri dish actually, because people have so much freedom to implement their ideas, which also means that core developers cannot easily formalize data/flow dependencies between different modules, because the main loop is such an "anarchist" place the very instant the property tree and scripting are involved - in turn, that also means that people can get really fancy and implement sophisticated features without requiring support or endorsement from core developers (think bombable addon, local weather, earthview, space shuttle etc - all these features were developed on top of the very freedom and flexibility provided by this anarchist environment we tend to call a "flight simulator", whereas reality suggests it's as much a "flight sim" as vim or emacs are "just editors" ) :D

The property tree, XML and Nasal are definitely contributing to many issues in FlightGear (and so is the Canvas), however it's too late to put the genie back in the bottle: middleware/base package development (aircraft + fgaddon) has long surpassed core development in terms of manpower, resources and activity ... and it's these very building blocks that make it happen.

So all we can do is look at the facts, and the history to learn a lesson or two from that - and since backward compatibility is essential, you cannot just go and break stuff, you can only come up with new/better features and try to convince content developers to adopt those (i.e. due to better performance) - which inevitably means such improvements must be strictly opt-in.

Trying to deal with existing Nasal code and trying to offload that onto separate threads isn't gonna happen without re-architecting things - it's the equivalent of trying to turn a 20-year old car into an electric car, while riding on the highway :lol:

Like your posting is showing, people tend to misunderstand Nasal and FlightGear performance in general, and they tend to be drawing the wrong conclusions (indeed compiling Nasal to native code has been suggested a few times already, and so has replacing Nasal altogether or moving it to a separate thread ...):



PS: In theory, we /might/ be able to get away with running Nasal's GC concurrently with OSG's culling - since culling the scene graph is essentially "the same thing" as reaping in the GC, i.e. it's all about traversing a graph/tree structure to decide which elements are relevant/irrelelvant (visible vs. referenced) - at that point, we would run the GC more frequently obviously, but that way, the amount of total work should go down in comparison, because there would be much less of a chance for too much work to accumulate in between two frames; Richard has done some experiments related to running parts of the GC interleaved with OSG. And a couple of years ago it was Anders who came up with a patch to make the GC threaded - the real issue is, it's a mark/sweep collector which isn't incremental/generational, and Anders' patch showed up roughly at the same time as the Canvas system got introduced, which all of a sudden added a ton of Nasal ghosts for things like Canvas (OSG) data structures - basically tying Nasal and OSG together, which is kinda unfortunate admittedly: http://wiki.flightgear.org/How_the_Nasal_GC_works
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: System Requirements for Flightgear

Postby V12 » Thu Nov 26, 2020 1:08 pm

Hooray wrote in Thu Nov 26, 2020 11:25 am:If you read again carefully, you will notice that I did hint at Nasal and Canvas, too.

Sorry, what is this ?
Hooray wrote in Wed Nov 25, 2020 4:13 pm:More recently, a number of aircraft developers have run into performance issues on Canvas-heavy aircraft, i.e. those featuring multiple independent Canvas MFDs - and in fact, complex Canvas avionics like the FG1000 may take several seconds to initialize on lower-end systems.

But thx for explanation.

I had problem with NASAL performance too, when worked on TCAS and WX radar for Concorde with standard canvas implemented in FG. Then I adopted very old Artix code for NAV display, for better performance added filter on distance and aircraft speed, because around busy airports like EHAM, EGLL or EDDF You can have 200 AI aircrafts, then active traffic layer on ND can eat 30-50% fps.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: System Requirements for Flightgear

Postby Hooray » Thu Nov 26, 2020 1:25 pm

Yeah, artix was basically the only contributor to successfully use the MapStructure framework for what it was designed for ... however, back when we wrote MapStructure it was explicitly intended to allow people to override all sorts of defaults - including the filter (searchCmd) implementation. Like you say, having dozens (or even hundreds) of AI nodes will obviously mean more work for Nasal to process when the searchCmd routine is invoked (= property I/O, let's say 5 property reads per AI node X 200 = 1000 read access, which are in turn used to instantiate new nodes, because all canvas drawing goes through the property tree - creating at least another new ~1000 nodes for 200 elements, and probably even more).

Like I said, it's been years since we wrote that code, and it was basically a large rewrite of code originally contributed by Gijs - so we had to make it work somewhow without breaking tons of stuff, the messy ND code is a testimony to that. Functionality-wise it was very much superior to what we had at the time, but the structure suffered massively.

I haven't looked at that code in years, but obviously the right thing to do would be not to run the whole searchCmd during a single frame, but instead spread the workload across multiple frames - say, we expect on average 30 fps, and we want up to ~210 aircraft processed within one second, that would mean roughly 70 nodes per frame to be processed, but obviously that will differ for people depending on their hardware. Basically, it would be better to adopt Richard's frame-loop abstraction for stuff like this and merely specify a max impact on frame spacing that is acceptable (say 5 ms) and then use that as a soft constraint while iterating through /ai/models.

And keep in mind, what you are saying here: You state Nasal performance as the problem, and then you indirectly admit that it's actually property I/O that is the bottleneck here.

But again, this is also one of those situations where it doesn't necessarily make sense to process everything in scripting space - we ran into the same issue when implementing the FIX layer, which would mean hundreds of fixes to be processed and created/updated on demand. Ultimately, we decided to create a "vector diff" extension function in C and we then simply invoked that from Nasal, which meant much much better performance.

That would also be an option for the searchCmd routine of the AI/MP MapStructure layer - the algo/function will look almost the same, i.e. with a few very minor differences. It would address 90% of the performance issues people are seeing when working with an AI/MP traffic layer. However, the proper fix would be to sub-class sc::Map to implement an interface class for stationary and moving targets - which is what we did in MapStructure, if that's ported to C++ space, you'll get rock-solid map layers, that are populated by C++ code, with Nasal only providing the texture map coordinates for the instancing/animation of the symbols (VOR, FIX, NDB, WPT, TFC).

Sorry, what is this ?

See my comments about CompositeViewer support likely paving the way for Canvas avionics to optionally use their own dedicated windows, and scene graphs, which at some later point in time also means that well-encapsulated avionics (FG1000 via Emesary) could potentially run outside the main loop, because their data flow dependencies are already well-understood due to the use of Emesary - i.e. if a device like the FG1000 stops invoking extension functions (navdb queries, getprop, setprop and friends) directly, it's all of a sudden much more straightforward to start a dedicated SGThread with its own FGNasalSys instance, or use a Nasal worker thread to emulate the device that way, because all main loop I/O is being handled by an MPI framework like Emesary.
However, as I alluded to, that won't be of interest to other avionics using a less stringent/formalized structure - because those would indeed need to encapsulate/wrap all API invokations to stand a chance at all.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: System Requirements for Flightgear

Postby V12 » Thu Nov 26, 2020 5:33 pm

OK. Why is NASAL I/O slow, but JSBSIM not ?
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: System Requirements for Flightgear

Postby Hooray » Thu Nov 26, 2020 5:41 pm

please let's not compare apples and oranges here ... Nasal runs as part of the "cooperate multi-tasking" subsystem structure that FlightGear provides - i.e. time-sharing, typically once per frame. And any subsystem that takes more time than expected will cause a hiccup - we even have C++ code that tends to do just that (e.g. the AI traffic system).

JSBSim however is not executed as a Subsystem per frame, instead it gets to run more frequently per frame (I think the default was once something like 120 iterations per frame ?)

Also, look at the pure amount of property tree I/O going: JSBSim properties are maybe in the hundreds (?) - whereas, a Canvas sub-tree is easily in the thousands.
JSBSim properties are also typically "just" PODs - whereas Canvas properties typically represent more complex data structures, often triggering listeners (callbacks).

Besides, for many years, JSBSim used a trick: so called "tied properties" (not sure if that's still the case) - basically, using the address of C++ variables rather than working with the property tree API (which is causing other problems, especially on the threading front and that is also why fdm listeners don't work as well ).

Thus, apart from being scripted code vs. native code obviously, you cannot really compare subsystems executed per frame versus those intended to run dozens of times per frame.

And obviously there is the context switching overhead when Nasal code is involved - but otherwise, it's not a fair comparison, we've seen plenty of examples of C++ subsystems that would cause stuttering (degrading frame rate/spacing).

Again, rather than posting screen shots showing other flight simulators, it might make more sense to read up a little on how FlightGear is structured, how scripting relates to that and what has been previously said in the context of multi-threading, HLA/RTI.

There are built-in tools that you can use to help you better understand how FlightGear works (osg stats, performance monitor, built-in profiler, Nasal benchmarking to name just a few).

And once you open the performance monitor, you will see that the "fdm" subsystem (JSBSim) gets updated more often than the rest of the systems (except for those running interleaved with the FDM/flight, i.e. the AP/systems/instrumentation, see the column titled "iterations"):

http://wiki.flightgear.org/Howto:Use_the_system_monitor
Image

In particular, it's worth noting that "nasal" (scripting) isn't representative - instead, "events" should probably be named "nasal-events", and properties should have its own nasal tracking, too ...
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: System Requirements for Flightgear

Postby V12 » Thu Nov 26, 2020 10:33 pm

Hooray wrote in Thu Nov 26, 2020 5:41 pm:Again, rather than posting screen shots showing other flight simulators, it might make more sense to read up a little on how FlightGear is structured, how scripting relates to that and what has been previously said in the context of multi-threading, HLA/RTI.

I leave this for developers, I'm only user.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: System Requirements for Flightgear

Postby GinGin » Fri Nov 27, 2020 12:19 am

V12 wrote in Thu Nov 26, 2020 10:33 pm:I leave this for developers, I'm only user.


So , people take time to explain you things again and again with detailled answers . But you don’t want to read more about it and prefer to post unrelevant screens to complain about things you don’t dare to at least to educate yourself about a minimum ?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: System Requirements for Flightgear

Postby Hooray » Fri Nov 27, 2020 10:42 am

V12 wrote in Thu Nov 26, 2020 10:33 pm:I leave this for developers, I'm only user.


With FlightGear, once you can download and run it, you are a potential contributor. And once you can use an editor and take screen shots (which clearly is your strong forte :D ), you are already a developer :wink:

Seriously though, you've been posting rather technical questions and suggestions, so please don't be surprised if people treat you accordingly.

Also note that I merely suggested to do a little background reading prior to making such postings, once you start doing that, you will realize that many problems don't have an obvious solution. And you may in fact come to appreciate the finer details of the project by doing a little bit of legwork. Look, this isn't rocket science after all (unless you start tinkering with the shuttle that is :lol: ) - the tools I mentioned (OSG stats, performance monitor) are readily there, to be used by all end-users who are able to run FlightGear.

As has been said already, some of us took the time to answer your questions and to specifically respond to your ideas/proposals - the point being, it seems, you aren't exactly bringing across the impression that you are actually "reading", let alone, "processing" our responses - it's usually the same pattern: you pose a few questions and suggest a few things, then a handful of contributors take the time to get back to you (often in great detail, even posting links to related readings), and then all of a sudden you politely thank everybody by posting a one-liner, while continuing to post identical questions in subsequent postings, either in different topics or sometimes even a few days/weeks later, posting in the original topic.

If you are seriously interested in understanding Nasal/FlightGear performance, it makes sense to look up the pointers that have been shared with you (look especially at the postings made by Vs or Richard over the course of last couple of months).


https://www.mail-archive.com/osg-users@ ... 29898.html
Robert Osfield (OSG project lead) wrote:With graphics applications the load is taken up between the disks,
memory, buses, CPU cores, CPU caches, GPUs, etc. any one of this might
be the bottleneck at any one time. Which is most likely to be a
bottleneck will depend on the nature of your application, the type of
scene you have, the OS, the OpenGL drivers, the graphics card, the
motherboard etc.


It's nothing unusual to be maxed out your system yet still not full
utilise an single resource such as CPU cores. What you are actually
trying to achieve with a graphics application is to tread lightly but
still achieve your goals, i.e. keep the whole system comfortably
handling the load but still hitting your required frame rate.

So rather than try to max out CPU utilisation you should be looking at
whether your application hits the required frame rates with your
required models and then to look at the bottlenecks if it doesn't
achive this. Looking at maximizing CPU utlisation is a false goal,
you need to ditch it right away and start focusing on what will
provide your end users with the best experience possible.
[....]

I'm afraid there is no substitute for investing time in learning about
optimization of graphics applications, it's a big topic, one that you
have to consider every component of the computer and how the software
interacts with it.

There are many many things you can to do turn an scene from one that
renders at 15fps to one that renders at a solid 60Hz.

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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: System Requirements for Flightgear

Postby SGFlightSimmerYT » Mon Jul 25, 2022 6:51 am

I got Intel i7-7500U cpu (min 2.7GHz, max 2.9GHz), intel hd graphics 620/nvidia gefoce 940mx gpu, RAM 8GB
i can run flightgear at 10fps....
how to run at normal (20 minimum) fps?
SGFlightSimmerYT
 
Posts: 19
Joined: Thu Jul 21, 2022 9:52 am
Location: Singapore
Callsign: 9V-SGFS
Version: 2020.3.13
OS: Windows 10 21H2

Re: System Requirements for Flightgear

Postby TheEagle » Mon Jul 25, 2022 9:13 am

Either turn off ALS, or lower your graphics settings, or fly in lighter scenery …
Cessna 210 (Wiki)
My other aircraft: my wiki profile !
Other: FGTools (GitHub)
World tour: View on SkyVector
Please consider donating $1 / €1 to help me finance a new camera !
User avatar
TheEagle
 
Posts: 3413
Joined: Sat May 01, 2021 3:27 pm
Location: France
Pronouns: You, he
Callsign: F-EAGLE
IRC name: none
Version: Git next
OS: Ubuntu Studio 22.04

Previous

Return to Hardware

Who is online

Users browsing this forum: No registered users and 2 guests