Board index FlightGear Development Canvas

FlightGear/Canvas on dual-core Netbook (Intel GMA graphics)

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

FlightGear/Canvas on dual-core Netbook (Intel GMA graphics)

Postby Hooray » Sat Sep 13, 2014 8:50 pm

Like I mentioned previously, I built FlightGear on a fairly underpowered netbook to see how well Canvas works there (given all the "white rectangle" bug reports) - in addition, I am hoping to understand how to improve the initialization process for slower systems:

Subject: 3.2rc1 Overall impression
Hooray wrote:
onox wrote in Sat Sep 13, 2014 10:35 am:Has any dev tried to disable their nvidia card and use their built-in intel GPU for once? :)


I recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - I do think that a few contributors try to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work. But I do agree that FG would be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:

http://wiki.flightgear.org/FlightGear_Headless
http://wiki.flightgear.org/Testing

Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.

People wanting to change that, need to roll up their sleeves and get involved, and provide feedback.
all testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: http://wiki.flightgear.org/Howto:Optimi ... le_devices

The whole FGCanvas thing (FG with most subsystems disabled) does work even on hardware as old as 7 years: http://wiki.flightgear.org/FGCanvas


Here's a screen shot of the whole thing:
Image

And here some initial observations:

  • our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit
  • once I close the dialog, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!)
  • hiding the PUI menubar further helps increase frame rate and improve frame spacing
  • hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s
  • the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !)
  • it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!)
  • in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100%
  • Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage)
  • there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on

I am hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs.
If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine.
So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM.

The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby zlsa » Sat Sep 13, 2014 9:04 pm

I've used FGFS on a slow laptop for a while now; PUI is abysmally slow. Framerates with menu hidden are in the 20-25fps range; with the menu shown it drops to 15-20fps; and with the rendering options dialog open I'm lucky to get 8fps). Canvas PFDs are slow as well; the map dialog is unusable. I actually thought that these speed problems were already known, hence the push for Canvas GUI.
zlsa
 
Posts: 145
Joined: Fri Feb 14, 2014 2:29 am
Callsign: N275A
Version: 3.5 git
OS: Linux

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby Hooray » Sat Sep 13, 2014 9:32 pm

What MFDs are you referring to ? Have you tested those without the corresponding aircraft, to rule out aircraft-specific issues ?
If you're indeed just referring to a Canvas PFD here, do you mean Gijs' (744) or Torsten's (the latter should perform much better) ?
Otherwise, the ND code still isn't overly optimized, it is doing some things better than other code, but there's still room for improvement.
However, there seem to be a number of unrelated issues...

Nope, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs. For instance, here's the new "Aircraft Center" on the same netbook:

Image

However, there's much more going on, some subsystems are unnecessarily slow, too:

Image

The map-canvas dialog you mentioned, is indeed performing worse than the native Canvas version:
Image

Here's the MapStructure self-test for comparison (no PUI involved, and functionality is basically equivalent to above, in terms of listeners/timers running):
Image

It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization.

But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ...

We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself.

People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing stupid things, and that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have.

http://wiki.flightgear.org/FlightGear_Benchmark
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby zlsa » Sat Sep 13, 2014 10:59 pm

Well it's been a few weeks, so I don't remember which aircraft I tested the ND with, but I used at least the 744. I wasn't aware there's a new Canvas MFD implementation being worked on right now.

The only issue with building from source on my netbook is that it takes a good 6 hours to build FlightGear; if you want me to report any issues on a slow computer I'd be glad to do so.

P.S. What's "Enabling ATI viewport hack" actually do? It enables it on nVidia, too.
zlsa
 
Posts: 145
Joined: Fri Feb 14, 2014 2:29 am
Callsign: N275A
Version: 3.5 git
OS: Linux

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby Hooray » Sat Sep 13, 2014 11:13 pm

yeah, building is indeed slow - if you also have a faster computer you can use a combination of distcc/ccache to build the whole thing much faster, which is what I am using here, because the netbook is simply too slow to build everything from source - I already opted to use packages for everything but SG/FG (and fgdata obviously). There's a fairly cool "distcc-pump" tool available which can delegate most of the work to another, more powerful, computer - the alternative would be cross-compiling for the netbook.

