Rpi Developer says "slimm(ing) down your application". How ?

[bdbcat]

NahanniV....
We need to be clear:
Does the problem occur if you are only using ENCs? Or does it require some use of RNCs? These have greatly different GL memory footprints....


Thanks
Dave

[verkerkbr]

Originally Posted by verkerkbr

Now I see a well known problem. Users are in a hurry and tap keys several times mostly the same key. Say the + key or - keys. The RPI is then overfilled with instructions.

You can avoid some problems by swiching off soundings and text first, then there is less use of the resources.

Perhaps is it an idea to add a time delay between using the keys ?

Regards,


Bram

Re: NV


The Rpi would usually follow our route during the day without any intervention. Then at the end of the day when we would start looking for an anchorage, panning, zooming, changing scale, switching chart types... it would inevitably crash.

I think there too much load on the RPI. All these actions are probably too fast after another. Some processes with the charts needs time.

What happens if these actions are done with some time interval ?


Bram

[NahanniV]

Originally Posted by bdbcat

NahanniV....
We need to be clear:
Does the problem occur if you are only using ENCs? Or does it require some use of RNCs? These have greatly different GL memory footprints....


Thanks
Dave

I can not say for certain that ENCs only causes the problem.

But I am certain that it has happened when I am using RNCs exclusivly.
I have a Chart Group that is only RNCs.

[Moo]

Originally Posted by bdbcat

NahanniV....
We need to be clear:
Does the problem occur if you are only using ENCs? Or does it require some use of RNCs? These have greatly different GL memory footprints....


Thanks
Dave

RNCs when I have seen it.

[transmitterdan]

Originally Posted by verkerkbr

Hi All,

latest sentence also added to my config.txt. Trying to switch on the texture caching did not work. Setting was removed after reboot.

I don't see what is the real problem here.

I'am using VC4 OpenGL driver with the latest kernel version 4.19.36 and the system is working fast and without any problems.

Is there sufficient space on the SD card ? (Gparted check).

Using Vector charts. Some older kernel version had sometimes problems. But now it seems full-proof in combination with VC4/OpenGL.

Bram

Bram,

Kernel 4.19.36 is the latest unstable/testing kernel. It will not be installed for most regular users.

Dan

[NahanniV]

Originally Posted by verkerkbr

Re: NV


The Rpi would usually follow our route during the day without any intervention. Then at the end of the day when we would start looking for an anchorage, panning, zooming, changing scale, switching chart types... it would inevitably crash.

I think there too much load on the RPI. All these actions are probably too fast after another. Some processes with the charts needs time.

What happens if these actions are done with some time interval ?


Bram

Bram,

I am not performing multiple actions rapidly, except perhaps panning and zooming.

If there is a sequence of user actions that cause a hangup or crash, please report it. There should not be any user inputs that can hang up the program, no matter how quickly they are performed.

[verkerkbr]

Originally Posted by transmitterdan

Bram,

Kernel 4.19.36 is the latest unstable/testing kernel. It will not be installed for most regular users.

Dan

Hi Dan,

you are right. It is the latest test kernel version.

Stable version is still 4.17.XX. But I can inform that the latest kernel 4.19.36 version works great in combination with OpenGL VC4 setting.

You can simple try it with: sudo rpi-update.

Regards,


Bram

[NahanniV]

Originally Posted by verkerkbr

Hi Dan,

you are right. It is the latest test kernel version.

Stable version is still 4.17.XX. But I can inform that the latest kernel 4.19.36 version works great in combination with OpenGL VC4 setting.

You can simple try it with: sudo rpi-update.

Regards,


Bram

Hi Bram,

I agree with your much repeated statement that "it works great and very fast".

BUT, when pressed, you seem to have similar problems as I am reporting.

My point of view is that we should track down these problems, as small or infrequent as they may be in order to make OpenCPN on Rpi completely reliable.

So, I encourage you to report any problems you see, so that they can be eliminated.

[seandepagnier]

The raster texture cache reduces the gpu memory needed to 1/6th. It also allows much faster reloading so the amount of graphics memory is only needed not usually more than 16M and more than this does not make much difference.



So if the problem is gpu memory I would suggest finding a way to build opencpn using gles with etc1 support and limiting gpu memory opencpn uses for raster textures to about 16M.


Sean

[NahanniV]

Originally Posted by boat_alexandra

The raster texture cache reduces the gpu memory needed to 1/6th. It also allows much faster reloading so the amount of graphics memory is only needed not usually more than 16M and more than this does not make much difference.



So if the problem is gpu memory I would suggest finding a way to build opencpn using gles with etc1 support and limiting gpu memory opencpn uses for raster textures to about 16M.


