OpenCPN Runs on Embedded ARM

[NahanniV]

Originally Posted by deltasig

JM, it's great to have you to bounce things off; thank you for your feedback.
I was looking at the CMakeLists.txt:

# Search for opengles, short of running a program to test the speed
# of acceleration, I simply use gles on "native linux" arm systems
IF (ARCH MATCHES "arm*" AND (NOT QT_ANDROID) )
find_path(OPENGLESv1_INCLUDE_DIR GLES/gl.h )
IF (OPENGLESv1_INCLUDE_DIR)
MESSAGE (STATUS "Found OpenGLESv1")
ADD_DEFINITIONS(-DocpnUSE_GLES)
ADD_DEFINITIONS(-DocpnUSE_GL)
ADD_DEFINITIONS(-DUSE_GLU_TESS)

SET(OPENGLES_FOUND "YES")
SET(OPENGL_FOUND "YES")

SET(wxWidgets_USE_LIBS ${wxWidgets_USE_LIBS} gl )
add_subdirectory(src/glshim)

add_subdirectory(src/glu)

SET(OPENGL_LIBRARIES "GL_static" "GLU_static" "EGL" "X11" "drm" "dri2" )
ENDIF()
ENDIF()

I see it is looking for OpenGLESv1 but I have v2 and the only places there is a GLES/gl.h is in
/home/orangepi/OpenCPN/src/glshim/include/GLES/gl.h and
/usr/include/khronos/GLES/gl.h

Here is khronos:
/usr/include/khronos/:
total 12
drwxrwxr-x 2 orangepi orangepi 4096 Dec 27 19:18 EGL
drwxrwxr-x 2 orangepi orangepi 4096 Dec 27 19:18 GLES
drwxrwxr-x 2 orangepi orangepi 4096 Dec 27 19:18 GLES2

/usr/include/khronos/EGL:
total 44
-rw-rw-r-- 1 orangepi orangepi 26187 Aug 5 2015 eglext.h
-rw-rw-r-- 1 orangepi orangepi 12353 Aug 5 2015 egl.h

/usr/include/khronos/GLES:
total 100
-rw-rw-r-- 1 orangepi orangepi 59377 Aug 5 2015 glext.h
-rw-rw-r-- 1 orangepi orangepi 34332 Aug 5 2015 gl.h
-rw-rw-r-- 1 orangepi orangepi 901 Aug 5 2015 glplatform.h

/usr/include/khronos/GLES2:
total 108
-rw-rw-r-- 1 orangepi orangepi 72782 Aug 5 2015 gl2ext.h
-rw-rw-r-- 1 orangepi orangepi 31871 Aug 5 2015 gl2.h
-rw-rw-r-- 1 orangepi orangepi 909 Aug 5 2015 gl2platform.h

Do you think I should change something in the CMakeLists.txt? I'm not very familiar with Cmake scripting but it doesn't look as if it's picking up what it needs, at least in my case.

The compile is at 50% after an hour, so I have a bit more to go before I see results.
BTW, with the ppa version of O, when I set OpenGL I was getting up to 6 FPS; the system was more responsive without it, though.

Nice screen!

Cheers
DS

Your .opencpn/opencpn.log file probably already shows that you are using a software OpenGL that is installed on your board; It would say something like "OpenGL -> Renderer String: Software Rasterizer". That's why it's slower.

I'm also not familiar with the Cmake scripting. You could try just forcing OpenGLES1 on, I don't know if it will work, probably have to delete or clean your build directory to get it to rebuild.

You will see the performance improvement when you get the hardware acceleration to work, it's quite dramatic for raster charts; You can also check the OpenCPN log file to see that the OpenGL -> Renderer String: has changed to Mali-400 MP.

Also, try make -j5 to keep all your cores busy and speed up the build.

Cheers,
JM.

[deltasig]

