Board index FlightGear Support Compiling

FG on the Jetson Nano?

Building FlightGear from source, and in the need for help?

FG on the Jetson Nano?

Postby jharris1993 » Wed Jul 08, 2020 10:48 pm

Ref:
There appears to be a few threads about FG on the Pi, such as the one here:
https://forum.flightgear.org/viewtopic.php?f=45&t=36922

Has anyone tried anything like this on the Jetson Nano? It would be interesting to see how well FG would do on a small system that is (supposedly) designed for graphically intensive applications.

<Note>
Though the Nano might be an interesting platform for FG, I thought it would be a bit on the bizarre side, until I saw that someone else was doing this on a Pi of all things! At least the original poster was trying this on a Pi-4, not a Zero. :roll: :wink:

Now I'm really interested in seeing if this is doable.
</Note>

Like the original poster, I'm not exactly a programming guru, but I do know where the "Any" key is located and I generally can find the top side of the keyboard, especially if the lights are on! :wink:

Since it's been done on the Pi, it "should be", (famous last words!), doable on something like the Nano whose OS is based on Ubuntu. So, what should I read/do to get started on something like this?

Thanks!
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 155
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-10/ Linux MInt

Re: FG on the Jetson Nano?

Postby jharris1993 » Fri Jul 10, 2020 2:04 pm

Update:

I found a number of articles on "Building FlightGear", some discussing more "normal" builds and others talking about building on ARM based systems like the Pi.

Since there are significant "gotchas", especially when building onto a system that is materially different from the existing standard systems, I suspect it will be a bit experimental, not unlike adapting a recipe. You throw a bunch of stuff into the pot, light the flame underneath, stir, and hope that you have something edible once it's done.
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 155
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-10/ Linux MInt

Re: FG on the Jetson Nano?

Postby Hooray » Fri Jul 10, 2020 2:35 pm

You could get started by posting the specs of the system in question :wink:

Speaking in general, you'll want working OpenGL support (hardware accelerated, at least 1gb of dedicated VRAM), 3-4 cores (>= 1 ghz), and 4-8gb of RAM.

Absent that, things will become pretty interesting quickly - as they may involve cross-compiling FG, and only being able to run a subset of FG itself
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: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: FG on the Jetson Nano?

Postby jharris1993 » Fri Jul 10, 2020 3:19 pm

Hooray wrote in Fri Jul 10, 2020 2:35 pm:You could get started by posting the specs of the system in question :wink:


Silly me. . . .

Most of my recent time has been spent in the robotics maker space and, (not unlike the Raspberry Pi), the "Jetson Nano" (actually the small dev kit that includes the Jetson Nano board itself), is pretty self-defining. I forgot that not everyone is spending their spare time trying to develop The Next Big Thing In Robotics, so the 'Nano may not be generally well known.

Viz.: NVIDIA's site for the 'Nano.
https://developer.nvidia.com/embedded/j ... eloper-kit

It is an ARM based system with a large handful of cores, and is specifically designed for people who want to use a zillion or so CUDA-like rendering pipelines for AI research or graphics.

