nVidia Driver Tweaks for Fligthgear on *nix OS

[valery]

I have recently changed my laptop for a better one, but when I upgraded my OS I encountered some regression on FGFS rendering. So I investigated on many things, and I'm happy to share with you some of them I discovered during my investigations. My own troubles still continue, but are in a good way ..

I'm running a FreeBSD OS, but you can actually use everything under Linux, NVidia drivers are "more or less" the same ("more" here means Linux can use CUDA for example (Blender is very happy... ), FreeBSD cannot amongst others)
I think it is possible to tweak your NVidia card under MSWindows the same way, but I'm not sure. Just read carefuly your nvidia README, the team really provides a lot of information for everyone.

I heavily used GLMark2, a kind of "apt-get install glmark2" on Linux could help you if you want to benchmark your GPU + test your parameters.
Notice that a better GLMark2 score do not leads to a better performance on FGFS. This is because GLMark2 bench everything relative to OpenGL, and FGFS don't use everything relative to OpenGL. So, some score matters, some others don't.

Anyway, if you don't have already set-up your driver, this is the good time to do it.
I - nvidia driver optimization:
- these settings have been tested on an *nix OS, I don't know if they are
useable for MSWindows OS, but I guess yes.

I use the "Application Profiles" feature through the nvidia-settings app. as seen here:


It's really easy to use: you first define a profile (2cd Profiles tab), then you define what app (1st tab) use this profile. Save everything, launch you app, and see. Some parameters can be defined at start time on your shell environment (export ...)

1) The 1st parameter that has really improved my fps is _GL_YIELD="NOTHING"
I think that you can ignore the calls sched_yield() on multi-core CPU
setting it to "NOTHING", so the driver don't wait on external state to
change. Of course, this consume a bit more CPU, but I think that is not
relevant on a 4-Cores for example.
In order to be clear, take an eye on this glmark2 bench:
With GL_YIELD at its default value (on)
[build] use-vbo=false: FPS: 3287 FrameTime: 0.304 ms
[build] use-vbo=true: FPS: 3463 FrameTime: 0.289 ms

With GL_YIELD=NOTHING
[build] use-vbo=false: FPS: 3348 FrameTime: 0.299 ms
[build] use-vbo=true: FPS: 3530 FrameTime: 0.283 ms

The only issue I saw with my parameter is on the way an X11 client will
refresh its windows: you could see some part that are updated a bit slower
than other. But when you play with FGFS, do you really care about others X
client ? )

2) GLShaderDiskCache + GLShaderDiskCachePath
They work together. The 1st indicates to compile any shaders your app will
use at runtime once and for all. So, if your app use the same shader,
the GPU don't have to compile it over again and again.
This really improve your performance.
GLShaderDiskCachePath indicate where to put the files, eg
/home/ETisMyName/.nv/GLCache
Notice that you could see some lags during the 1st minutes you play FG,
then they disappears.

3) GLThreadedOptimizationss=true.
Not sure if this is relevant to FGFS. But I don't see any regression with it, so I keep it.

II - Flightgear tweaks
- I tried to use the multithreading support on FG, but it doesn't work at all
for me (and yes, FG was compiled with pthread).
You can try the 3 values (see inside preferences.xml) eg:
Flightgear Root/preferences.xml:
<multithreading-mode>AutomaticSelection</multithreading-mode>

IMHO, FG don't really use multithreading. I still don't understand why FG
don't use the full cpupower you could have. In most case, it is single
threaded (and so use only one cpu thread). If someone knows the reasons ..

III - X11 Window Manager.
IMHO, the best for a day to day use is ... the legacy Compiz-0.8. Every bench I launched on it are far better than other WM featuring a compositor (or like compiz, using OpenGL)
But for FG, the best is probably Openbox, or some other lightweight wm, w/o any compositor of course.
Whatever WM you use, disable the compositor. Kill compton or xcompmgr, disable XFCE compositor, or simply change your WindowManager.
In fact, GL score are from 100% to 200% better without any compositor.
Try to avoid Firefox too during you play session, html5/x264/coffeeMaker could really decrease some precious GPU clock.

That's all folks !
oÔ

I hope this will help you,

Happy new year

Valéry

[IAHM-COL]

Afaik, FG is not coded to use multithread, but there is a launch parameter to kind of use some of it. As you pointed above I also never seen a major improvement or multiple core performance with fgfs.

Some time I do see major RAM usage, maybe leakage.

[valery]

