Has anyone managed to get hardware supported OpenGL on Rasperry Pi2 to work?

[Hakan]

Dave....thanks for your post making me trust OCPN will support also the Rb-Pi in a not so far future. But it's not a hurry at all. At least for me this Rb project is mostly for fun. What I did was to start touch a working system, I should have known! OCPN was working with a "out of the box system" although without OpenGL. Then I began to install additions without real control and now I'm lost and can't trace my history back to be able to restore the system.
I think I've to restart from a clean system and await OCPN core support instead.

Thanks/ Håkan

[seandepagnier]

Originally Posted by bdbcat

Sean...

I recommend that you try to use the glshim that is in the 4.1 master tree now. I hacked it a bit to solve some troubles with passing doubles as function arguments. Compiler error, or I dunno what else. Also hacked the CMake build rules, just to get it going. I think a more generalized approach to GLES and glshim should be implemented in the OCPN CMake rules. But I have only the one platform to work with now.

Which platform? Android?
I will try using openGLES on x86 linux because with intel graphics even if libGL is supported, libGLES is also supported.

So take a look if it appeals, and send some patches.

Ok, I think I already found some minor bugs.

You can use the glu tesselator as well. Seems like decent code, and I sure need it for android. So might as well try it for all arm.

Ok, well if you need it for android it must be included, I just think the glu tesselator which is part of the software opengl package can be used with glshim and hardware accelerated libgles, but maybe it's good to avoid this.

I don't have any RPI hardware running, so cannot help here specifically with this thread.

Also, note that I disabled GL display list processing. Its broken in glshim, but should be an easy fix. But time......

Good Luck
Dave

I don't think it's completely broken, because, after all it does work on linux. It might be nice to figure out why it doesn't work on arm, but.. did you disable display lists for anything bug ownship rendering? We really can and should eliminate using display lists all together.

[Hakan]

Sean..
When I try to build glshim for RPi, cmake . -DBCMHOST=1; make GL, I get the following errors:

src/CMakeFiles/GL.dir/build.make:422: recipe for target 'src/CMakeFiles/GL.dir/glx/lookup.c.o' failed
make[3]: *** [src/CMakeFiles/GL.dir/glx/lookup.c.o] Error 1
CMakeFiles/Makefile2:82: recipe for target 'src/CMakeFiles/GL.dir/all' failed
make[2]: *** [src/CMakeFiles/GL.dir/all] Error 2
CMakeFiles/Makefile2:94: recipe for target 'src/CMakeFiles/GL.dir/rule' failed
make[1]: *** [src/CMakeFiles/GL.dir/rule] Error 2
Makefile:106: recipe for target 'GL' failed
make: *** [GL] Error 2

Is it possible you can see what I'm missing?
The build log is attached, please discard the ".pdf" extension.
Thanks Håkan

[bdbcat]

Sean...

I would say to focus on embedded glshim for generic arm/linux platform. Once it works well for OCPN, we can push the changes upstream for all to see and use.

Android GLES is a whole separate path, with many potholes which I am filling as I discover them..

The GLU tesselator replacement is needed for android, since there is no such thing as glu for android without root dependencies. So it will be there if needed.

Display lists: I only changed ownship rendering in glChartCanvas::ShipDraw(). Probably a trivial bug.

Dave

[lunixbochs]

If you read the glshim readme, I have a mobile-optimized version of glu including the tesselator here https://github.com/lunixbochs/glues.git

The actual GLU project should work with glshim as well, but may be slower or less reliable than glues.

As far as those build errors, try the patch in https://github.com/lunixbochs/glshim/pull/71 for building on the Pi 2. I don't have a Raspberry Pi 2 yet, so I haven't tested glshim on one.

[seandepagnier]

Originally Posted by lunixbochs

If you read the glshim readme, I have a mobile-optimized version of glu including the tesselator here https://github.com/lunixbochs/glues.git

The actual GLU project should work with glshim as well, but may be slower or less reliable than glues.

I have been trying to use glues, but the tesselator constantly caused segmentation faults when dealing with the gshhs data. In the cases when it didn't crash, the output rendered was incorrect.

I replaced it with the glu project and it's working perfectly. The speed is not so much of an issue because opencpn will invoke the tesselator once per cell, and cache the vertexes to use after.

Could you explain what changes were made to glues and why it should run faster?

[lunixbochs]

glues is a project I adapted from someone else for glshim. It targets GLES directly, so it doesn't give glshim any extra work, and glshim is guaranteed to support all of the features. I can't guarantee I have everything needed for all functions in the real GLU as I haven't usually been using it

[mattkab]

I built OpenCPN on the Raspberry Pi 2 this past week. I compiled and built OpenCPN without installing glshim or glues, and it runs. It is just very very slow (0 FPS)

I can run glxgears, but only at ~15FPS.

