Compilation Question, Driver Version Weirdness, Any CMake Gurus Here?

Greetings,

After about a week of very hit-or-miss but steady efforts, I have managed to compile and run the project FlightGear (see flightgear.org for more details if you like flight simulators). This has a lot of dependencies on specialty packages which also have a lot of dependencies on packages available through apt-get (“trusty” “universe”, mostly).

For the build: See also
https://www.google.com/search?client=ubuntu&channel=fs&q=building+debian+flightgear&ie=utf-8&oe=utf-8
http://wiki.flightgear.org/Building_FlightGear_-_Debian

Dependency “plib” is available as “plib-dev” via apt-get. Other dependencies and prerequisites not mentioned on the build page include Computational Geometry Algorithm Libraries from
https://www.cgal.org/
LibBoost etc etc all available from apt-get and many pre-built binaries can be installed by running apt-get build-dep libopenscenegraph-dev ; apt-get -b source libopenscenegraph. The build will die but you will get all of the required dependencies installed.

OpenSceneGraph “OSG” is available as source from the developers as a bleeding-edge ‘git’ pull version 3.3.1, but compilation was successful only after installing both QT4 and QT5 and letting the compiler pick what it wanted to use. I am still uncertain how this managed to compile; I was half asleep when I did it. Pure QT4 and stable version 3.2.0 could not be made to compile, bombing out very repeatedly over a known issue in QT.

Satisfying “OSG” allowed further compilations to go forward, and I was able to build FlightGear.

Here’s the problem. It all works, the graphics are every bit as beautiful as you might hope, the world rendered around the pilot’s view is highly detailed and very lovely etc etc. But it is Dead Slow. The simulator itself works well, but the display frame rate for updates is about 2 to 5 seconds. At least. This won’t do.

At start-up, the xterm launching the application shows these error messages:

~$ bin/fgfs --fg-root=/usr/local/flightgear/fgdata
Enabling ATI viewport hack
Outdated graphics drivers:FlightGear has detected outdated drivers for your graphics card.
(Please upgrade to at least version 300 of the nVidia drivers (installed version is 19.2))

The version number 19.2 is a result returned by glxinfo |grep NVIDIA

This is being executed with LD_LIBRARY_PATH="/usr/local/cuda-6.0/lib:/usr/local/cuda-6.0/targets/armv7-linux-gnueabihf/lib/:/usr/local/flightgear/lib"

Question 1. How can I convince the application that there’s a version 300+ NVIDIA driver so that it won’t fall back to a straight VGA/XGA non-hardware-accelerated display mode?

Question 2. in case there aren’t ways to force this thing to use the NVIDIA drivers without re-compiling, are there any CMAKE Gurus here, or would anyone recommend an authoritative resource online?

Question 3. Should I just go read the CUDA docs because my answer is likely there?

Thanks in advance,

Just to clarify… you were able to build FG already? I’m trying to find the relevance of Question 2? Otherwise it might actually be easiest to try to find that error string in the FG source code and hard-code the version string there to 331-something or whatever and recompile and see if it runs any better.

I did do a strings grep check of the fgfs binary (an older version, 2.4) and didn’t find any references to nvidia. Maybe it’s in one of the libs?

To clarify: yes, I was able to build FG. It was not easy to get past compiling OpenSceneGraph. I seem to recall that I had to go into the subdirectory where the compiled died, and make Foo.i, make Foo.s and make Foo.o directly, the Makefile had those options. Once that was done, the subsystem completed compiling and could be installed.

Try glxinfo |grep OpenGL and you’ll see that the driver version is 19,2, presumably to match the Linux-for-Tegra version. I suppose I can try to hunt down the code where they check for version number and just disable it for now, and hope that because there’s a working OpenGL here, it will just work with what it has. It depends on the code in there, I have not yet looked at it, it may have totally different approaches to handling different driver versions.

Updating: there is a project called “osgCompute” which claims to support a much earlier version of CUDA, but that project hasn’t been updated since 2011 as best I can tell. The OSG forums are not particularly helpful either.

