Forum: GNU Radio Work around for gr.multiply_cc( ) for non NEON enabled ARM devices

Posted by Karl Petrow (Guest)
on 2013-02-14 16:21
(Received via mailing list)
Has anyone developed a work around for replacing gr.multiple_cc() to 
work on ARM devices that have to disable NEON in order to install?  I 
have two lines in gr.ais that keep giving me overflow.

Thanks ahead of time,

karl
Posted by Tom Rondeau (Guest)
on 2013-02-14 16:44
(Received via mailing list)
On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow <
kpetrow@maritimeinfosystems.com> wrote:

> karl
>

You can turn it off. Have you run 'volk_profile' on the system, yet? If 
so,
that would have generated a ~/.volk/volk_config. You can edit that file 
by
hand to specify the architecture you want as 'generic' for whatever 
kernel
is causing you trouble. This just runs a standard C for loop with no 
SIMD
instructions (except whatever the compiler tries to do).

Tom
Posted by Karl Petrow (Guest)
on 2013-02-15 18:22
(Received via mailing list)
The Pi is having some problems running:
sudo volk_profile

It pegs out at 100% and I just cut it at 24 hours.  I am going to reboot 
and run it on terminal only with it overclocked for the weekend, but do 
you have any other suggestions?  I was really excited about Volk after 
reading up on it, but unfortunately it seems to be too much for the RPi.

Thanks

karl

From: trondeau@trondeau.com [mailto:trondeau@trondeau.com] On Behalf Of 
Tom Rondeau
Sent: Thursday, February 14, 2013 10:42 AM
To: Karl Petrow
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for 
non NEON enabled ARM devices

On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow 
<kpetrow@maritimeinfosystems.com<mailto:kpetrow@maritimeinfosystems.com>> 
wrote:
Has anyone developed a work around for replacing gr.multiple_cc() to 
work on ARM devices that have to disable NEON in order to install?  I 
have two lines in gr.ais that keep giving me overflow.

Thanks ahead of time,

karl

You can turn it off. Have you run 'volk_profile' on the system, yet? If 
so, that would have generated a ~/.volk/volk_config. You can edit that 
file by hand to specify the architecture you want as 'generic' for 
whatever kernel is causing you trouble. This just runs a standard C for 
loop with no SIMD instructions (except whatever the compiler tries to 
do).

Tom
Posted by Marcus D. Leech (Guest)
on 2013-02-15 18:28
(Received via mailing list)
> too much for the RPi.
>
>
>
> Thanks
>
>
>
> karl
>
A tangential comment here.  You never need to run ordinary commands as
root.  The only part of any source
  code build that usually requires root privilege (via sudo) is the
install phase, because that's moving generated
  code into parts of the system that you, as an ordinary user, can't
write to.

But running your applications, building code, etc, *don't* require root
privilege.
Posted by Nathan West (Guest)
on 2013-02-15 19:09
(Received via mailing list)
On Fri, Feb 15, 2013 at 11:26 AM, Marcus D. Leech <mleech@ripnet.com> 
wrote:
>
I'm not sure if you've seen some of the RPi/gnuradio commentary, but
this is a good summary:
https://lists.gnu.org/archive/html/discuss-gnuradi...

The first test that volk_profile runs
(volk_32fc_s32fc_x2_rotator_32fc_a) takes several minutes on my Core2
duo. I would also expect it to take a very long time on an RPi. That
said, the discussion previously linked would make me think that
running volk_profile on an RPi wouldn't actually do anything useful as
there's no SIMD architecture to take advantage of. Everything would be
set to generic after running for a long time which is the same result
as not running volk_profile at all (minus days of runtime).

If you want to test this you can remove that first test from
volk_profile and rebuild. The subsequent tests will probably take
about 10-20 minutes each but you might actually see some progress.

>   code build that usually requires root privilege (via sudo) is the install
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>




-nathan
Posted by Tom Rondeau (Guest)
on 2013-02-15 19:10
(Received via mailing list)
On Fri, Feb 15, 2013 at 12:21 PM, Karl Petrow <
kpetrow@maritimeinfosystems.com> wrote:

>
> ** **
>
> Thanks****
>
> ** **
>
> karl
>

