OpenCPN Runs on Embedded ARM

[NahanniV]

Originally Posted by boat_alexandra

why doesn't the radar overlay work with opengles?

The Navico Br24PI is working; I have done some limited testing with my Dome.

I can't Imagine why the Garmin versions would not work.

JM.

[Aikiguy]

Gradar: I can't get it to compile with just opgles, it demands opengl.....

I could be doing something wrong though, but another friend and developer of graphics drivers for linux tried and said it would not.

Guy
:-)

[seandepagnier]

there is a subset of functions that work in both opengl and opengles (think of ven diagram) but then there is glshim which allows additional functions from opengl to sit on opengles. Mostly all opengl works on opengles with a few caveats. Most likely the radar plugin is fine. Now that glshim is built into opencpn it dlopens libGLES so you don't actually need to link with libGL when building the plugin, the symbols should be resolved when the plugin loads or errors are reported in the log.

[Eirik]

Is glshim now built into OpenCPN? Where can I d/l it from? GitHub?
Would really like to try it on my somewhat quirky Utilite.

Thanks, Eirik


Sent from my iPad using Cruisers Sailing Forum

[verkerkbr]

Now to ask a question:

Are there any arm devices at all which have good full opengl acceleration or do all use opengles? T[/QUOTE]

What is the real Problem. Is it the Graphics processor ?. Or only a software problem ? Most of these small System use the Mali Graphics processor.

This setup does not yet work with Graphics processing in hardware.

But I read there is a new Banana thing coming with another Graphics Processor:

CPU: A31S ARM Cortex-A7 quad-core,256 KB L1 cache 1 MB L2 cache
GPU: PowerVR SGX544MP2 with OpenGL ES 2.0, OpenCL 1.x, DX 9_3
Memory (SDRAM): 1GB DDR3 (shared with GPU)
Onboard Storage: SD (Max. 64GB) / MMC card slot

Any idea if this board works with Graphics processing in the hardware instead of in the software?

Regards,


Bram

[Aikiguy]

My understanding from a lot of research that the opengl (Not opengles which is a software emulation of the driver), is not currently in production from the folks at the company that makes the Mali chip.

They have hired 1, that is right ONE person, to try and make this driver, he has been working on it for over a year, and there is not a driver that installs with any of the standard distributions of linux. My opinion is that it might get done before Mali depreciates the chip, it might not. Don't get me wrong the person they hired is a great guy and does great work. There is only so much that one guy can do..

This is THE issue with linux and non standard hardware. The stuff that is out there on the edges like these little computers are not well supported.

I am holding out hope for the Raspberry PI2, and have given up hope on the Odroid.

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.