Back with the log starting from the Education menu:
13:02:42 EST: OpenGL-> Renderer String: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
13:02:42 EST: OpenGL-> Version reported: 3.0 Mesa 11.0.2
13:02:42 EST: OpenGL-> Texture rectangle format: de1
13:02:42 EST: OpenGL-> Using Vertexbuffer Objects
13:02:42 EST: OpenGL-> Using Framebuffer Objects
13:02:42 EST: OpenGL-> Using FBO Stencil buffer
13:02:42 EST: OpenGL-> Using Stencil buffer clipping
13:02:42 EST: OpenGL-> Using Scissor Clipping
13:02:42 EST: OpenGL-> Not Using compression
13:02:42 EST: OpenGL-> Minimum cartographic line width: 1.0
13:02:42 EST: OpenGL-> Minimum symbol line width: 1.0

No idea what that is. Have not got any maps loaded to see the response.

Starting from CLI:
Gtk-Message: Failed to load module "atk-bridge"
libGL error: unable to load driver: mali_drm_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: mali_drm

Then the ALSA lib messages follow

The interesting thing is that it does look for the mali driver but it does not find it although it is loaded:
orangepi@OrangePI:~$ lsmod
Module Size Used by
8188eu 915632 0
cdc_acm 15103 2
sunxi_ir_rx 6793 0
sunxi_gpiokey 2124 0
gpio_sunxi 8233 0
8189es 901572 0
mali_drm 6634 4
drm 180399 5 mali_drm
mali 211448 15
ump 40421 9 mali

Is it a matter of specifying any env variables at start up?

Thank you
DS

[NahanniV]

Originally Posted by deltasig

Back with the log starting from the Education menu:
13:02:42 EST: OpenGL-> Renderer String: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
13:02:42 EST: OpenGL-> Version reported: 3.0 Mesa 11.0.2
13:02:42 EST: OpenGL-> Texture rectangle format: de1
13:02:42 EST: OpenGL-> Using Vertexbuffer Objects
13:02:42 EST: OpenGL-> Using Framebuffer Objects
13:02:42 EST: OpenGL-> Using FBO Stencil buffer
13:02:42 EST: OpenGL-> Using Stencil buffer clipping
13:02:42 EST: OpenGL-> Using Scissor Clipping
13:02:42 EST: OpenGL-> Not Using compression
13:02:42 EST: OpenGL-> Minimum cartographic line width: 1.0
13:02:42 EST: OpenGL-> Minimum symbol line width: 1.0

No idea what that is. Have not got any maps loaded to see the response.

Gallium llvmpipe driver is a software rasterizer:

llvmpipe

Originally Posted by deltasig

Starting from CLI:
Gtk-Message: Failed to load module "atk-bridge"
libGL error: unable to load driver: mali_drm_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: mali_drm

Then the ALSA lib messages follow

The interesting thing is that it does look for the mali driver but it does not find it although it is loaded:
orangepi@OrangePI:~$ lsmod
Module Size Used by
8188eu 915632 0
cdc_acm 15103 2
sunxi_ir_rx 6793 0
sunxi_gpiokey 2124 0
gpio_sunxi 8233 0
8189es 901572 0
mali_drm 6634 4
drm 180399 5 mali_drm
mali 211448 15
ump 40421 9 mali

Is it a matter of specifying any env variables at start up?

Thank you
DS

Is that with a build forcing OpenglESV1 ?

Hopefully someone else can help here, seems you are close, but I don't know the solution.

[deltasig]

This is the original build no OpenGLESv1 forced.

I'll try again and poke around. I'll be back Thank you

DS

[NahanniV]

Originally Posted by deltasig

This is the original build no OpenGLESv1 forced.

I'll try again and poke around. I'll be back Thank you

DS

If you have another SD card, you could try this distribution:

Orange Pi PC H3 – armbian

I don't think there is software OpenGL or GLshim pre-loaded, which may make things easier.

I have no Idea if it works on your board or not.

Cheers,
JM.

[deltasig]

SUCCESS! the Orange Pi PC run fully accelerated OpenCPN! I can move around or zoom in/out whole screen (339 mm) at the beat of a Wiener Waltz with up to 120 FPS for raster and 24 FPS for vector charts. That feels good!

