64-bit ARM support?

[ajmas]

Has anyone been able to build this on a 64-bit Raspbian install? Asking in part to see the status, since I am looking at a RPi 4, and in part to see what work needs to be done if not, for 64-bit support in general?

[danmilon]

yeah I've compiled it fine on aarch64 (64-bit armv8), but you should know that GPU FFT isn't supported on RPi 4, but it should have plenty of resources to do the FFT on the CPU for 4 rtlsdr devices (the most you can have before saturating the USB bandwidth of the USB2 controller on the raspberry).

[ajmas]

Is this a hardware or software limitation on the RPi4?

BTW it would appear that GPU FFT was achievable using the GPU_FFT library on previous versions of the Pi, though the library does not seem to have been updated since 2014: https://www.raspberrypi.org/blog/accelerating-fourier-transforms-using-the-gpu/

BTW the library is part of the Raspbian code base, but the original author has no plans to continue working on it: https://github.com/raspberrypi/firmware/tree/master/opt/vc/src/hello_pi/hello_fft

[danmilon]

right, it's just that the gpu_fft lib is tightly-coupled to the broadcom gpu shipped on rpi2/3. the rpi4 uses a different model.

IMO a hardware-independent solution could be developed that uses opengl ES 3.0 to do the FFT on the GPU. Most recent SBCs support ES 3.0. (e.g. Orange PI 3, RPI4). There's this library https://github.com/Themaister/GLFFT that does that, but IDK how hard it would be to integrate it into rtlsdr-airband.

[ajmas]

Discussing on the RPi forums it was suggested the use of NEON FFT. While it is CPU based, rather than GPU based, a single core could be dedicated to it.

I can’t say what the comparative performance is like, but it should at least offer an alternative way forward. It would also be interesting to compare to GLFFT, if it is made to work.