Subject: 3.2rc1 Overall impression
Hooray wrote:onox wrote in Sat Sep 13, 2014 11: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:
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.