so it is. Really weird. The FG team announce proudly they now use C++11, but the core don't support multithreading. C++11 for what ? Heavy meta-programing ? I don't think so, perhaps some use of garbage collector features (smart_ptr), but still no threading at all. It's a pity because a major improvment of C++11 is its multithreading library. Perhaps the team will use it next time ... next release.
It seems that Simgear is not updated at all since 2008, and if you put your hands in the sources, it is difficult to find out a clear split between the rendering engines: ALS or Rembrandt seems to be the same engine featuring different way to render things. IMHO ... very quickly at first view ...

Well, it could be interesting to think about a fork, getting the best and leaving the rest. And of course, there's a lot of best things.
But FGFS suffers of an unfriendly team, I think that some guys in this team wan't to see anybody else improve - or even think about - the simulator.
Some with good C/C++ skills (and probably more time) are interested ?

Opened question..
CU
Val.

[IAHM-COL]

It certainly cruises my mind, but we had been shy of such task.

[valery]

but we had been shy of such task

The computer was invented exactly for that ! (and sometimes to compute the stars location too)


Perhaps could we start a list of wanted/unwanted things, eg:
- Only one rendering engine API for Aircraft !
- Photo realistic tiling support
- Friendly team
...
then seeing what matches our goals, what we keep or not.
Then finding out an OpenGL Windowing engine (I have some idea on this, like the Blender/Ghost layer I tried myself some times ago ..)
Then gathering a team
and so forth

Or perhaps nothing from above at all, just trying to do a fork with some improvment, and let see what happened.

[IAHM-COL]

My wish list:

1. Multicore/multithread of FGFS core
2. Python support as an alternative to Nasal for OOO procedural programming
3. Change of graphics rendering out of the ugly OpenSceneGraph (there are a couple of viable GPL alternatives once I had in mind. Need to re-research)
4. A reworked launcher in Java or GTK, able to better interact with FGMEMBERS and give better control of properties to the user. This being more FGRUN-like.
5. walk away of PLib dependencies (I believe the cores are already doing this as well)
6. Solve the rembrandt/ALS issue (I dont' think these are really that incompatible except by design -- intentionally made incompatible by Thorsten Renk)
Anyhow, ultimately the software would look so much better if both features could be simmultaneously on.
7. Catch and kill memory hogs
8. Improve multiplayer plattform (many goals needed here)

9. Air Combat capabilities !

[IAHM-COL]

but we had been shy of such task

The computer was invented exactly for that ! (and sometimes to compute the stars location too)

You misunderstood me.
I dont mean that FG would be hard to compute / calculate

Instead I mean its a lot of work to program, correct the bugs, and maintain.

That is real work that a computer can't make. FG-fork would not be able to program itself.

IH-COL

[jwocky]

I am more of a Java programmer, and one with very little time too, but I looked at the whole project under this angle already. The problem is, there is a lot "organic" grown source code and issues with compatibilities with older versions, hundreds of years old aircraft and so on. To bring order in this, it could mean to actually rewrite some big parts of it.
However, I didn't follow up on the idea to base some parts on Java because I lacked the time, but for my feeling, it would make at least the maintaining of three platforms (Windows, Linux, Mac) a lot easier and more stable. And Java in some of the surface parts would also reduce the always popular segment faults because, well, Java has smart pointer since like forever. But then, I am not a graphic guy, so, wioth all of this 3D stuff, I left my usual stomping grounds far behind and got so lost.

[valery]

@IHAM
I'm not very clever in communication .. I was meaning "computer were invented for the shy guys" ...
as you see, not clever at all.

Anyway, it's effectively a real work, perhaps I will come back here with more material/demo ..

@jwocky: good to know ; but I'm not sure Java is well designed for OpenGL. The only library I know is the Jogamp/Jogl one, and I'm not sure it's enough for good performance. IMHO of course; You're right, Java is more easy to maintain on the 3 platform, but see how Blender do the task, full OpenGL on the 3 platforms, and working very well. They avoid Glut a long time ago and build their own low-rendering layer: Ghost.
If you have time, try to compile some Ghost's unit-tests that you can find inside the source tree, very impressive. Take an eye inside the source and you will see a very well designed, very easy to read program. Platform specification are done at compile time: abstract class + instanciation at compile time. Very clean work.
Other engine that could be very interesting to explore/study is the Doom3 engine that is Opensource now.

But as IHAM said, whatever you do, it's a very hard work, sure.

Thanks

Cu
Val

[IAHM-COL]

on the positive side, given that FG is GPL, clearly we can hog as much of the functioning code there to begin with.
On the negative side, I have no training to do this kind of task at all.