Closed andimik closed 7 months ago
I fear I cannot help here easily. I have no Raspi to try that out and I never intended yet to run that on a Raspi.
I never changed something regarding the neon-virterbi files which I took from Qt-DAB.
Is Qt-DAB compiling in this case? If yes, I can look for differences to my project.
I read that the gcc call must be prepared for NEON with:
gcc -march=armv7-a -mfpu=neon ...
You can try changing line 38 in CMakeLists.txt from
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Werror=return-type -ffast-math")
to
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Werror=return-type -ffast-math -march=armv7-a -mfpu=neon")
end try again.
Finally if you will not got it to run you can try out switch-off also VITERBI_NEON and the CPU load goes hopefully not too high. At least on my Intel i7-6700K I feel not really a difference if I have SSE active or not.
Yes, I have Qt-DAB running on the RPI 3B and I am looking for an alternative...
To get sure: really build the Qt-DAB with the cmake switch VITERBI_NEON=ON
? If yes, can you say which version of Qt-DAB you had compiled (best would be the git commit SHA1), so got better do a comparison?
I've then switched NEON
to OFF
; and I could compile it, but the program does not work (only xx?
in the console) with any DAB signal at all.
There was just a minor warning, if you want to know it:
[ 87%] Building CXX object CMakeFiles/dabstar.dir/src/scopes-qwt6/carrier-display.cpp.o
In file included from /usr/include/c++/8/vector:69,
from /home/pi/apps/DABstar/src/scopes-qwt6/iqdisplay.h:36,
from /home/pi/apps/DABstar/src/scopes-qwt6/iqdisplay.cpp:31:
/usr/include/c++/8/bits/vector.tcc: In member function ‘void std::vector<_Tp, _Alloc>::_M_fill_insert(std::vector<_Tp, _Alloc>::iterator, std::vector<_Tp, _Alloc>::size_type, const value_type&) [with _Tp = double; _Alloc = std::allocator<double>]’:
/usr/include/c++/8/bits/vector.tcc:478:5: note: parameter passing for argument of type ‘std::vector<double, std::allocator<double> >::iterator’ {aka ‘__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >’} changed in GCC 7.1
vector<_Tp, _Alloc>::
^~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/8/vector:64,
from /home/pi/apps/DABstar/src/scopes-qwt6/iqdisplay.h:36,
from /home/pi/apps/DABstar/src/scopes-qwt6/iqdisplay.cpp:31:
/usr/include/c++/8/bits/stl_vector.h: In constructor ‘IQDisplay::IQDisplay(QwtPlot*)’:
/usr/include/c++/8/bits/stl_vector.h:847:4: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >’ changed in GCC 7.1
_M_fill_insert(end(), __new_size - size(), __x);
^~~~~~~~~~~~~~
/usr/include/c++/8/bits/stl_vector.h:847:4: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >’ changed in GCC 7.1
_M_fill_insert(end(), __new_size - size(), __x);
^~~~~~~~~~~~~~
I'll give up and close this issue because without libqwt-qt5-6
lots of installed tools will not work at all, so I have re-installed this package to get all tools back (incl. Qt-DAB, which is in old version 3.4.1 from May 2020.
@andimik : that is pity. The issue sounds like that the gcc 7.1 standard library does not fit to some vector interface. But as carrier-display.o
andiqdisplay.o
are compiled against that, there should be no issue. So I can not really explain this. Have you tried to clean the build folder and build again?
I understand further using libqwt-qt5-6
. You could install this lib and try out the DABstar version in this branch https://github.com/tomneda/DABstar/tree/qwt_6.1.4_adaption.
If it really worked for you I consider to make this official. Or I think about to have Qwt coexistent with an older version.
I will try to find the sources of this Qt-DAB version 3.4.1 from May 2020 and compare against the NEON usage there.
I also tried your hint to modify the CMakeList.txt
and use NEON, but it fails, too.
[ 94%] Building C object CMakeFiles/dabstar.dir/src/support/viterbi-spiral/spiral-neon.c.o
In file included from /home/pi/apps/DABstar/src/support/viterbi-spiral/sse2neon.h:65,
from /home/pi/apps/DABstar/src/support/viterbi-spiral/spiral-neon.c:28:
/home/pi/apps/DABstar/src/support/viterbi-spiral/sse2neon.h: In function ‘_mm_setzero_si128’:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:16143:1: error: inlining failed in call to always_inline ‘vreinterpretq_s64_s32’: target specific option mismatch
vreinterpretq_s64_s32 (int32x4_t __a)
^~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/apps/DABstar/src/support/viterbi-spiral/spiral-neon.c:28:
/home/pi/apps/DABstar/src/support/viterbi-spiral/sse2neon.h:146:36: note: called from here
#define vreinterpretq_m128i_s32(x) vreinterpretq_s64_s32(x)
^~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/apps/DABstar/src/support/viterbi-spiral/sse2neon.h:350:12: note: in expansion of macro ‘vreinterpretq_m128i_s32’
return vreinterpretq_m128i_s32(vdupq_n_s32(0));
^~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/apps/DABstar/src/support/viterbi-spiral/sse2neon.h:65,
from /home/pi/apps/DABstar/src/support/viterbi-spiral/spiral-neon.c:28:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:6733:1: error: inlining failed in call to always_inline ‘vdupq_n_s32’: target specific option mismatch
vdupq_n_s32 (int32_t __a)
^~~~~~~~~~~
In file included from /home/pi/apps/DABstar/src/support/viterbi-spiral/spiral-neon.c:28:
/home/pi/apps/DABstar/src/support/viterbi-spiral/sse2neon.h:146:36: note: called from here
#define vreinterpretq_m128i_s32(x) vreinterpretq_s64_s32(x)
^~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/apps/DABstar/src/support/viterbi-spiral/sse2neon.h:350:12: note: in expansion of macro ‘vreinterpretq_m128i_s32’
return vreinterpretq_m128i_s32(vdupq_n_s32(0));
^~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/dabstar.dir/build.make:1168: CMakeFiles/dabstar.dir/src/support/viterbi-spiral/spiral-neon.c.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:150: CMakeFiles/dabstar.dir/all] Fehler 2
make: *** [Makefile:130: all] Fehler 2
Have compiled
hackrf
andqwt
on my own, but buildingDABstar
stops at 98%:Any ideas?
This is my cmake:
This is my CPU: