GNUradio Companion 3.7x performance on Raspberry Pi 3 & 4 with vc4-fkms-v3d accelerated driver enabled

[keyboarderror]

I'm encountering an extremely sluggish GUI and poor performance in Raspbian Buster with a Raspberry Pi 4 when loading large flowgraphs. This has also started happening with the unofficial Ubuntu 18.04.3 pre-release build v12, with GRC version 3.7.11 but not in Ubuntu pre-release v10. Under pre-release v10 it's quite good. So what's wrong?

Please see TheRemote/Ubuntu-Server-raspi4-unofficial#54

[keyboarderror]

Update: It seems to work properly in the official Ubuntu 19.10. 32 bit anyway. Just FYI.

[Wayne-Weng]

I have the same issue on Raspbian Buster(Pi4B) with gnuradio v3.7.13.4 when I loaded my flow graph built on Raspbian Stretch(Pi3B+) with gnuradio v3.7.10.1. It takes forever long to update the GRC GUI. I can say that on Pi3B+ it does take a while to update GRC gui but it finishes soon. However on Pi4B it really takes forever with a cpu usage of constant 25%.

[keyboarderror]

In testing the ARM64 version of Ubuntu 19.10 runs properly with the repository GRC version 3.7.13.4 once I worked around the current USB problems on booting a pi4 with more than 1gb of ram. When only limited to 1GB, GRC will not start.

I'm unable to compile GNU radio from source using pybombs in Raspbian Buster or Ubuntu 18/19 as the process grinds to a halt and freezes up after seemingly running out of memory in the cases where I can satisfy the requirements to get it to work (Ubuntu). There's no way to compare with 3.8 or any other previous versions I set it to build for. Compiling from source alone hasn't worked. Currently v10 of unofficial Ubuntu 18.04.3 is still the best version I can use for testing when comparing graphics performance and memory. The upgrade.sh script there to bring it forward to the latest build breaks GRC along the way. It's great to see it CAN work, it'll be even better when it works where it's needed. :)

[marcusmueller]

The raspberry pi is an embedded device. Trying to compile a 400,000 lines of code C++ codebase on an embedded device failing due to limited resources isn't really a bug ;)

The appropriate way here is using cross-compilation. I think any respectable linux distro offers an easy-to-set-up way of doing a cross-build. Debian certainly does!

[marcusmueller]

The sluggish GUI behaviour is almost certainly beyond our control for now. Maybe you could enhance your bug report by adding some kind of top/htop/perf analysis on what's taking so long?

NB: X drivers for the Pi's GPU have historically always been of very varying degrees of satisfaction.

[keyboarderror]

Actually a pi can compile it. Performance monitor confirmed the memory was running out. I managed to get pybombs to complete GR 3.8 successfully on unofficial 18.04 after following the steps at https://wiki.gnuradio.org/index.php/InstallingGRFromSource_on_Raspberry_Pi and creating a 8GB swap file. 2 Gigabytes is insufficient, it should be at least 4GB. But I'm getting PYTHONPATH errors trying to run it and it looks like the setup_env.sh points to python 2.6 when what's compiled is python 2.7. I also tried cross-compiling with similar results. So more troubleshooting is needed. I may try on Buster as well. I really think it's a graphics problem of some sort which makes me wonder if it will happen on other OS versions as drivers and firmware develop.

[keyboarderror]

I'm going to try building on Buster as the guide says it's been tested. The problem gets worse depending on the size of the flowgraph.

[keyboarderror]

GR 3.9 builds from source manually on Buster. GRC Interface is working properly with flowgraphs as far as I can tell without gr-osmosdr. But the bug may have been addressed. Just need a way to get gr-osmosdr working...

Pybombs does not work automatically as it tried to compile UHD with neon support. You must specify not to use it when compiling UHD with cmake -DNEON_SIMD_ENABLE=OFF ..

[velichkov]

Hi @keyboarderror,

Just need a way to get gr-osmosdr working...

You could try compiling the gr3.8 branch from igorauad's fork. Also have a look at debian's package repo.

[keyboarderror]

@velichkov Thank You! I did find one from https://github.com/fmdxpl/gr-osmosdr that partially enabled things and proved the interface still works. I've set that aside temporarily to try a 3.7 build just to see if there's a difference.

[keyboarderror]

Compiled GRC 3.7.13.5 has the bug. Next to try 3.9 again in Ubuntu.

[keyboarderror]

Compiled 3.9 GRC works on Ubuntu 18.04.

So to sum up there is a graphics and performance bug with flowgraph size in versions 3.7x of gnuradio-companion with certain possible video settings on the Raspberry Pi 4 and probably 3. This may well be solved through the natural progression to GNU radio 3.9 and beyond. Should anyone know what it is or figure it out anyway that would be great.

[keyboarderror]

I found the culprit. Disabling the Pi 4's accelerated video driver allows Gnuradio Companion 3.7x to operate normally. A test confirms this also applies to the RPi3.

Comment out dtoverlay=vc4-fkms-v3d in your config.txt as a work around.

[rrrRbert360]

The (similar) problem I'm facing with GNURadio and RPi4 is that osmocom- and RTL-sources give troubles resulting in interrupted audio as shown here
Gqrx2.11.5(qt5.11.3 based) is working perfectly fine with RTL-SDR on the same RPi4.
My setup: RPi4(c03112, 4Gb, 32GB-SD) gnuradio:3.7.13.4-4+b1 gr-osmosdr:0.1.4-14+b7 rtl-sdr:0.6-1+rpt1
The same grc-file(and the grc example file in this thread) and RTL-stick are working perfectly on a Ubuntu laptop.
I'm not sure if this is the right place to ask, but does anyone have RPi v4 and FM-radio audio working with GNURadio?

[keyboarderror]

I think that is a separate issue with GNU Radio 3.7 on the Pi. As they are binary packages GQRX may not share the same problems. I can replicate it in 3.7 and confirm it works properly on a Pi4 with a compiled GNU Radio 3.8.1. The workaround makes no difference. You may want to open another ticket or pursue your attempts there.