Viz.:
(These are the specs for the 'Nano board itself, taken directly from the Ninvidia Jets Nano site referenced above)
* GPU: 128-core Maxwell
* CPU: Quad-core ARM A57 @ 1.43 GHz
* Memory: 4 GB 64-bit LPDDR4 25.6 GB/s
* Storage: microSD (not included)
(It can be run from an attached USB hard drive/SSD similarly to the way it can be done with a Raspberry Pi.
* Video Encode: 4K @ 30 | 4x 1080p @ 30 | 9x 720p @ 30 (H.264/H.265)
* Video Decode: 4K @ 60 | 2x 4K @ 30 | 8x 1080p @ 30 | 18x 720p @ 30 (H.264/H.265)
* Camera: 2x MIPI CSI-2 DPHY lanes
(Note that this is true for the second-generation development carrier board only. The original, which is the one I have, has one camera port.)
* Connectivity: Gigabit Ethernet, [and a] M.2 Key E [slot for a wireless card is located under the Jetson Nano board itself.]
* Display: HDMI and display port
* USB: 4x USB 3.0, USB 2.0 Micro-B
* Others: GPIO, I2C, I2S, SPI, UART
(The GPIO pins are set to match the Raspberry Pi GPIO pinout so that Raspberry Pi daughter boards will fit.)
* Mechanical: 69 mm x 45 mm, 260-pin edge connector.
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 155
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-10/ Linux MInt

Re: FG on the Jetson Nano?

Postby Hooray » Fri Jul 10, 2020 3:46 pm

Ok, thank you.

With just 4gb, RAM seems a bit on the low end for a "stock" fgfs build.
Also, the website mentions OpenGL 4.5, OpenGL ES 3.2 and Vulkan 1.0.2: https://docs.nvidia.com/jetson/l4t/inde ... ID0E0BB0HA

Neither of these are currently supported/targeted by FlightGear, so that FlightGear certainly isn't optimized to make use of this kind of hardware.
Thus, it seems likely that only a subset of FlightGear should be built/used on that hardware (i.e. minus legacy OpenGL stuff)

Apart from that, the specs look actually rather compelling, but a number of people using the nano actually mentioned cross-compiling on a more powerful platform, i.e. so that you use your powerful PC (with plenty of cores and RAM) to build binaries for the nano.

Speaking in general, it would make sense for people with similar hardware (Pi, Nano etc) to team up and define a safe subset of features to make legacy code optional, so that it can be excluded during compilation - that would possibly include stuff like the 2D panels code, the legacy HUD and the PUI UI.

In fact, the most proper way to tackle a "port", would actually be a headless build, i.e. with all the graphics stuff excluded for starters: http://wiki.flightgear.org/FlightGear_Headless

Having a team of contributors who are interested in retargeting FlightGear onto embedded hardware could be pretty cool for the project, too - because many performance issues that may only show up after hours of running fgfs, will show up much earlier (or much more prominently) on such constrained hardware.

If you can find others able to use git and scripted compilation, that could actually become the foundation for such an "embedded fgfs" effort - and that would be valuable regardless of the specific platform, i.e. because there are common requirements that would good to aim for - such as using OpenGL ES and disabling legacy stuff:

http://wiki.flightgear.org/Howto:Build_ ... berry_Pi_4
http://wiki.flightgear.org/FlightGear_and_OpenGL_ES
http://wiki.flightgear.org/Howto:Optimi ... le_devices

A corresponding OpenGL ES enabled fgfs build could also become the foundation for a future Vulkan port: http://wiki.flightgear.org/Vulkan_Scene_Graph
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: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: FG on the Jetson Nano?

Postby Johan G » Fri Jul 10, 2020 5:05 pm

I guess I am the only one who look at a device like that, compare it to my computer and sighs (look at the Windows box in my profile...). :|
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5775
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: FG on the Jetson Nano?

Postby Hooray » Fri Jul 10, 2020 5:23 pm

People with access to older hardware would actually seem to be in a good position to team up with people interested in running a subset of fgfs on embedded platforms, since the kind of required refactorings/patching would also benefit them, i.e. by helping identify a tiny subset of FG that such hardware can accommodate, while providing an option to make more and more bits (subsystems) optional and the remaining ones better configurable at startup/runtime: http://wiki.flightgear.org/FlightGear_and_old_Hardware

The headless option would remain interesting, while it will obviously not provide any graphics "as is", it will help people wanting to identify/troubleshoot and understand performance issues: http://wiki.flightgear.org/FlightGear_Headless

And having such a headless option, will also make it much easier to actually profile/benchmark FlightGear (parts of it) to increasingly optimize those - so that we can come up with a benchmark using FlightGear itself, and use the corresponding infrastructure to implement dynamic feature scaling support for less powerful systems.

http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Feature_Scaling

Admittedly, 2gb of total RAM is fairly low, especially on a platform like Windows - but it isn't far-fetched to run a subset of fgfs on such hardware, even a recent version using the minimal startup profile:

http://wiki.flightgear.org/Minimal_Startup_Profile
Image

Note that the screen shot was taken on a notebook from around ~2007:
Image

In other words, people interested in running FlightGear on older PCs are basically in an excellent position to team up with folks interested in targeting embedded platforms, and that also applies to mobile platforms (think android phones/tablets), but also dedicated gaming consoles. From a software engineering standpoint, the work that lies ahead to make things build/work, is pretty much the same.

And in fact, having access to a headless startup mode would also mean that it may become much easier to distribute fgfs sessions across multiple threads/cores or machines, which is touching on the whole HLA/RTI idea: http://wiki.flightgear.org/High-Level_Architecture

And that's in fact one of the reasons, why I suggested to introduce a dedicated wiki portal for people interested in such embedded development: http://wiki.flightgear.org/FlightGear_wiki:Village_pump
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: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: FG on the Jetson Nano?

Postby xcvb » Sat Jul 11, 2020 8:06 am

Some years ago I tried FG on the Jetson TK1. The performance was ok for my favorite aircraft tu154b in low density areas and without vegitation. The only minor problem was that FG complained that I needed to update my driver, but the L4T drivers have different version numbers.
xcvb
 
Posts: 116
Joined: Sat Mar 14, 2015 2:08 pm
Version: GIT
OS: Linux

Re: FG on the Jetson Nano?

Postby jharris1993 » Sat Jul 11, 2020 6:18 pm

Hooray wrote in Fri Jul 10, 2020 2:35 pm:In fact, the most proper way to tackle a "port", would actually be a headless build. . . .


A headless build for FlightGear? Seems kinda' counter-productive, unless you're REALLY serious about your instrument rating! :lol:
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 155
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-10/ Linux MInt

Re: FG on the Jetson Nano?

Postby jharris1993 » Sat Jul 11, 2020 7:38 pm

Boy, it sure looks like I really kicked over an ant-hill with this question, 'eh?

Hooray wrote in Fri Jul 10, 2020 3:46 pm:Speaking in general, it would make sense for people with similar hardware (Pi, Nano etc) to team up and define a safe subset of features to make legacy code optional, so that it can be excluded during compilation - that would possibly include stuff like the 2D panels code, the legacy HUD and the PUI UI.

In fact, the most proper way to tackle a "port", would actually be a headless build, i.e. with all the graphics stuff excluded for starters: http://wiki.flightgear.org/FlightGear_Headless

Having a team of contributors who are interested in retargeting FlightGear onto embedded hardware could be pretty cool for the project, too - because many performance issues that may only show up after hours of running fgfs, will show up much earlier (or much more prominently) on such constrained hardware.


Perhaps there could be a specific sub-forum for the embedded hardware crowd?

Hooray talked about a dedicated Wiki section - all good - but I think a separate forum space will attract more attention more rapidly as people tend to look in the support fora first. (At least that's what I do.)

One thought I had when I was thinking about running FG on the 'Nano was the advanced, and dedicated, graphics hardware on the 'Nano.

Unlike a "normal" system, I thought that running FG on the 'Nano would provide access to the advanced hardware without all the competition found in a larger system. In essence an "embedded" FG install, on a system that (might) be able to pull it off.

Not that I am advocating a "FG game system", but it seemed to me that a system built for and only running FG, would be able to do many wonderful things without a huge hardware expense on super-advanced graphics, processors, and memory.

Here's a thought that is the conjunction of "headless" and "embedded":

Maybe later on when the dust has settled, (and perhaps after a total refactor of the FG code has been done), various parts of the FG functionality could be loaded and run on a number of networked modules - AKA a FlightGear Cluster.

I can easily see someone creating functional hardware modules that each provide some small, and easily configured, part of the entirety of the FG experience. Want more 4k-HD monitors? Add a few more 'Nanos, each one exclusively responsible for it's own share of the whole display task. Meanwhile the small module that is responsible for Just-In-Time terrain loading doesn't have to worry about who's going to render what part of what section.

This could get REALLY interesting and REALLY hairy, REALLY quickly!

====================

One thing needs clarifying:

Hooray wrote in Fri Jul 10, 2020 3:46 pm:. . . people with similar hardware (Pi, Nano etc)


When you're looking at the embedded hardware crowd, "embedded", (even if using the same basic processor family), is not even close to "similar".

Even clones of the exact same hardware can be vastly different depending on who did the cloning. (i.e. "Original" Arduino, SparkFun, Seeed Studios, Vellman, etc.)

Virtually every embedded system out there is based on a very specific, (and highly customized), system-on-a-chip that was designed and manufactured to present a very specific use-case to the world.

In the case of the Pi, it was/is designed to be a very inexpensive, (< $50 USD), makerspace computer that would run a "real" O/S, instead of being low-level programmed like the Arduino.

The 'Nano is intended for those who are exploring robotics and AI, who have outgrown their 'Pi based systems and 'bots, who want advanced "CUDA-core like" programmable rendering pipelines that can be used for more advanced processing, and still have a 'Pi-compatible GPIO header and a relatively small physical footprint.

That these disparate systems can be used for something like FG is a tribute to the ingenious people who absolutely insist on getting that dad-gummed square peg into that pesky round hole.

All good, but be careful. These systems are not nearly as "similar" as you may think.

Maybe this is what should be etched into the bottom of the mirror:

Warning! Differences are larger than they appear!
:lol:
Last edited by jharris1993 on Sat Jul 11, 2020 8:01 pm, edited 1 time in total.
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 155
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-10/ Linux MInt

Re: FG on the Jetson Nano?

Postby Hooray » Sat Jul 11, 2020 8:00 pm

I appreciate your comments (and your humor in the preceding posting), but the point was not that such targets are "similar" in the technical sense, but that the kind of refactoring work needed to make fgfs on such hardware would indeed be "similar" - regardless if the hardware has 2 cores, 4 cores or 8 cores - and regardless if the hardware has got 2gb of RAM, 4 gb or more. Likewise, OpenGL support is likely to be constrained, too - regardless of the underlying platform, OpenGL ES (or OpenGL core profile) would be the lowest hanging fruit probably.

So this was not about failing to recognize that embedded hardware may indeed differ hugely, but it was about recognizing that the underlying work to retarget fgfs itself is indeed very much similar.

Otherwise we could just as well talk about different processor instruction sets, RTOS etc - but that wasn't the point, when tackling something like this, you need to walk before you can run. Which is exactly the reason why I mentioned the "headless" option, too - building just a subset of fgfs (e.g. the non-graphical portion) can already go a long way to retarget certain parts of fgfs.

Realistically though, hardware has been catching up rapidly, end users able to run a recent fgfs version on the RPi are a testimony to that - but people wanting to run fgfs on platforms like tablets/phones, will still need to make certain changes (think OpenGL ES)
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: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: FG on the Jetson Nano?

Postby jharris1993 » Sat Jul 11, 2020 8:10 pm

Hooray wrote in Sat Jul 11, 2020 8:00 pm:I appreciate your comments (and your humor in the preceding posting), but the point was not that such targets are "similar" in the technical sense, but that the kind of refactoring work needed to make fgfs on such hardware would indeed be "similar"


Dawggonnit! Where's the "like" button?

Anyone who can make me spit tea laughing and impress me with their logic and common sense at the same time deserves a "like"!
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 155
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-10/ Linux MInt

Re: FG on the Jetson Nano?

Postby Hooray » Sat Jul 11, 2020 8:43 pm

I do understand that most people would not really consider a "headless" fgfs version particularly "useful" - on the other hand, this all boils down to "feature scaling", i.e. being able to configure if, and how, certain subsystems are to be executed, and then scale defaults on demand.

To some extent this is already possible, what's missing is an XML configurable "boot sequence", so that some hard-coded dependencies (subsystems) can be more easily removed/tweaked.

Right now, there is roughly ~20 subsystems which are added in a hard-coded fashion - however, there's the reset/re-init effort, and the subsystem factory to dynamically remove/re-init and re-add subsystems.

People interested in running fgfs on embedded hardware could look at that code to come up with an XML configurable initialization sequence - which is actually in line with some of the cppunit work that James and Edward have been doing lately, because they also needed a way to only run a subset/portion of fgfs to test certain subsystems in isolation, while also encoding subsystem dependencies.

Realistically, such work will include an option to disable the loading of scenery/terrain and aircraft models entirely, until the "core" works well enough.
And then, it's likely that only certain locations/airports and aircraft will actually work well enough.
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: 11835
Joined: Tue Mar 25, 2008 8:40 am


Return to Compiling

Who is online

Users browsing this forum: No registered users and 1 guest