Very clearly I am running software rendering of OpenGL.

I spent a couple hours today trying to get OpenGL to work on it, but to no avail. After installing libgl1-mesa-dev, I can no longer make either OpenCPN or GLshim

I see exactly what Hakan saw on post #33:

Originally Posted by Hakan

Sean..
When I try to build glshim for RPi, cmake . -DBCMHOST=1; make GL, I get the following errors:

src/CMakeFiles/GL.dir/build.make:422: recipe for target 'src/CMakeFiles/GL.dir/glx/lookup.c.o' failed
make[3]: *** [src/CMakeFiles/GL.dir/glx/lookup.c.o] Error 1
CMakeFiles/Makefile2:82: recipe for target 'src/CMakeFiles/GL.dir/all' failed
make[2]: *** [src/CMakeFiles/GL.dir/all] Error 2
CMakeFiles/Makefile2:94: recipe for target 'src/CMakeFiles/GL.dir/rule' failed
make[1]: *** [src/CMakeFiles/GL.dir/rule] Error 2
Makefile:106: recipe for target 'GL' failed
make: *** [GL] Error 2

Is it possible you can see what I'm missing?
The build log is attached, please discard the ".pdf" extension.
Thanks Håkan

Has anyone else had any luck?

[nohal]

Matt...
Have you tried the suggestion from post #35?

Pavel

[mattkab]

Pavel:

I did, and got similar make errors and couldn't build it. I'm not at the device right now so I can't provide the exact message but I'll check again tomorrow.

Thanks!

[seandepagnier]

Can you run es2_gears? Does it run in a window? I got hardware acceleration working on my raspberry pi v1, and it worked but the toolbar, statusbar chartwindow etc were all invisible because the driver is fullscreen only. I found some hacks online to copy the framebuffer back into x to make hardware acceleration work in window mode (with the cost of an extra copy which isn't too bad) but this is not integrated into opencpn or anything. Otherwise, maybe the opensource driver is better (is's very now)

glshim is built into opencpn now, so there is no need to build it, but you might need to tweak the cmakelists to add the bcmhost define.

[mattkab]

Originally Posted by boat_alexandra

Can you run es2_gears? Does it run in a window? I got hardware acceleration working on my raspberry pi v1, and it worked but the toolbar, statusbar chartwindow etc were all invisible because the driver is fullscreen only. I found some hacks online to copy the framebuffer back into x to make hardware acceleration work in window mode (with the cost of an extra copy which isn't too bad) but this is not integrated into opencpn or anything. Otherwise, maybe the opensource driver is better (is's very now)

glshim is built into opencpn now, so there is no need to build it, but you might need to tweak the cmakelists to add the bcmhost define.

I can't find es2_gears anywhere in any of the RPi repositories. I have mesa-utils installed, but there are no packages found when I look for mesa-utils-extra or mesa-demos, the two packages that contain es2_gears when I google search.

I did find a workaround on the problem with building OpenCPN though -- somehow my cmake files had an error. I deleted the build directory, recreated it, and re-ran CMAKE. It worked fine. Now I'm running make and it's moving along just fine. Should be done in a couple hours, and I'll report back.

Thanks again, everyone.

[mattkab]

Moving the conversation over to the Embedded ARM thread to keep the information organized and because it's currently a repeated error.

[erik23_de]

Hi,

I just make a fresh pull, (til now 4.1 from 20th of march). It looked all very promising, with that gl stuff.
But compiling stopped, saying that "cannot find -ldri2". So I probably missed to install a library, but wich one? (okay: dri2 library wich is part of wich packet) I installed everything with a dri2 in it, but that did not help...

(Raspi II)

Hoping for a hint...

[mattkab]

Originally Posted by erik23_de

Hi,

I just make a fresh pull, (til now 4.1 from 20th of march). It looked all very promising, with that gl stuff.
But compiling stopped, saying that "cannot find -ldri2". So I probably missed to install a library, but wich one? (okay: dri2 library wich is part of wich packet) I installed everything with a dri2 in it, but that did not help...

(Raspi II)

Hoping for a hint...

I had the same problem on a previous build, and the following commands worked just fine:

sudo apt-get install autoconf xutils-dev
git clone https://github.com/robclark/libdri2
cd libdri2
./autogen.sh
./configure --prefix=/usr
make
make install
ldconfig

But I'm currently doing a brand new fresh build, and it compiles fine (Software rendered OpenGL).

I installed the following and it compiled successfully (4.1.427):

apt-get install -y libgtk2.0-dev gettext git-core cmake gpsd gpsd-clients libgps-dev build-essential wx-common libwxgtk2.8-dev libglu1-mesa-dev wx2.8-headers libbz2-dev libtinyxml-dev libsdl1.2debian xcalib libportaudio2 portaudio19-dev libegl1-mesa-dev