OpenCPN Runs on Embedded ARM

[bdbcat]

NahanniV...

Can you point me to some screen shots of incorrect vector chart area rendering? Maybe I can reproduce this and take a look at it.

Also, I echo Sean in the general case....

What we want to achieve is this: If you can run glesgears, or something like it, at acceptable frame rate, then the current O github master should find the hardware accelerated gles libraries, and include the glshim layer (and friends) automatically in the build. If the current github build does not do that, we need to fix it. There should be very little need for hand-crafting of the build for a particular platform, assuming a standard gcc build environment.

If your glesgears runs slow, for whatever reason, then O will run slow. Simple as that.

If it looks like there will not be a fast hardware implementation of GLES for your favorite platform, by all means switch platforms. These things are cheap enough to throw away if they become too frustrating...

Performance wise, I'm getting acceptable performance on US$35 generic android tablets, so there is no good reason to struggle with a dead-end platform unless you are a true kernel hacker living on 50 watts of solar.

No one has all of the possible alternative arm platforms in one place, so we we need broad testing and careful feedback/documentation to be sure we are covering the desired target. Keep it coming.

Thanks
Dave

[NahanniV]

Originally Posted by boat_alexandra

So you can confirm you didn't have to really do anything special to get good acceleration or deal with glshim correct?

Correct, the build and install worked perfectly, much simpler, but the functionality is the same as V4.0.

Thanks,
JM.

[NahanniV]

Originally Posted by bdbcat

NahanniV...

Can you point me to some screen shots of incorrect vector chart area rendering? Maybe I can reproduce this and take a look at it.

Also, I echo Sean in the general case....

What we want to achieve is this: If you can run glesgears, or something like it, at acceptable frame rate, then the current O github master should find the hardware accelerated gles libraries, and include the glshim layer (and friends) automatically in the build. If the current github build does not do that, we need to fix it. There should be very little need for hand-crafting of the build for a particular platform, assuming a standard gcc build environment.

If your glesgears runs slow, for whatever reason, then O will run slow. Simple as that.

If it looks like there will not be a fast hardware implementation of GLES for your favorite platform, by all means switch platforms. These things are cheap enough to throw away if they become too frustrating...

Performance wise, I'm getting acceptable performance on US$35 generic android tablets, so there is no good reason to struggle with a dead-end platform unless you are a true kernel hacker living on 50 watts of solar.

No one has all of the possible alternative arm platforms in one place, so we we need broad testing and careful feedback/documentation to be sure we are covering the desired target. Keep it coming.

Thanks
Dave

The build, installation, and frame rate are fine, but there is some problem with rendering of vector charts.

It seems to be related to certain features: disabling: dredged areas, Quality Of Data, Unsurveyed Area, and Shoreline Constructions seems to help.

Here is a link to a conversation earlier in this thread discussing the problem:
http://www.cruisersforum.com/forums/...ml#post1731437

I'm using the latest C-Map files and the bridge in the video is at:
43 17.9088 N 079 47.7904 W

The problem only happens with OpenGL enabled on the CubieTruck. In this case it seems to be the Dredged Areas causing the problem, if the Display Catagory has them disabled all is well.

I have also seen similar problems with US Vector charts and Netherlands Vector Charts were other features caused problems.

I am happy enough with raster chart performance on this platform that I plan to use it this summer on my boat regardless of the vector chart problems. Perhaps next winter I'll look for something else.

Thanks again for all your efforts,
JM.

[seandepagnier]

Originally Posted by bdbcat

NahanniV...

Can you point me to some screen shots of incorrect vector chart area rendering? Maybe I can reproduce this and take a look at it.

Please give specific locations for the charts and which charts.

What we want to achieve is this: If you can run glesgears, or something like it, at acceptable frame rate, then the current O github master should find the hardware

The program is es2gears.

Maybe we should build into cmake to run glxinfo and if direct rendering, use that, if not, then try es2_info and if direct rendering, then use that. If neither work, then revert back to opengl (software)

Performance wise, I'm getting acceptable performance on US$35 generic android tablets, so there is no good reason to struggle with a dead-end platform unless you are a true kernel hacker living on 50 watts of solar.

Which tablet are you using that costs $35? What about smart phones?

I have 200 watts of solar, so power isn't my issue, it's the ability to actually get new platforms. I can't just go buy a tablet here, local people don't use them, in fact very few people use computers at all. In a larger city maybe but I'm a long way from there. As for mail ordering.. forget it, it's going to cost $35 for the device and $80 to ship it.

It's in our interest to support as many devices as possible within reason. In a few years, I suspect opencpn capable devices will cost around $5. Also considering the popularity of the raspberry pi, it would be good to support because they will be around for a long time to come.