Concerning the ND, it is true that we can still optimize quite a few things - but most aircraft are literally unusable on such a slow computer understandably - thus, it would be better to test such things "standalone", i.e. in GUI mode. Or at least investigate optimizing other things first - i.e. I just rebuilt using the built-in profiler: http://wiki.flightgear.org/Built-in_Profiler

Also, for regression testing purposes, you need some kind of lightweight setup to end up with a working fgfs session - the minimal startup profile is starting up here within 20-30 seconds typically: http://wiki.flightgear.org/Troubleshoot ... up_profile

The main showstopper here is indeed the navcache, which does need to complete first - and which can easily take anywhere between 10-20 minutes apparently - fortunately, it will usually only need to run once per update, but that would be one of the lowest hanging fruits to optimize startup performance.

Otherwise, it's mainly a matter of using existing tools and interpreting the results, e.g.:

And obviously, we also need to come up with some test case that can be easily left running unattended, such as either a flight plan (route manager), a pre-recorded flight, or a flight recorder tape:


Depending on your OS of choice, there are other tools, such as gdb/valgrind or oprofile that can provide additional stats - but that is obviously going to be a bit more involved.

Getting rid of PUI and adopting Canvas for the GUI will obviously help with UI related issues - but there are at least a handful subsystems that are eating up more CPU cycles than would be necessary here, and it is really only showing up in such slow hardware.

It would probably be a good idea to document such findings so that we can investigate what's going and and try to fix these issues over time.

PS: the viewport hack isn't needed, but the people who added it didn't bother using GL_VENDOR detection to disable it, but it doesn't do any harm - for all the nitty gritty details, see: https://code.google.com/p/flightgear-bu ... ail?id=385 or even: search.php?st=0&sk=t&sd=d&sr=posts&keywords=ati+viewport+hack

(admittedly, we may want to better document the message ...)
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby zlsa » Sun Sep 14, 2014 1:21 am

Oh damn, that bug bit me for a while, googling about it brought up no results. Every once in a while, resizing the window would fix it.... good to know it's been fixed.

(Before you ask, this was a few years ago before I'd gotten this involved in FG, which is why I didn't file a bug report.)
zlsa
 
Posts: 145
Joined: Fri Feb 14, 2014 2:29 am
Callsign: N275A
Version: 3.5 git
OS: Linux

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby Hooray » Mon Sep 15, 2014 9:41 pm

And here's a screen shot showing the upcoming Canvas menubar (25ms/@55fps) vs. PUI (80 ms, 25 fps):
Image
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby Hooray » Sun Sep 21, 2014 6:36 pm

Originally, frame rate and frame spacing were pretty good when showing just the Canvas/Aircraft Center, with ~40fps and 44ms even on Intel GMA graphics - here's the same dialog on the same computer (netbook with integrated graphics), still with all the C++ subsystems running (no dedicated fgcanvas mode so far), but with ~50% improvement in both, frame spacing and frame rate - i.e. 25 ms at ~60 fps with a modified binary that is using different rendering settings (obviously, there's still more Nasal involved here than in the hard-coded PUI menu bar, but it's all OSG code - i.e. fewer state changes):

Image
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby TheTom » Sun Sep 21, 2014 6:56 pm

How does it behave if you interact (eg. something that triggers mouse over effects) with the dialog? If you don't trigger any changes its basically just rendering about 10 textured quads.
Also it seems like you have somehow disabled clipping of the scroll area?
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby Hooray » Sun Sep 21, 2014 7:28 pm

yes, those are artifacts that I introduced when playing with introducing OSG expressions (osg::switch/multiswitch for C++ rendering logic) :oops:

Yes, it is true that triggering listeners/events will affect frame rate - typically, in the ~15 ms/fps ballpark .- but scrolling really fast will cause spikes of 40-50+ ms , which is part of the reason why I am trying to use OSG expressions and encoding such logic at the scene graph level, and hopefully use less Nasal and more SGPropertyChangeListeners directly.