I had suggested elsewhere here on this forum that perhaps I needed to specify to cmake that it should use certain libraries, someone suggested that this wasn’t necessary because the usual GL-ish libraries would automatically link to the CUDA-associated GL-ish libraries. But thus far it doesn’t seem to be the case… or perhaps there’s not much in the OSG or FG code that lends itself to CUDA parallel processing. For now I will explore the idea that FG is not seeing the NVIDIA OpenGL version string as sufficient, and simply passes all rendering to the CPU rather than even trying the GPU. That seems most likely for now, as they are known to support a lot of NVIDIA and Radion cards. I guess I should send them mail. ;-)

Thanks,

UPDATE PROBLEM SOLVED

First, edited the source so that the simulator recognizes that there is an OpenGL with hardware acceleration. Accomplished in $FG_SOURCE_DIR/src/Main/main.cxx by changing value for minimal allowed driver version. Don’t change this unless compiling for Tegra For Linux on the Jetson. Recompiled and installed.

A lot of segmentation faults occurred, often after very jerky renderings and stuttering/jumping of simulation. Too much was running in swap. Killed the services “cups” and “cups-browsed”. For some reason those use a lot of memory and CPU. This helped a lot.

What finally got full-speed simulation with excellent rendering, in a window or fullscreen, was was follows:

echo $PATH="/usr/local/cuda-6.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/flightgear/bin"

echo $LD_LIBRARY_PATH="/usr/local/cuda-6.0/lib:/usr/local/cuda-6.0/targets/armv7-linux-gnueabihf/lib:/usr/local/flightgear/lib"

To get the program to run well, I always pass the command lines with LD_LIBRARY_PRELOAD, thus:

LD_LIBRARY_PRELOAD="/usr/lib/arm-linux-gnueabihf/tegra/libtegrav412.so:/usr/lib/arm-linux-gnueabihf/tegra/libcuda.so:/usr/lib/arm-linux-gnueabihf/tegra/libGL.so.1" bin/fgfs --fg-root=fgdata

If you are using a non-CUDA application that does otherwise use OpenGL/FreeGLUT you will probably want to force the use of the NVIDIA accelerated drivers by passing LD_LIBRARY_PRELOAD to the commandline. You could also export them to the environment but it’s probably best to call it from the commandline lest you get unexpected/unintended results.

Probably the lines you would use to export would be something like:

export LD_LIBRARY_PATH="/usr/local/cuda-6.0/lib:/usr/local/cuda-6.0/targets/armv7-linux-gnueabihf/lib:/usr/local/flightgear/lib:$LD_LIBRARY_PATH"

export PATH="/usr/local/cuda-6.0/bin:/usr/local/flightgear/bin:$PATH"

Regards,

Good job! Is it nice and smooth?

If my board ever ships and arrives I’ll be pulling down Doom 3 source code and having some fun myself. ;)

@jwcalla: Yes, it’s running very smoothly now. I’ve tried a lot of aircraft and sometimes it’s a bit jumpy at the final moments of approach. Then again, my hand on the joystick is a bit jumpy at the final moments of approach. “Your mileage may vary” as they say. Mostly I have been trying large-body aircraft models but will soon start testing performance models such as fighter models. That should at least give good testing stresses for the landscape rendering.

@ALL: I remember the days when a person would build a new computer, and on the first power-up, whether or not boot was successful, we’d leave it up for at least a few hours just to let the RAM become accustomed to being powered up in the new system. This may be somewhat superstitious but it hasn’t yet hurt anything. Additionally once a good boot was achieved, we tended to run the largest program we could find, for at least 24 hours, so as to “burn in” the RAM.

My observation is that having spent most of the day exercising the rendering engine (and presumably also the GPU and its memory), it does seem to be a lot less prone to error and I haven’t seen any segfaults in the last 12 hours of operation. “Burn in” may solve a lot of problems of erratic behavior. Load up the GPU and keep it busy for 24 hours and see if that makes things run better.

Regards, I am off to try to help the OpenSceneGraph package-maintainer for the armhf-ubuntu package, and then I think I will see if I can get BOINC[1] to build with the client able to use the GPU for high-speed parallel computing.

Cheers,

Ref: 1 http://boinc.berkeley.edu