Visit our Popular Forums

seandepagnier · 25-04-2019, 09:52

I think etc compression is supported only for gles on the driver so maybe you can recompile opencpn to target gles instead and see if compression works.

transmitterdan · 25-04-2019, 18:56

Quote:

Originally Posted by boat_alexandra

I think etc compression is supported only for gles on the driver so maybe you can recompile opencpn to target gles instead and see if compression works.

How to tell cmake to use GLES on RPi?

bdbcat · 27-04-2019, 07:32

NahanniV...
Looking at this problem today.
Please check your config file for the entry:

[Settings]
GPUTextureMemSize=128

If it does not exist, or is different from 128, please change to
GPUTextureMemSize=64

OCPN tries to keep the texture memory used by the GPU to some nominal maximum value, like this: (from glChartCanvas.cpp)

Code:

    //  Delete any textures known to the GPU that
    //  belong to charts which will not be used in this render
    //  This is done chart-by-chart...later we will scrub for unused textures
    //  that belong to charts which ARE used in this render, if we need to....

    g_glTextureManager->TextureCrunch(0.8);

He uses the declared GPUTextureMemSize as a reference point.

I'm pretty sure this code is active on RPI, but will need to build some debug output to verify.

Do you have a simple method to provoke a failure due to GPU memory exhaustion?

Dave

verkerkbr · 27-04-2019, 10:33

Quote:

Originally Posted by bdbcat

NahanniV...
Looking at this problem today.
Please check your config file for the entry:

[Settings]
GPUTextureMemSize=128

If it does not exist, or is different from 128, please change to
GPUTextureMemSize=64

OCPN tries to keep the texture memory used by the GPU to some nominal maximum value, like this: (from glChartCanvas.cpp)

Code:

    //  Delete any textures known to the GPU that
    //  belong to charts which will not be used in this render
    //  This is done chart-by-chart...later we will scrub for unused textures
    //  that belong to charts which ARE used in this render, if we need to....

    g_glTextureManager->TextureCrunch(0.8);

He uses the declared GPUTextureMemSize as a reference point.

I'm pretty sure this code is active on RPI, but will need to build some debug output to verify.

Do you have a simple method to provoke a failure due to GPU memory exhaustion?

Dave

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

transmitterdan · 27-04-2019, 10:55

Quote:

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,

Can you post your entire /boot/config.txt & opencpn.conf files here? If you did already i did not find it. I cannot get good performance with real VC4 OpenGL enabled.

bdbcat · 27-04-2019, 11:04

Bram...

Experimenting some here today.
- Added instrumentation to track texture storage while running.
- Load a large set of RNCs
- Start OCPN with parameter "-unit_test_1:0"
- Watch the slide show and monitor the texture memory utilization.

Result: Texture memory grows until approximately 80% of stated config file value. Then varies up and down, as the app runs. Never exceeds specified maximum.

Conclusion: Texture memory management on RPI is working as designed.

Also, on RPI, we cannot use compressed texture caching, since the nativeGL driver does not support texture compression. Moving (back) to GLES will probably be a bad idea, since this engages the glShim library as an interface between standard GL and GLES. This will probably end up being slower than the basic GL implementation, though I have not explicitly tested this lately with the new GL driver.

Longer term, we plan to move the entire rendering library to GLES for those platforms that support it. We will get much better performance all around, as much of the grunt work will be offloaded from the CPU to the GPU, running in parallel. Implementation is not a huge task. We do this on Android already. Biggest challenge will be testing on all desktop platforms, and dealing with expected errors on older hardware.

Dave

verkerkbr · 27-04-2019, 11:06

Quote:

Originally Posted by transmitterdan

Bram,

Can you post your entire /boot/config.txt & opencpn.conf files here? If you did already i did not find it. I cannot get good performance with real VC4 OpenGL enabled.

Hi T,

the configs are on my other systeem. I will make a copy of these.

Did you try the latest updates and the latest kernel version 4.19.36-V7+ ?

I have only made some changes for the use as a headless RealVNC server with a high resolution for my chromebook VNCviewer. This in combination with a dummy HDMI dongle.

Done nothing special. The improvements are mainly in the latest software.

Regards,

verkerkbr · 28-04-2019, 01:36

Quote:

Originally Posted by transmitterdan

Bram,

Can you post your entire /boot/config.txt & opencpn.conf files here? If you did already i did not find it. I cannot get good performance with real VC4 OpenGL enabled.

Here the configs.

Nothing special. Only some settings for headless use.

NahanniV · 28-04-2019, 07:05

Quote:

Originally Posted by bdbcat

NahanniV...
Looking at this problem today.
Please check your config file for the entry:

[Settings]
GPUTextureMemSize=128

If it does not exist, or is different from 128, please change to
GPUTextureMemSize=64

OCPN tries to keep the texture memory used by the GPU to some nominal maximum value, like this: (from glChartCanvas.cpp)

Code:

    //  Delete any textures known to the GPU that
    //  belong to charts which will not be used in this render
    //  This is done chart-by-chart...later we will scrub for unused textures
    //  that belong to charts which ARE used in this render, if we need to....

    g_glTextureManager->TextureCrunch(0.8);

He uses the declared GPUTextureMemSize as a reference point.

I'm pretty sure this code is active on RPI, but will need to build some debug output to verify.

Do you have a simple method to provoke a failure due to GPU memory exhaustion?

Dave

My GPUTextureMemSize was set to 128, I have it changed to 64 now.

I do not have a simple method to provoke the problem.
It seems to often happen after a full day of navigating.
Typically this includes recording a track, encountering multiple AIS targets, and switching between many different charts.

We will be underway again soon, and I will do more testing.

bdbcat · 28-04-2019, 07:16

NahanniV....

For reference, what charts are you using?
Thanks
Dave

NahanniV · 28-04-2019, 10:14

Quote:

Originally Posted by bdbcat

NahanniV....

For reference, what charts are you using?
Thanks
Dave

In the USA I was using a mix of RNC & ENC. downloaded using the chartdownloader pi. Mostly navigating with the ENC vector charts since they had less clutter. 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.

In the Bahamas we are using scanned charts.

conachair · 28-04-2019, 10:46

Quote:

Originally Posted by NahanniV

We will be underway again soon, and I will do more testing.

Would it be an idea to record to the VDR , then the rest of us could try to replicate the problem during playback?

verkerkbr · 28-04-2019, 10:47

Quote:

Originally Posted by NahanniV

In the USA I was using a mix of RNC & ENC. downloaded using the chartdownloader pi. Mostly navigating with the ENC vector charts since they had less clutter. 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.

In the Bahamas we are using scanned charts.

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

NahanniV · 28-04-2019, 12:22

Quote:

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

After a reboot I can do the same operations that seemed to cause the failure without a failure.

What seems to be the difference is some time spent navigating.