Thank you JM for the tips. The tip about somehow making the CMakeLists.txt to "see" the GLES/gl.h and set the "Found GLESv1" worked.
The one about the "make -j5" did not; it threw the H3 into a swap thrashing loop and the compilation took three times as long! Not enough real storage, I guess, plus a suspected kernel bug that gets the kswapd0 process to monopolize a whole thread (100% cpu usage). Most of the time was spent on waiting for disk (microSD) swap IO.
I changed the CMakeLists.txt as follows in order for the Mali-400 to get in:
# find_path(OPENGLESv1_INCLUDE_DIR GLES/gl.h )
SET(OPENGLESv1_INCLUDE_DIR "/usr/include/khronos/GLES" )
I do not profess expertise in CMakeLists.tx but from what I understand the find_path instruction needs some suggestions to look at different locations to find the path where the GLES/gl.h is hiding. I don't know if having the correct info in OPENGLESv1_INCLUDE_DIR makes any difference but the change above forced the right flags to be set and the hardware acceleration to work.

Big thanks to the community of OpenCPN.
DS

[NahanniV]

Originally Posted by deltasig

SUCCESS! the Orange Pi PC run fully accelerated OpenCPN! I can move around or zoom in/out whole screen (339 mm) at the beat of a Wiener Waltz with up to 120 FPS for raster and 24 FPS for vector charts. That feels good!

Thank you JM for the tips. The tip about somehow making the CMakeLists.txt to "see" the GLES/gl.h and set the "Found GLESv1" worked.
The one about the "make -j5" did not; it threw the H3 into a swap thrashing loop and the compilation took three times as long! Not enough real storage, I guess, plus a suspected kernel bug that gets the kswapd0 process to monopolize a whole thread (100% cpu usage). Most of the time was spent on waiting for disk (microSD) swap IO.
I changed the CMakeLists.txt as follows in order for the Mali-400 to get in:
# find_path(OPENGLESv1_INCLUDE_DIR GLES/gl.h )
SET(OPENGLESv1_INCLUDE_DIR "/usr/include/khronos/GLES" )
I do not profess expertise in CMakeLists.tx but from what I understand the find_path instruction needs some suggestions to look at different locations to find the path where the GLES/gl.h is hiding. I don't know if having the correct info in OPENGLESv1_INCLUDE_DIR makes any difference but the change above forced the right flags to be set and the hardware acceleration to work.

Big thanks to the community of OpenCPN.
DS

Glad it's working.
The CubieTruck has 2GB RAM, so no swapping problem.
When OpenCPN starts up do you see a black or garbled screen until you click the chart Area ?
Do you know what version of WxWidgets you have ? (wx-config --version-full)

Cheers,
JM.

[deltasig]

wx-config 3.0.2.0

