OpenCPN on Raspberry Pi 2 - slow panning

[CCed]

I have installed OpenCPN on RPi model B and on the new RPi 2,
I can not notice any difference in performance. For both platforms panning and zooming raster chars is extremely slow , and in practice not usable. When panning, screen is updated less than once per second.
For RPI 2 I have tried HW acceleration , but this made panning even slower , and also charts tend to jump in unexpected directions.
I have done some experiments with screen resolutions/frame buffer depths and memory allocations to GPU, but no visible changes in performance can be seen.
Building texture cache is unstable and results in crashes and caleidoscope maps.
I noticed that on older RPI, the CPU load is 100% when panning, while for RPi 2 the load is 25%. RPI 2 processor has 4 cores, so maybe this explains the 25%. Only one is used I guess.
If this is the case , Question to the forum is if it would be possible to use multiple cores to get better performance ?
If anyone have any suggestions on how to get better performance , this would be much appreciated.
If not , I'll try another platform.
Kind regards, Christer

[seandepagnier]

Originally Posted by CCed

I have installed OpenCPN on RPi model B and on the new RPi 2,
I can not notice any difference in performance. For both platforms panning and zooming raster chars is extremely slow , and in practice not usable. When panning, screen is updated less than once per second.
For RPI 2 I have tried HW acceleration , but this made panning even slower , and also charts tend to jump in unexpected directions.
I have done some experiments with screen resolutions/frame buffer depths and memory allocations to GPU, but no visible changes in performance can be seen.
Building texture cache is unstable and results in crashes and caleidoscope maps.

Please post log file.

Can you provide backtraces of the crashes?

I noticed that on older RPI, the CPU load is 100% when panning, while for RPi 2 the load is 25%. RPI 2 processor has 4 cores, so maybe this explains the 25%. Only one is used I guess.
If this is the case , Question to the forum is if it would be possible to use multiple cores to get better performance ?

Yes it's possible, but its a lot easier and with even better performance to use hardware acceleration.

If anyone have any suggestions on how to get better performance , this would be much appreciated.
If not , I'll try another platform.
Kind regards, Christer

When you run glxinfo what does it say? And glxgears you get what fps?

I was able to get about 10 frames per second on a raspberry pi using hardware acceleration, but the toolbar and other windows were invisible because the broadcom drivers didn't handle windowing.

There is a hack to make it work in windowing mode which maybe we can use, but it involves an extra copy of the window every frame. Otherwise, maybe the new open source driver will work; did you try it?

[conachair]

Have you added these lines to config.txt as described here...
Pi Chart

vi /boot/config.txt
framebuffer_depth=32
framebuffer_ignore_alpha=1

[CCed]

Thanks for the responses :

1: Some more info, the more I zoom in the chart, the slower the panning gets

2: I have tried HW acceleration in OpenCPN , but as described above, panning gets even slower and maps tend to jump in unexpected directions. (often jump back to where I started the panning).

3: I checked glxinfo:
name of display: :0.0
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so
display: :0 screen: 0
direct rendering: Yes
OpenGL renderer string: Software Rasterizer

I'm not that familar with OpenGL/glxinfo , but it looks as there may be something worth looking into in the above result ?

glxgears gives approx 36 fps

4: Yes , the below lines are in config.txt:
framebuffer_depth=32
framebuffer_ignore_alpha=1

5: Crashes : When Building texture cache , progress suddenly stopped and system became unresponsive. Had to reboot.
Caleidoscope maps, I got that occasionally when texture caching was enabled.
In order to provide the backtraces, are we talking about OpenGL traces or OpenCPN traces ?
I need some guidance about which logs/backtraces to provide , and how to enable and/or find them.

[nohal]

CCed...
Your system is NOT using the GPU, all OpenGL is software emulated - it makes very little sense to progress in this direction until you get HW acceleration to work.
As far as the backtraces go (in case the program crashes for you at all, which does not seem so from your last post):
Install GDB

sudo apt-get install gdb

Run OpenCPN in the debugger

gdb opencpn
(gdb) run

Wait for it to crash
Generate a backtrace

(gdb) backtrace

Post it here

Pavel

[CCed]

Thanks ,
So HW acceleration does not seem to be used. A few more questions then.

Does anyone know if HW acceleration is expected to work on the RPi/raspbian installation. ? If it is, then I guess something needs to be fixed in my particular system, which I guess can be done. If it's not supposed to work, my attempts becomes more of pilot project which may be a bit more tricky.

About the Open Source driver , I'm happy to try it, but would need some advice on where to find it , and how to install it. ( And possibly how to revert to the original drivers if the new one isn't working well.