You can edit volk/apps/volk_profile.cc and change the the number of 
samples
and iterations it runs for each kernel. The function call is (from
volk/lib/qa_utils.h):

#define VOLK_PROFILE(func, tol, scalar, len, iter, results)

So len and iter can be decreased for your processor's needs.

Tom
Posted by Nathan West (Guest)
on 2013-02-15 19:19
(Received via mailing list)
Ah, I neglected the context of wanting to run volk_profile. Sorry! :-)

You might first try just manually creating ~/.volk/volk_config and
setting whatever kernel you need set to generic. Unless I'm mistaken
you don't really need to whole config.
Posted by Karl Petrow (Guest)
on 2013-02-19 18:15
Attachment: volk_profile.cc (10,1 KB)
(Received via mailing list)
I recompiled the program with commenting out all non-multiply 
kernels(see attached).  Still pegged out for 2 hours and still going. 
Do you know specifically which kernel relates to the multiply_cc 
function?

Thanks again,

kyp

From: trondeau@trondeau.com [mailto:trondeau@trondeau.com] On Behalf Of 
Tom Rondeau
Sent: Friday, February 15, 2013 1:09 PM
To: Karl Petrow
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for 
non NEON enabled ARM devices

On Fri, Feb 15, 2013 at 12:21 PM, Karl Petrow 
<kpetrow@maritimeinfosystems.com<mailto:kpetrow@maritimeinfosystems.com>> 
wrote:
The Pi is having some problems running:
sudo volk_profile

It pegs out at 100% and I just cut it at 24 hours.  I am going to reboot 
and run it on terminal only with it overclocked for the weekend, but do 
you have any other suggestions?  I was really excited about Volk after 
reading up on it, but unfortunately it seems to be too much for the RPi.

Thanks

karl

You can edit volk/apps/volk_profile.cc and change the the number of 
samples and iterations it runs for each kernel. The function call is 
(from volk/lib/qa_utils.h):

#define VOLK_PROFILE(func, tol, scalar, len, iter, results)

So len and iter can be decreased for your processor's needs.

Tom


From: trondeau@trondeau.com<mailto:trondeau@trondeau.com> 
[mailto:trondeau@trondeau.com<mailto:trondeau@trondeau.com>] On Behalf 
Of Tom Rondeau
Sent: Thursday, February 14, 2013 10:42 AM
To: Karl Petrow
Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for 
non NEON enabled ARM devices

On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow 
<kpetrow@maritimeinfosystems.com<mailto:kpetrow@maritimeinfosystems.com>> 
wrote:
Has anyone developed a work around for replacing gr.multiple_cc() to 
work on ARM devices that have to disable NEON in order to install?  I 
have two lines in gr.ais that keep giving me overflow.

Thanks ahead of time,

karl

You can turn it off. Have you run 'volk_profile' on the system, yet? If 
so, that would have generated a ~/.volk/volk_config. You can edit that 
file by hand to specify the architecture you want as 'generic' for 
whatever kernel is causing you trouble. This just runs a standard C for 
loop with no SIMD instructions (except whatever the compiler tries to 
do).

Tom
Posted by Nick Foster (Guest)
on 2013-02-19 20:08
(Received via mailing list)
I'm a little confused here. The RPi has no NEON unit. So Volk, which is
designed to accelerate common functions for vector processing units like
NEON, won't actually do anything on RPi; every kernel executed will be
the unaccelerated generic version. I understand the motivation behind
Tom's earlier suggestion to fix Volk on non-NEON ARM devices by forcing
all kernels to "generic" in volk_config, but I don't understand the
reason to attempt to get volk_profile to run on a device which doesn't
support anything other than the generic kernels.

That said, Volk includes a routine to detect NEON support on ARM
platforms (volk/tmpl/volk_cpu.tmpl.c:static int has_neon(void)), and
should correctly refuse to run NEON kernels on non-NEON platforms,
although I only have one report from a user who tested the negative case
(no NEON) successfully. So all this is to say I have no idea why
volk_profile is hanging, but it's pointless to run it on your platform
anyway. If you really still want to run volk_profile, try turning down
the number of iterations of each routine to 1 or something and see if it
completes for you.

--n
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.