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

Philip Balister philip at balister.org
Fri Nov 10 07:00:46 EST 2017


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 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
> 
> _______________________________________________
> 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