On 11/10/2017 06:57 AM, Gwenhael Goavec-Merou via USRP-users wrote: > I've some difficults to understand because the piece of code impacted > by this patch is only use if HAVE_ARM_NEON_H is true. > Then I suppose if the CPU is an ARM but has no neon this test is false > and then this part is not used. > It's seems logical because c and asm files added in this section are > neon related. No?
The compiler having the header file does not mean the target device has the neon execution unit. Philip > > Gwen > > On Fri, 10 Nov 2017 06:41:10 -0500 > Philip Balister via USRP-users <usrp-users@lists.ettus.com> wrote: > >> On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote: >>> I guess this is a little late, but you can pass in compiler flags >>> on the command line with -DCMAKE_CXX_FLAGS. For example: >>> >>> cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon >>> -mtune=cortex-a15" ../ >> >> That would be the preferred way. The patch mentioned assumes that >> anytime you are using a compiler with the neon.h header file, the SoC >> you are compiling for has a neon unit. This is a bad assumption. There >> are a few examples of SoC's around that do not have a neon unit. Now >> UHD will generate neon and create runtime failures. >> >> Bottom line, in the ARM world, you cannot test compiler features to >> figure out what features the runtime system has. >> >> Philip >> >> >>> >>> Ron >>> >>> On 11/10/2017 12:07 AM, Gwenhael Goavec-Merou via USRP-users >>> wrote: >>>> Hello, >>>> >>>> maybe this : https://github.com/EttusResearch/uhd/pull/135 >>>> will help you >>>> >>>> Gwen >>>> >>>> On Fri, 10 Nov 2017 00:29:25 -0600 >>>> Kevin McGuire via USRP-users <usrp-users@lists.ettus.com> wrote: >>>> >>>>> I was able to get the compiler flags passed in so that the check >>>>> for the header arm_neon.h passes. I added it to the CMakeList >>>>> root file with SET(CMAKE_CXX_FLAGS, "${CMAKE_CXX_FLAGS} >>>>> -mfloat-abi=softfp -mfpu=neon"). >>>>> >>>>> Then, it would detect neon. However, I spent considerable time >>>>> cleaning up whatever package problems I had since I ended up with >>>>> a bunch of weird errors. >>>>> >>>>> Once I straightened my packages up (Debian), it is compiling with >>>>> neon! And, hopefully, it will actually use the ARM neon routines. >>>>> >>>>> On Thu, Nov 9, 2017 at 3:22 AM, Kevin McGuire <kmcg3...@gmail.com> >>>>> wrote: >>>>> >>>>>> I have noticed that neon support for the converter is not >>>>>> enabling. The CMakeError.log has this output. I am not certain >>>>>> as I am not really familiar with ARM and NEON, but I checked my >>>>>> CPU and it does support it. Also, the error message below is >>>>>> saying it is just a matter of passing certain flags. >>>>>> >>>>>> /mnt/extra/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_neon.h:32:2: >>>>>> error: #error You must enable NEON instructions (e.g. >>>>>> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h >>>>>> #error You must enable NEON instructions (e.g. >>>>>> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h >>>>>> >>>>>> Normally, I would just fix it myself and move forward, but me and >>>>>> CMake mix like oil and water. It is kind of embarrassing but I >>>>>> swear it never does what I want it do - such as adding a darn >>>>>> flag. I even tried to force the options, lol, and all be danged >>>>>> if CMake finds some way to error. >>>>>> >>>>>> Will work on this tomorrow, but if anyone has a solution I am all >>>>>> ears. If not then no problem and I will reply when I figure it >>>>>> out. >>>>>> >>>>>> This came about when I noticed what really seemed like abnormally >>>>>> high CPU usage on my ARM code for a simple shuffling of data out >>>>>> of the network packets. I traced what I felt like was the biggest >>>>>> possible hot spot to the converter routine. Anyway, that is my >>>>>> plan right now, to see if NEON might help if the converter is >>>>>> having to swap byte order. >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