[sea-bee]

Originally Posted by bdbcat

... acceptable performance on US$35 generic android tablets...

How are you running O under Android? Linux emulator?

[bdbcat]

sea-bee....

We are in very early pre-alpha testing of O on android.
More work to do, but we expect some more public alpha testing will start shortly.

Here is one low end android gizmo that I've tested on:
Irulu 7" Google Android 4 1 Capacitive Tablet PC Dual Cameras 8GB 1 2GHz WiFi | eBay

Better if it had 1 GB of RAM, but not bad with 512MB.

Dave

[NahanniV]

Originally Posted by boat_alexandra

Please give specific locations for the charts and which charts.
......

We have discussed this problem before.

Here are some instances to refresh your memory:

1. CM93 latest files.
   Discussion:
   http://www.cruisersforum.com/forums/...ml#post1731437
   The bridge in the video is at:
   43 17.9088 N 079 47.7904 W
   
2. Dutch ENC charts. Free download:ENC - Fairway Information Services
   Discussion:
   http://www.cruisersforum.com/forums/...ml#post1744124
   51 35.6626 N 003 36.9273 E

It looks to me like the problem is either in GLSHIM or something below that like the drivers on the CubieTruck.
I'll be interested to hear if BDBCAT has the same problem with his android version.

Cheers,
JM.

[bdbcat]

NahanniV...

Yep, I see the trouble with the dredged area it at certain cm93 scales.

On the list....

Dave

[mrm]

Originally Posted by Aikiguy

I was shocked to learn in my research though that linux does not as an operating system deal well with multiple core processors. This means that if you use OpenGLES, and OpenCPN, you are going to use ONLY ONE of your processor cores. So in effect you get slower charting with opengles, because one processor core is now running a software emulator for opengl, and the opencpn program. It is a substantial hit to usability especially with vector charts. Apparently to use multiple cores in Linux the program must be written so that it manages the core usage instead of this being done by the operating system.

Sorry, but you seem to be very confused or have zero knowledge about parallel programming. It is always a responsibility of a programmer to write code to utilise multiple cores. The operating system provides supporting mechanisms and abstractions (threads / processes interface, semaphores, mutexes, barriers, shared memory, IPC etc.) but if program code is not written with the intent of utilising available hardware fully, operating system (be it Linux, Windows, whatever) will not help. The best an operating system can do when multiple cores are available but applications are written with a single core model in mind is to assign different processes to different cores.

Let me repeat: if you want to use multiple cores in your program write appropriate code for that. No operating system (in common use, forget university research) is going to do it for you.

[seandepagnier]

Yes, but even programs with only 1 thread often benefit because the OS, drivers, etc.. run on a different core. Also there are typically on linux, X (which uses cpu) and gpsd (which uses a lot more cpu than it should). To fully utilize all the cores, the program must use threads or more than one process.

[seandepagnier]

Originally Posted by bdbcat

Better if it had 1 GB of RAM, but not bad with 512MB.

Dave

Are you using swap space? At least for raster charts the ram requirement should be really low with the compressed cache, but maybe vector charts use a lot? Perhaps it should purge vector tiles that are far away more frequently as I notice the ram requirement just grows as I look at more areas.

[bdbcat]

Sean...

The memory requirement is particular to android. android does not use swap at all. By the time the 'droid UI and support stuff is running, there are precious little resources (RAM and CPU cycles) available to an app like O.

Memory gets tight, even when O is using only say 80-90 MB of memory, including compressed textures. android then starts shutting down inactive apps/services (like the always running google location services, google Store, etc.), doing some slow java garbage collection, and then trying to restart the killed services. The whole process bogs down, and eventually O gets OOM-killed.

Much nicer with modern 1 GB 'phone.

Dave

[CarinaPDX]

Originally Posted by boat_alexandra

gpsd (which uses a lot more cpu than it should)

Eh? My brother is a gpsd dev, and on his rpi2 it is using <0.1% of the processor and 0.2% of the RAM. I don't think that is "a lot more cpu than it should". (This is with v3.15-dev, but 3.14 stable is OK.)

You should probably look elsewhere for CPU savings...

Greg

[seandepagnier]

This is on a chromebook c720p. It's about 10 times faster than a raspberry pi.

Using gpsd 3.9 I am getting cpu usage of 4% for gps when either cgps, opencpn, or both are running. There is no cpu usage when these programs are not running.

[CarinaPDX]

You should consider updating to v3.14 or even 3.15-dev; 3.9 is about 2 years old, which is pretty long in the tooth for such software - it is still under active development. You should see an improvement. FWIW Debian does have an old version, so anyone using Debian and gpsd should update gpsd to current.

Greg