[USRP-users] Compiling UHD Host Library: Problem Enabling ARM Neon Support

Gwenhael Goavec-Merou gwenj at trabucayre.com
Fri Nov 10 06:57:03 EST 2017


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?

Gwen

On Fri, 10 Nov 2017 06:41:10 -0500
Philip Balister via USRP-users <usrp-users at 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 at 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 <kmcg3413 at 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 at lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>  
> > 
> > 
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >   
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




More information about the USRP-users mailing list