No black or garbled screen; straight to the last chart and scale within 8 sec.
Here's the log
17:36:29 EST: 2016-03-04
17:36:29 EST: ------- Starting OpenCPN -------
17:36:29 EST: Version 4.2.0 Build 2016-02-03
17:36:31 EST: wxWidgets version: wxWidgets 3.0.2 Linux 32 bit wxGTK
17:36:31 EST: MemoryStatus: mem_total: 1002 mb, mem_initial: 16 mb
17:36:31 EST: SData_Locn is /usr/local/share/opencpn/
17:36:31 EST: PrivateDataDir is /home/orangepi/.opencpn
17:36:31 EST: Using existing Config_File: /home/orangepi/.opencpn/opencpn.conf
17:36:31 EST: Setting Viewpoint Lat/Lon 39.1215, 23.7365
17:36:31 EST: Setting Ownship Lat/Lon 26.0387, -80.1396
17:36:31 EST: Styles loading from /usr/local/share/opencpn/uidata/styles.xml
17:36:31 EST: No styles found at: /home/orangepi/
17:36:31 EST: No styles found at: /home/orangepi/.opencpn/
17:36:31 EST: Using SVG Icons
17:36:31 EST: Detected display size (horizontal): 339 mm
17:36:31 EST: System default Language: en_US
17:36:31 EST: Opencpn language set to: en_US
17:36:31 EST: Creating MyFrame...size(1280, 674) position(0, 20)
17:36:31 EST: Creating glChartCanvas
17:36:31 EST: OpenGL-> Renderer String: Mali-400 MP
17:36:31 EST: OpenGL-> Version reported: 1.4 glshim wrapper
17:36:31 EST: OpenGL-> Texture rectangle format: de1
17:36:31 EST: OpenGL-> glGenerateMipmap unavailable
17:36:31 EST: OpenGL-> Using Vertexbuffer Objects
17:36:31 EST: OpenGL-> Framebuffer Objects unavailable
17:36:31 EST: OpenGL-> Using Depth buffer clipping
17:36:31 EST: OpenGL-> Using oes etc1 compression
17:36:31 EST: OpenGL-> Compressed tile size: 128kb (6:1)
17:36:31 EST: OpenGL-> Minimum cartographic line width: 1.0
17:36:31 EST: OpenGL-> Minimum symbol line width: 1.0
17:36:32 EST: ChartDB Cache policy: Application target is 493 MBytes
17:36:32 EST: Loading chart db version: V018
17:36:32 EST: Chartdb: Chart directory list follows
17:36:32 EST: Chart directory #0: /home/orangepi/MAPS/ENC_ROOT
17:36:32 EST: Chart directory #1: /home/orangepi/MAPS/Cm93 jan 2011
17:36:32 EST: Chart directory #2: /home/orangepi/MAPS/aa_Maps_SAS
17:36:32 EST: GPS Watchdog Timeout is: 6 sec.
17:36:32 EST: ChartSymbols loaded from /usr/local/share/opencpn/s57data/chartsymbols.xml
17:36:33 EST: Using s57data in /usr/local/share/opencpn/s57data
17:36:33 EST: Initializing Chart /home/orangepi/MAPS/Cm93 jan 2011/
17:36:33 EST: CM93Composite Chart Root is /home/orangepi/MAPS/Cm93 jan 2011//
17:36:33 EST: Loaded CM93 Dictionary from /home/orangepi/MAPS/Cm93 jan 2011//
17:36:33 EST: Loading CM93 cell /home/orangepi/MAPS/Cm93 jan 2011//03300060/G/03870071.G
17:36:37 EST: OpenCPN Initialized in 8258 ms.
17:36:37 EST: Looking for UserIcons at /home/orangepi/.opencpn/UserIcons
17:36:37 EST: Loading navobjects from navobj.xml
17:36:37 EST: Done loading navobjects
17:36:38 EST: Opening NMEA Datastream GPSD:localhost:2947
17:36:38 EST: Warning: Color not found CHDRD