Sean

It’s been a few years, but I seem to remember a few problems when trying to use GLES, that was on a MAli GPU.

Switching to GLES seems like a big change that might introduce more problems than it would fix.

Is it not possible to use etc1 compression with desktop OpenGL ?

[bdbcat]

NahanniV...


The GL driver needs to support at least one texture compression mode. The current rPI GL driver supports none at all. So we cannot use texture compression in GL immediate mode at all.



Have you tried my earlier experiment, running unit_test_1 with a large RNC chartset loaded? This will definitely stress the GPU texture memory. I saw no problems, but maybe you should try also. We really can figure this out if we can devise a repeatable failure case.



Going back to GLES and glShim on RPI would be a regression in overall performance, I fear.

Are you able to build OCPN from scratch on your device?


Thanks
Dave

[transmitterdan]

Ok, I rebuilt OV5 with the unstable/testing kernel. I had to use the latest git of wxWidgets 3.1.x which took several hours to build.

Now i have a stable system with OpenGL real driver. So I fear there is maybe a wx issue that got “fixed” after 3.0.x was released.

Before we get too excited I also have lots of error messages issued by wxWidgets wxFile object into the opencpn.log file. I am investigating.

[did-g]

Originally Posted by transmitterdan

Before we get too excited I also have lots of error messages issued by wxWidgets wxFile object into the opencpn.log file. I am investigating.

It's /proc/memory stuff, files there can't seek and wx reports a warning every time O open a file!

[NahanniV]

Originally Posted by bdbcat

NahanniV...


The GL driver needs to support at least one texture compression mode. The current rPI GL driver supports none at all. So we cannot use texture compression in GL immediate mode at all.

It is my understanding that the VC4 driver supports ETC1 compression.
https://www.phoronix.com/scan.php?pa...er-Tex-Up-Down
Is that only available for GLES ?

Originally Posted by bdbcat

Have you tried my earlier experiment, running unit_test_1 with a large RNC chartset loaded? This will definitely stress the GPU texture memory. I saw no problems, but maybe you should try also. We really can figure this out if we can devise a repeatable failure case.

I tried it just now and it did not fail.
There were some messages, mostly about audio, but also a mismatch that might be important:

pi@openplotter:~ $ opencpn               
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround40
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround41
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround50
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround51
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround71
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'defaults.bluealsa.device'
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4996:(snd_config_expand) Args evaluate error: No such file or directory
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM bluealsa
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'defaults.bluealsa.device'
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4996:(snd_config_expand) Args evaluate error: No such file or directory
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM bluealsa
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
15:03:37: Device: 0: bcm2835 ALSA: - (hw:0,0)
15:03:37: Device: 1: bcm2835 ALSA: IEC958/HDMI (hw:0,1)
15:03:37: Device: 2: sysdefault
15:03:37: Device: 3: default
15:03:37: Device: 4: dmix
15:03:37: Device: 0: bcm2835 ALSA: - (hw:0,0)
15:03:37: Device: 1: bcm2835 ALSA: IEC958/HDMI (hw:0,1)
15:03:37: Device: 2: sysdefault
15:03:37: Device: 3: default
15:03:37: Device: 4: dmix
15:03:37: Device: 0: bcm2835 ALSA: - (hw:0,0)
15:03:37: Device: 1: bcm2835 ALSA: IEC958/HDMI (hw:0,1)
15:03:37: Device: 2: sysdefault
15:03:37: Device: 3: default
15:03:37: Device: 4: dmix
15:03:37: Device: 0: bcm2835 ALSA: - (hw:0,0)
15:03:37: Device: 1: bcm2835 ALSA: IEC958/HDMI (hw:0,1)
15:03:37: Device: 2: sysdefault
15:03:37: Device: 3: default
15:03:37: Device: 4: dmix
15:03:37: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8).

libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information

The CPU usage did go up to 100% at times.
I tried it a few times now and it has always completed.

Originally Posted by bdbcat

Going back to GLES and glShim on RPI would be a regression in overall performance, I fear.

As far as I can remember, there were some unresolved issues.

Originally Posted by bdbcat

Are you able to build OCPN from scratch on your device?

Thanks
Dave

I think so, might run out of room on my existing SD card.

[NahanniV]

Originally Posted by bdbcat

NahanniV...


The GL driver needs to support at least one texture compression mode. The current rPI GL driver supports none at all. So we cannot use texture compression in GL immediate mode at all.
....

pi@openplotter:~ $ glxinfo | grep ETC1       
libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
    GL_OES_compressed_ETC1_RGB8_texture, GL_OES_depth24, GL_OES_depth_texture, 
pi@openplotter:~ $