When I go really crazy with scrolling up/down, I can cause ms/fps spikes/lows of ~350ms and ~5fps respectively.

Currently, my idea is to wrap up SGPropertyChangeListener (or propertyObjects<>) in a node visitor so that we can add such "property-based animation stuff" directly into the sg, i.e. based on this tutorial: http://trac.openscenegraph.org/projects ... /OSGSwitch

Without necessarily having to use Nasal for everything - but we need to encode some way of "hints" for Canvas then, so that it knows that a group can be expected to be transformed in a certain way, and set up the osg::group subclass to prepare this without too much Nasal being involved, i.e. the osg::group subclass will be directly updated by properties or timers

My working theory so far is that mapping rendering logic to the corresponding OSG group structures (sequence, switch, multiswitch etc) should be faster if we manage to set up a C++ visitor struct/class that selectively controls each type of group directly, but first I need to look at some of the more common use-cases and find matching OSG::group sub-classes: http://trac.openscenegraph.org/document ... 00357.html

And then we need to look at our features/widgets to see how they are likely to benefit, i.e. a scroll area is about clipping/transforming and then map that to OSG primitives.

I am using gDebugger and oprofile so will do some more profiling and testing and post the results here, but I am seeing several Nasal-related APIs in the profile, too - which kinda suggest that I should look at that "generational-gc" branch again some day 8)

Code: Select all
CPU: Intel Atom, speed 1.6e+06 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Core cycles when core is not halted) count 100000
samples  %        symbol name
30514    10.0683  run
25850     8.5294  simgear::canvas::Group::getChildByIndex(unsigned int) const
12363     4.0792  naiHash_sym
11461     3.7816  SGSkyDome::repaint(SGVec3<float> const&, SGVec3<float> const&, SGVec3<float> const&, double, double)
9650      3.1841  simgear::canvas::Element::getMatrix() const
8660      2.8574  findcell
7484      2.4694  SGAtomic::operator++()
7468      2.4641  simgear::canvas::Element::isVisible() const
7130      2.3526  resize
5719      1.8870  int find_child<char const*>(char const*, char const*, int, vector<SGSharedPtr<SGPropertyNode>> const&)
5083      1.6772  noise3(double*)
5035      1.6613  naHash_get
4102      1.3535  SGPropertyNode::getChild(string const&, int, bool)
4000      1.3198  validateName(string const&)
3825      1.2621  getMember_r
3655      1.2060  simgear::canvas::Group::update(double)



I have used the other patches I sent you earlier to disable other non-Canvas related rendering here.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear/Canvas on dual-core Netbook (Intel GMA graphi

Postby Hooray » Sun Sep 28, 2014 10:16 am

TheTom wrote in Sun Sep 21, 2014 6:56 pm:How does it behave if you interact (eg. something that triggers mouse over effects) with the dialog?



The recent commits made by Torsten and Stuart have also improved the situation for "fgcanvas" considerably - even "crazy scrolling" will now provide on average ~45 fps/ms (both), so it's pretty good.

The main issue here is that our effects system cannot be disabled for the time being - I've been in touch with Thorsten about this, and it seems effects are built during startup, even if they are not used - once you dump the scene graph to an *.osg file via the debug menu, you'll also see all kinds of shaders and effects in the scene graph, despite all of those being normally disabled - Thorsten also pointed out that some heavy textures will be loaded that way - so understandably, this is a potential issue for people with similar hardware, and we should explore providing an option to entirely disable such things on demand.

On the other hand, this might become a no-brainer once Canvas itself supports effects and shaders, so we'll see how things will evolve over time - but back when I was working on "fgcanvas", I completely missed that all those textures and effects would be loaded/built regardless.

Also, it would still make sense to either add some kind of unit test for the effects issue or at least expose the number of listeners as a property to track down such issues much earlier hopefully - we've already seen bug reports related to this issue 6-8 months ago, so people shouldn't have to rediscover such bugs ...
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: 11317
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 41 guests