I am still trying, and will try the latest version of opencpn which apparently has the glshim (a bridge between opengl calls and opengles ((Emulated Software)) calls. However having seen how much opengles slows down any of these little computers, I am not really hoping for much. ((Can Anyone direct me to the version of opencpn that does this? THanks!).

The cubietruck has some opengl enabled in it's kernel, so some of the calls are handled by the graphics processor. It does look like it works smoother. It is an expensive board though with a small users group, and lower hardware specs than a comparable $35.00 raspberry pi2. However someone there added some of the anholt driver base to the kernel, not all of it though, and there are apparently some issues with what is used where.

Sources for the above:
anholt's lj
The Raspberry Pi VC4 Graphics Driver You Won't Find In Linux 4.0 - Phoronix
Cubietruck | Welcome to Cubieboard world! A series of open ARM miniPC!

And best of all this: https://github.com/anholt/linux/tree/vc4 which is supposed to be installable somehow into what we are doing, but I have no clue on how to do it. Which theoretically according to what I am reading should give opengl (not opengles), to the odroid, raspberry pi2, and a host of other boards. How do we install this in a kernel? Anyone want to make a custom kernel for either the odroid, or the raspberry pi2 that has this in it? (I have no idea how to compile a kernel).

Thanks,
Guy
:-)

[NahanniV]

Originally Posted by Eirik

Is glshim now built into OpenCPN? Where can I d/l it from? GitHub?
Would really like to try it on my somewhat quirky Utilite.

Thanks, Eirik


Sent from my iPad using Cruisers Sailing Forum

I don't think it's ready yet.

bdbcat says they are curently doing some housekeeping:
http://www.cruisersforum.com/forums/...ml#post1764114

As far as I can see this housekeeping includes adding support for Android and incorporating GLSHIM. I have not seen any GLSHIM bug fixes in the main branch of OpenCPN, perhaps it's being worked on in a private branch.

Cheers,
JM.

[owlhead]

Originally Posted by boat_alexandra

Are there any arm devices at all which have good full opengl acceleration or do all use opengles? T

Saw this thing while browsing through the internet today, though the specs looks to be a bit overkill for onboard applications and it is obviously much more expensive ($192) than the other boards discussed in this thread:

https://developer.nvidia.com/jetson-tk1

Jetson TK1 Board Features
Tegra K1 SOC
Kepler GPU with 192 CUDA cores
4-Plus-1 quad-core ARM Cortex A15 CPU
2 GB x16 memory with 64 bit width
16 GB 4.51 eMMC memory
1 Half mini-PCIE slot
1 Full size SD/MMC connector
1 Full-size HDMI port
1 USB 2.0 port, micro AB
1 USB 3.0 port, A
1 RS232 serial port
1 ALC5639 Realtek Audio codec with Mic in and Line out
1 RTL8111GS Realtek GigE LAN
1 SATA data port
SPI 4MByte boot flash

Jetson TK1 - eLinux.org

Hardware-accelerated APIs supported:

CUDA 6.0 (SM3.2, roughly the same as desktop SM3.5)
OpenGL 4.4
OpenGL ES 3.1
OpenMAX IL multimedia codec including H.264, VC-1 and VP8 through Gstreamer
NPP (CUDA optimized NVIDIA Performance Primitives)
OpenCV4Tegra (NEON + GLSL + quad-core CPU optimizations)
VisionWorks

[seandepagnier]

Originally Posted by Aikiguy

They have hired 1, that is right ONE person, to try and make this driver, he has been working on it for over a year, and there is not a driver that installs with any of the standard distributions of linux. My opinion is that it might get done before Mali depreciates the chip, it might not. Don't get me wrong the person they hired is a great guy and does great work. There is only so much that one guy can do..

You mean one person to write an opengl driver? I didn't think a full spec opengl driver was even possible with mali hardware without some software emulation. Why do we care when we already have opengles?

I am holding out hope for the Raspberry PI2, and have given up hope on the Odroid.

I am too, but perhaps for different reasons. The usb ports on my odroid don't work.

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.

Has nothing to do with opengl or opengles. You can only use as many cores as threads in the application. OpenCPN has limited support for multiple cores, but it's probably ok because mostly it doesn't use much cpu. In a few examples which use lots of cpu I have used threads like generating the compressed texture cache, and some plugins (like weather routing) Otherwise it uses a single core.

I had intended a while ago to improve this, for example putting all nmea data processing in a thread so it could be handled in a separate core. Another thread could upload textures and data to the graphics card while the main thread renders it. I could even put the grib particle update in a separate thread etc...

So in effect you get slower charting with opengles, because one processor core is now running a software emulator for opengl,

What?

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.

If you mean by using multiple threads, then yes, this is always the case and not specific to linux.

I am still trying, and will try the latest version of opencpn which apparently has the glshim (a bridge between opengl calls and opengles ((Emulated Software)) calls. However having seen how much opengles slows down any of these little computers, I am not really hoping for much. ((Can Anyone direct me to the version of opencpn that does this? THanks!).

Maybe you are using software opengles not hardware accelerated, it's much faster hardware acclerated

The cubietruck has some opengl enabled in it's kernel, so some of the calls are handled by the graphics processor. It does look like it works smoother. It is an expensive board though with a small users group, and lower hardware specs than a comparable $35.00 raspberry pi2. However someone there added some of the anholt driver base to the kernel, not all of it though, and there are apparently some issues with what is used where.

You mean opengles, not opengl. The bananna pi has the same hardware as the cubie truck and is a cheaper alternative, possibly the cheapest board I know of which currently runs opencpn really well.

And best of all this: https://github.com/anholt/linux/tree/vc4 which is supposed to be installable somehow into what we are doing, but I have no clue on how to do it. Which theoretically according to what I am reading should give opengl (not opengles), to the odroid, raspberry pi2, and a host of other boards. How do we install this in a kernel? Anyone want to make a custom kernel for either the odroid, or the raspberry pi2 that has this in it? (I have no idea how to compile a kernel).

Correct me if i'm wrong but I believe rp2 has broadcom drivers which is what the vc4 graphics driver is all about, not odroid, at least not the U3.

Yes, you need to patch the kernel to use it as it's not in linux 4.0.0, but maybe in linux soon. I have no idea how well it works, but you said it has opengl support not opengles?? I thought the vc4 was opengles... anyway I couldn't find anyone who had actually used the driver so I don't know much about it, and I don't have a raspberry pi2.

Basically it needs to support opengles (or opengl) in windowed mode. The original broadcom drivers for the rpi did not and so when I used them with opencpn, they worked (about 1/3rd the speed of cubie truck, or 3 times faster than software rendering) giving me 10 frames per second panning and zooming. I imagine on rpi2 this would be a lot faster and close to cubie truck speed. The problem is, all other windows were invisible including the toolbar and chart selector, and status bar.

A possible solution is to render the toolbar and chart selector using opengl which is not difficult to implement. Of course the route manager setup etc.. would also be invisible. Maybe we could switch off opengl when other windows are visible, or copy them and draw them in opengl... I might be able to deal with this if I actually had a rpi2.

Originally Posted by NahanniV

I don't think it's ready yet.

bdbcat says they are curently doing some housekeeping:
http://www.cruisersforum.com/forums/...ml#post1764114

As far as I can see this housekeeping includes adding support for Android and incorporating GLSHIM. I have not seen any GLSHIM bug fixes in the main branch of OpenCPN, perhaps it's being worked on in a private branch.

Cheers,
JM.

Are you sure? It's in master branch. He tested on android I tested on cubie truck. I'm sure it still breaks somehow somewhere.

Originally Posted by owlhead

Saw this thing while browsing through the internet today, though the specs looks to be a bit overkill for onboard applications and it is obviously much more expensive ($192) than the other boards discussed in this thread:

https://developer.nvidia.com/jetson-tk1



Jetson TK1 - eLinux.org

I think it's really overkill, but maybe it will run opencpn really well since it already supports opengl. My guess is, it uses a lot of power, and most of the specs there are utterly useless like all the cuda cores (we could at some point in the future use these somehow)

[NahanniV]

Originally Posted by boat_alexandra

....
Are you sure? It's in master branch. He tested on android I tested on cubie truck. I'm sure it still breaks somehow somewhere.
....

Are you saying the problems with rendering vector charts using GLSHIM have
been fixed ?

I saw that the code was included about a month ago, but I didn't see any changes except to the makefile since then.

If it's fixed, I'll give it a try.

Thanks !
JM.

[Aikiguy]

Originally Posted by boat_alexandra

You mean one person to write an opengl driver? I didn't think a full spec opengl driver was even possible with mali hardware without some software emulation. Why do we care when we already have opengles?

Raspberry PI2: Opengles is emulated on the same processor core as the opencpn program. The charting using vector charts is usable without Opengles, but too slow to be a usable solution for even route plotting with it on. I have also not gotten the gradar or the gxradar to compile on the system wihtout Opengl (NOT ES), but the latest 4.2.xx beta should do that, but I can't find where to install it from. The processor pegs at a little over 25% and stays there while panning vector charts is slowwwww. Turn off opengl in opencpn and the charting is very usable. However no radar overlay then or any of the components that use opengles for overlays.

Originally Posted by boat_alexandra

I am too, but perhaps for different reasons. The usb ports on my odroid don't work.

I don't have that problem.

Originally Posted by boat_alexandra

Has nothing to do with opengl or opengles. You can only use as many cores as threads in the application. OpenCPN has limited support for multiple cores, but it's probably ok because mostly it doesn't use much cpu. In a few examples which use lots of cpu I have used threads like generating the compressed texture cache, and some plugins (like weather routing) Otherwise it uses a single core.

Hmm Mine Pi2 pegs it when moving around on vector charts I think. Will try again.

Originally Posted by boat_alexandra

I had intended a while ago to improve this, for example putting all nmea data processing in a thread so it could be handled in a separate core. Another thread could upload textures and data to the graphics card while the main thread renders it. I could even put the grib particle update in a separate thread etc...

Yes PLEASE!!! YES Please!!! I will send you a bring you a beer! :-)

Originally Posted by boat_alexandra

Maybe you are using software opengles not hardware accelerated, it's much faster hardware accelerated

HUH my understanding was that opengles is only software, there is no hardware portion.? The hardware portion is what the broadcom employee is working on was my understanding.

Originally Posted by boat_alexandra

You mean opengles, not opengl. The bananna pi has the same hardware as the cubie truck and is a cheaper alternative, possibly the cheapest board I know of which currently runs opencpn really well.

Apparently from my research the cubitruck linux package has some hardware acceleration opengl tied into the kernel, which comes from the cubie people. But I can't find where I found that. some Suni site that linked to the hardware on the cubie truck.

Originally Posted by boat_alexandra

Correct me if i'm wrong but I believe rp2 has broadcom drivers which is what the vc4 graphics driver is all about, not odroid, at least not the U3.

I don't know enough to evaluate this statement

Originally Posted by boat_alexandra

Yes, you need to patch the kernel to use it as it's not in linux 4.0.0, but maybe in linux soon. I have no idea how well it works, but you said it has opengl support not opengles?? I thought the vc4 was opengles... anyway I couldn't find anyone who had actually used the driver so I don't know much about it, and I don't have a raspberry pi2.

I am so hoping that it is added to the raspberry pi2, the official rumor is that it is coming soon. But I don't know what soon is?

Originally Posted by boat_alexandra

Basically it needs to support opengles (or opengl) in windowed mode. The original broadcom drivers for the rpi did not and so when I used them with opencpn, they worked (about 1/3rd the speed of cubie truck, or 3 times faster than software rendering) giving me 10 frames per second panning and zooming. I imagine on rpi2 this would be a lot faster and close to cubie truck speed. The problem is, all other windows were invisible including the toolbar and chart selector, and status bar.

A possible solution is to render the toolbar and chart selector using opengl which is not difficult to implement. Of course the route manager setup etc.. would also be invisible. Maybe we could switch off opengl when other windows are visible, or copy them and draw them in opengl... I might be able to deal with this if I actually had a rpi2.

Where are you can I send you one?

Originally Posted by boat_alexandra

Are you sure? It's in master branch. He tested on android I tested on cubie truck. I'm sure it still breaks somehow somewhere.

I will do a completely new install on my raspberry pi2 and get back to you on this.

boat_alexandra Thank you very very much for the help! It is really appriciated!

I am not arguing with you on anything in here.. I bow to your superior knowledge.

Thanks,
Guy
:-)

[bcn]

OpenGL|ES is explained and defined here:

https://www.khronos.org/opengles/

The Standard for Embedded Accelerated 3D Graphics
OpenGL® ES is a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems - including consoles, phones, appliances and vehicles. It consists of well-defined subsets of desktop OpenGL, creating a flexible and powerful low-level interface between software and graphics acceleration. OpenGL ES includes profiles for floating-point and fixed-point systems and the EGL™ specification for portably binding to native windowing systems. OpenGL ES 1.X is for fixed function hardware and offers acceleration, image quality and performance. OpenGL ES 2.X enables full programmable 3D graphics. OpenGL SC is tuned for the safety critical market.

OpenGL|ES in Wikipedia:
OpenGL ES - Wikipedia, the free encyclopedia

The Khronos group has announced recently that OpenGL and OpenGL|ES will be overridden in the future by Vulkan :
https://www.khronos.org/vulkan

Glshim - https://github.com/lunixbochs/glshim - is a library which maps the functions of OpenGl into OpenGL|ES:

This is a shim providing OpenGL 1.x functionality to OpenGL ES accelerated cards.

[seandepagnier]

Originally Posted by Aikiguy

Hmm Mine Pi2 pegs it when moving around on vector charts I think. Will try again.

And this is software emulated opengl? not surprised.

HUH my understanding was that opengles is only software, there is no hardware portion.? The hardware portion is what the broadcom employee is working on was my understanding.

No.

There is opengles hardware accelerated driver always has been for raspberry pi, however it is not open source; the vc4 driver is. Can you send a link to what this broadcom emplyee is doing?

Apparently from my research the cubitruck linux package has some hardware acceleration opengl tied into the kernel, which comes from the cubie people. But I can't find where I found that. some Suni site that linked to the hardware on the cubie truck.

not suni; it is sunxi.

Yes it is a hardware accelerated driver for opengles, but it isn't open.

Where are you can I send you one?

I'm in indonesia.

I have no idea how you can send me one. Maybe in 2-3 months I will appear in some other country because this place is diabolical.

I will do a completely new install on my raspberry pi2 and get back to you on this.

Great, please post any issues in this form, es2_info output etc..

boat_alexandra Thank you very very much for the help! It is really appriciated!

I am not arguing with you on anything in here.. I bow to your superior knowledge.

I would notice if you are arguing; obviously you are just confused in a few ways, it's ok just ask!

[NahanniV]

Originally Posted by NahanniV

Are you saying the problems with rendering vector charts using GLSHIM have
been fixed ?

I saw that the code was included about a month ago, but I didn't see any changes except to the makefile since then.

If it's fixed, I'll give it a try.

Thanks !
JM.

I tried the latest master branch 4.x of OpenCPN on a fresh install of CubieEZ 2.2 on my CubieTruck. Updated the build instructions on the Wiki :Building and installing on CubieTruck with Hardware Acceleration | Official OpenCPN Homepage

The build went fine, but the problems with vector charts in OpenGL mode from version 4.0 persist:

Dredged Area, Quality Of Data, Unsurveyed Area, and Shoreline Constructions do not render correctly.

BDBCAT mentioned that he is working on a private version of glshim:http://www.cruisersforum.com/forums/...ml#post1756021

Perhaps these issues will be resolved when it is ready for public use.

Cheers,
JM.

[seandepagnier]

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