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.

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@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. >

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 <kmcg3413@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.

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" ../ 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 <kmcg3413@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 >

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 <kmcg3413@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 >

On 11/10/2017 06:41 AM, Philip Balister via USRP-users 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. Also, another quick look suggests neon for aarch64 is no longer built. Philip > > 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 <kmcg3413@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 >

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@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 <kmcg3413@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

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 <kmcg3413@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 >

On 11/10/2017 06:52 AM, Philip Balister via USRP-users wrote: > On 11/10/2017 06:41 AM, Philip Balister via USRP-users 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. > > Also, another quick look suggests neon for aarch64 is no longer built. Never mind. The code to allow the neon convertors to build for aarch64 never made it into uhd. Philip > > Philip > > >> >> 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 <kmcg3413@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 >