Apart of the framebuffers (message in red), the missing color and the ship bells (sound like they're coming from the "Deep") everything looks good.

Cheers
DS

[svkatielee]

Originally Posted by deltasig

SUCCESS! the Orange Pi PC run fully accelerated OpenCPN! I can move around or zoom in/out whole screen (339 mm) at the beat of a Wiener Waltz with up to 120 FPS for raster and 24 FPS for vector charts. That feels good!

DS

I was all set to post my success with the OrangePi One and PC. I searched the forum one last time to be sure I wasn't redundant, and here you are! I only got the Raspberry Pi image to run and without hardware acceleration at that.
Thanks for all this. Is there a possibility you are posting the details of the config files or even the completed image somewhere? Please.

[deltasig]

Hi Larry, needless to say I'm very happy with the price/performance/features of the Orange pi PC; I would suggest for OS a Debian/Ubuntu version that has the accelerated hardware drivers/features generated in. As you can follow from my and NahanniV posts, the trick was to compile the program making sure that in the cmake step it thinks that it has found the hardware acceleration support. To that end I changed the CMakeLists.txt as follows in order for the Mali-400 to get in:
# find_path(OPENGLESv1_INCLUDE_DIR GLES/gl.h )
SET(OPENGLESv1_INCLUDE_DIR "/usr/include/khronos/GLES" )

I don't thing the actual location of GLES/gl.h makes any difference; anything that sets the OPENGLESv1_INCLUDE_DIR to True will work.

I'm not clear as to what config file details you need; I'll see if I can get the generated deb version online somewhere.

Good Luck

DS

[svkatielee]

Thank you DS, those 2 lines was what I was looking for. I had thought you needed to configure more of the source for the OPi.

[svkatielee]

I realize that this is not a c++ help forum, but I've never seen this kind of error and wornered if anyone else has. 68 minutes into the build of opencpn for armhf on a new Orange Pi PC with a class4 sd card that has been used several times on a raspberry. here is the last cmake and error (in red):

/usr/bin/cmake -E cmake_progress_report /home/larryl/OpenCPN/build/CMakeFiles 82
[ 50%] Building CXX object CMakeFiles/opencpn.dir/src/navutil.cpp.o
/usr/bin/c++   -DARMHF -DLINUX_CRASHRPT -DOCPN_HAVE_X11 -DOCPN_USE_PORTAUDIO -DTIXML_USE_STL -DUSE_GARMINHOST -DUSE_GLU_TESS -DUSE_RENDER_CAIRO -DUSE_S57 -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__OCPN_USE_CURL__ -D__WXGTK__ -DocpnUSE_GL -DocpnUSE_GLES -DocpnUSE_SVG -pthread -O3 -DNDEBUG -isystem /usr/lib/arm-linux-gnueabihf/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0 -I/home/larryl/OpenCPN/include -I/home/larryl/OpenCPN/src -I/home/larryl/OpenCPN/src/wxcurl -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0 -I/usr/lib/arm-linux-gnueabihf/gtk-2.0/include -I/home/larryl/OpenCPN/src/wxsvg/include/wxSVG -I/home/larryl/OpenCPN/src/wxsvg/include/wxSVGXML -I/home/larryl/OpenCPN/src/wxsvg/include -I/home/larryl/OpenCPN/src/wxsvg/src -I/home/larryl/OpenCPN/src/nmea0183 -I/home/larryl/OpenCPN/src/mygdal -I/home/larryl/OpenCPN/src/garmin/jeeps -I/home/larryl/OpenCPN/src/texcmp/lz4 -I/home/larryl/OpenCPN/src/texcmp/squish -I/home/larryl/OpenCPN/build/CMakeFiles/include    -Wall -Wno-unused -fexceptions -rdynamic  -g -fno-strict-aliasing  -DPREFIX=\"/usr/local\" -o CMakeFiles/opencpn.dir/src/navutil.cpp.o -c /home/larryl/OpenCPN/src/navutil.cpp
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
CMakeFiles/opencpn.dir/build.make:1000: recipe for target 'CMakeFiles/opencpn.dir/src/navutil.cpp.o' failed
make[2]: *** [CMakeFiles/opencpn.dir/src/navutil.cpp.o] Error 4
make[2]: Leaving directory '/home/larryl/OpenCPN/build'
CMakeFiles/Makefile2:415: recipe for target 'CMakeFiles/opencpn.dir/all' failed
make[1]: *** [CMakeFiles/opencpn.dir/all] Error 2
make[1]: Leaving directory '/home/larryl/OpenCPN/build'
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

real    68m8.930s

I will redo the make and see if I get the error again.
Thanks,

[nohal]

Didn't you run out of memory during the compilation? This does not really seem to have anything to do with OpenCPN's code.

Pavel

[svkatielee]

Originally Posted by nohal

Didn't you run out of memory during the compilation? This does not really seem to have anything to do with OpenCPN's code.

Pavel

I don't know if I ran out of memory or not. This is my first big compile on a arm. I am asking if there is a possibility of a bug in the compiler or is this just the cryptic message that should have said "you ran out of memory, start over.".

I thought it could also be the manifestation of the flaky results of a substandard sd card.

I was trying to ask here in a friendly forum before I made a fool of myself on the compiler forum.

[nohal]

It is impossible to say from the information provided. Try compiling using

make -j1

and watch the memory usage. It could perhaps give you some clue. Or not.

Pavel