GNU Radio release 3.6.3 available for download

GNU Radio
21

On Jan 23, 2013, at 10:34 AM, Tom R. [email protected] wrote:

On Wed, Jan 23, 2013 at 10:29 AM, Michael D. [email protected] wrote:
I’m wondering what “volk_profile” is doing? It looks like it’s running through
(all?) available kernels for a given algorithm and finding the “best” (fastest?)
one. Is this correct?

Yes, that’s correct. It runs each proto-kernel available on your machine and
compares how long it took to execute them, then it stores the fastest version in
the config file. This is then read when your program initializes a new VOLK kernel
to find the right one to use.

Ah; OK. Sort of like what FFTW does for fft’s, but probably with its
own twist. So if the “volk_config” file exists, VOLK reads it and uses
it to determine which kernel to use for a given VOLK algorithm
instantiation. [Is there a proper VOLK-like name for a “VOLK algorithm
instantiation”?] If this file does not exist, how does VOLK pick the
kernel? Is this info somewhere in a Wiki? I haven’t looked, so forgive
me if I’m asking FAQ’s. - MLD

22

On Wed, Jan 23, 2013 at 10:43 AM, Michael D. [email protected]
wrote:

a new VOLK kernel to find the right one to use.

Ah; OK. Sort of like what FFTW does for fft’s, but probably with its own
twist. So if the “volk_config” file exists, VOLK reads it and uses it to
determine which kernel to use for a given VOLK algorithm instantiation.
[Is there a proper VOLK-like name for a “VOLK algorithm instantiation”?]
If this file does not exist, how does VOLK pick the kernel? Is this info
somewhere in a Wiki? I haven’t looked, so forgive me if I’m asking FAQ’s.

  • MLD

We call the “VOLK algorithm instantiations” VOLK proto-kernels.

When the volk_config file doesn’t exist or if it does not contain a
reference to the kernel (say you’ve installed a new version and did not
update your profile), then VOLK takes the set of proto-kernels that your
machine can run and selects the ‘highest’ version. So ACX > SSE4 > SS2 >
MMX, etc. While this isn’t always the best kernel to use on a given
machine, it’s definitely the best way to select barring other
information.

Will have to check the wiki to see how complete it currently is. Also,
we
just published a paper describing VOLK at the SDR conference. I should
upload that to the website.

Tom

23

Albert - Tom (as a VOLK developer) has some good advice:

(1) Try installing GNU Radio without the +orc variant, and seeing what
the configure output is; combined with:

(2) Run “volk_profile” after you’ve installed GNU Radio. It will test
all of the kernels and create a $HOME/.volk/volk_config file. If you
look in that file, it will tell you what architectures are to be used
for each kernel.

Tom - I’m wondering what “volk_profile” is doing? It looks like it’s
running through (all?) available kernels for a given algorithm and
finding the “best” (fastest?) one. Is this correct?

On Jan 23, 2013, at 9:50 AM, Tom R. [email protected] wrote:

This is the same command as above, or am I missing something?

The differences in Albert’s -original- install command and mine is the
“-d”: enable debug output; and “configure” instead of “install”. My
goal is to have the GNU Radio configuration stage printout what it is
doing within the MacPorts environment; one can then cherry pick the
specific lines related to VOLK (architectures / machines) and send them
to the list for the VOLK developers. I have no practical developer
knowledge of VOLK, but I’m sure there are folks on this list who do and
can make sense of the output.

So, for my ~2009 MacBook Pro, Core 2 Duo and MacPorts GCC 4.7 (latest),
I get:

– CPU width is 64 bits, Overruled arch 32
– Available architectures:
generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
– Available machines:
generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc;avx_64_mmx_orc

On Albert’s computer with Quad-core Core i7 and similar software, he
gets:

– CPU width is 64 bits, Overruled arch 32
– Available architectures:
generic;64;3dnow;abm;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2
– Available machines:
generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_1_64_orc

  • MLD
24

I have tried your instructions on my MacBook Pro 3.1 running Mountain
Lion. I get the following error after going into the boost directory.
How can I fix this? I’v tried several chown changes with no success. I
can do a build as non sudo but no install. Exact same issue with that.

—> Computing dependencies for boost
could not read
“/Users/hanspeterfoeste/Desktop/tmp-boost/boost/Portfile”: permission
denied
Please see the log file for port boost for details:
/opt/local/var/macports/logs/_Users_hanspeterfoeste_Desktop_tmp-boost_boost/boost/main.log

In addition, the main.log is not written so not sure where to go from
here.

Thanks

Hans

Michael D. wrote in post #1091611:

On Jan 9, 2013, at 9:41 AM, Michael D. [email protected] wrote:

On Jan 8, 2013, at 4:35 PM, Johnathan C. [email protected] wrote:

GNU Radio release 3.6.3 is available here:

For Mac OS X GNU Radio users: This morning (1/9) I updated the MacPorts’
install
to this release (“gnuradio”) as well as the latest GIT master
(“gnuradio-devel”)
and next (“gnuradio-next”).

I forgot to mention: MacPorts’ boost port is currently at 1.52 – the
latest release – which has bugs in the way it handles threads, does not
work with GNU Radio (and, it seems, many other projects), and hence has
been removed from the GNU Radio acceptable versions. The fix is already
in place for 1.53, but this release has not yet been made. Thus, in the
mean time you can manually reinstall 1.51, or activate any version of
boost from 1.35 to 1.51.

Follow these commands to manually reinstall 1.51:

cd ~/Desktop
mkdir tmp_boost
cd tmp_boost
svn co -r 98466
http://svn.macports.org/repository/macports/trunk/dports/devel/boost
cd boost
sudo port build

You can add variants after “build” if you want; just make sure that
those variants are also added after the “install” command below.
Assuming the build succeeds, then do:

ff=port installed boost | sed -e "1d" -e "s@(active)@@g"
sudo port -f deactivate $ff
sudo port install

and, remember to add any variants from “build” above after “install”.
You can clean up this install via:

cd Desktop
sudo rm -rf tmp_boost

Once this install or boost succeeds, you should be ready to go with
installing and/or using GNU Radio in MacPorts. If one of the GNU Radio
ports is already installed, it should now “just work” without having to
be reinstalled.

Remember to not upgrade boost until 1.53 is available via MacPorts. I
hope that Boost 1.53 will be released soon, to take care of this issue
(and, I’m sure, others). If you are using MacPorts and have questions
about this, feel free to ping me. - MLD

25

[New subject line]

Albert sent me the build log for:

{{{
sudo port install gnuradio +full configure.compiler=macports-gcc-4.7
}}}

and I can replicate the error on my computer; so, this must be a GCC 4.7
(or, MacPorts’s GCC 4.7) issue. The error is:

{{{
build/volk/lib/volk_cpu.c:54:no such instruction: `xgetbv’
}}}

VOLK folks: what other info do you need from me/us to address this
issue? - MLD

26

On 01/24/2013 07:37 AM, Michael D. wrote:

{{{
build/volk/lib/volk_cpu.c:54:no such instruction: `xgetbv’
}}}

VOLK folks: what other info do you need from me/us to address this issue? - MLD
This is a compiler problem. xgetbv was added to vanilla GCC in 4.4.
Apparently MacPorts’ mutant GCC hasn’t added it as of 4.7. The relevant
check is line 128 of volk/lib/CMakeLists.txt. We could just disable AVX
support on GCC < 4.7, but since 4.7 is basically the latest GCC out
there it seems a little aggressive to disable AVX for everyone. I’d
rather disable AVX on Mac. I haven’t done Mac-specific platform
detection in CMake; can anyone else suggest a Mac test to use here to
disable AVX on Mac?

–n

27

Hi, Tom and Michael,

Here is part of the message when I configure to use gcc 4.7 without orc
support(and the build was failed)

====================
– ORC support not found, Overruled arch orc
– Check size of void*[8]
– Check size of void*[8] - done
– CPU width is 64 bits, Overruled arch 32
– Available architectures:
generic;64;3dnow;abm;popcount;mmx;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
– Available machines:
generic;sse2_64_mmx;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64_mmx
– Did not find liborc and orcc, disabling orc support…

For volk_profile output, I’ll put it on my public folder of Dropbox
since it’s lengthy.

volk_profile output with ORC support:
https://dl.dropbox.com/u/31960195/volk_profile_output.txt

volk_profile output without ORC support:
https://dl.dropbox.com/u/31960195/volk_profile_output_no_orc.txt

Before MacPorts has GNU Radio packages, I always need to build gnuradio
by myself. I remember that I need to modify some files in VOLK in order
to support optimization for AVX. I don’t remember the exact reason, but
it’s related to Apple assembler and probably xgetbv(?) instruction
set. Here is the version of Apple assembler:

Apple Inc version cctools-836, GNU assembler version 1.38

I wonder if I can use the latest GNU assembler with VOLK?

Thank you very much!

Albert

Michael D. [email protected] writes:

28

Hi Nick - I’ll also query the MacPorts developers with respect to this
issue, to see if they can address it instead of GR folks trying to work
around some Mac-specific idiosyncrasy. Can you point me to a changelog
or something equivalent which shows that AVX support is in the mainline
GCC as of 4.4? And, also, what exactly is AVX support in the first
place? I assume it’s some variant on SIMD related to SSE1/2/3/4 or the
like? - MLD

29

Nick F. [email protected] writes:

everyone. I’d rather disable AVX on Mac. I haven’t done Mac-specific
platform detection in CMake; can anyone else suggest a Mac test to use
here to disable AVX on Mac?

Hi, Nick and Michael,

After digging into this issue, I found an answer on MacPorts list, and
it’s related to Apple’s ancient assembler(version 1.38). In this post,
they try to replace Apple /usr/bin/as by clang’s assembler.

http://lists.macosforge.org/pipermail/macports-dev/2011-October/016335.html

I tried this approach to compile gnuradio with gcc 4.7, it’s still not
successful. But it seems to be an interesting and possible way – to use
clang’s assembler to optimize for AVX on MacOSX. GNU binutil on MacOSX
does not come with GNU assembler, so gcc 4.7 on MacOSX uses the built-in
GNU assembler, which is very old and does not support AVX. Only clang’s
assembler on MacOSX provides support to AVX instruction set.

Albert

30

On Jan 25, 2013, at 10:06 AM, Michael D. [email protected] wrote:

  1. Does the target compiler’s assembler support the “xgetbv” instruction?

  2. Does the target CPU support the “xgetbv” instruction?

My CMake hack wasn’t quite right: only execute the binary if not
cross-compiling. I’m not sure my new version is quite correct, but it’s
closer. I’ve pushed a branch with these mods: volk_xgetbv_cmake_test in
gnuradio.org/michaelld .

Some MacPorts folks did reply back to my query, and the state of Apple’s
“as” is the same as before. So, GCC is correctly recognizing and
generating the “xgetbv” instruction, but Apple’s assembler is erroring
on it. Apple’s Clang assembler recognizes this instruction correctly,
but my computer’s CPU does not support it.

Hope this helps. - MLD

31

On Jan 25, 2013, at 1:19 AM, Albert Chun-Chieh H.
[email protected] wrote:

GNU assembler, which is very old and does not support AVX. Only clang’s
assembler on MacOSX provides support to AVX instruction set.

Hi Albert - Nice sleuthing! I don’t generally read the MacPorts
developers’ list emails unless they are addressed to me; hence, that
thread slipped through my reading. It seems like this issue has
multiple parts:

  1. Does the target compiler’s assembler support the “xgetbv”
    instruction?

  2. Does the target CPU support the “xgetbv” instruction?

Here’s my “hack” attempt. Add the following code to
lib/volk/CMakeLists.txt:132

{{{
if(CPU_IS_x86)
execute_process(COMMAND ${CMAKE_C_COMPILER} -o
${CMAKE_CURRENT_BINARY_DIR}/temp
${CMAKE_CURRENT_SOURCE_DIR}/test_xgetbv.c
OUTPUT_QUIET ERROR_QUIET
RESULT_VARIABLE avx_compile_result)
if(NOT ${avx_compile_result} EQUAL 0)
OVERRULE_ARCH(avx “Compiler missing xgetbv”)
else()
message(STATUS “Executing temp”)
execute_process(COMMAND ${CMAKE_CURRENT_BINARY_DIR}/temp
OUTPUT_QUIET ERROR_QUIET
RESULT_VARIABLE avx_exe_result)
if(NOT ${avx_exe_result} EQUAL 0)
OVERRULE_ARCH(avx “CPU missing xgetbv”)
endif()
endif()
file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/temp)
endif()
}}}

and add the file lib/volk/test_xgetbv.c :

{{{
static inline unsigned long long _xgetbv(unsigned int index) {
unsigned int eax, edx;
asm volatile(“xgetbv” : “=a”(eax), “=d”(edx) : “c”(index));
return ((unsigned long long)edx << 32) | eax;
}

int main (void) {
(void) _xgetbv(0);
return (0);
}
}}}

I tried to do this solely in cmake using “file(WRITE )”, but it never
wrote the file (latest cmake, btw). Hence, using a separate file for
the test.

On my system, this test result in cmake output “Compiler missing xgetbv,
Overruled arch avx” which is as desired. If I switch the asm line
to instead read:
{{{
asm (“.byte 0x0f, 0x01, 0xd0” : “=a”(eax), “=d”(edx) : “c”(index));
}}}
then this test results in “CPU missing xgetbv, Overruled arch avx”,
which is again as desired. It would also be good for someone to test
this on a system which -does- support xgetbv to make sure it works
successfully.

I’ll let the VOLK-powers-that-be determine if this test makes any sense
to include, or something like it, but IMHO it’s wiser to actually -test-
for a feature when reasonably possible rather than assume it based on
standard information such as program version. :slight_smile: - MLD

32

On Fri, Jan 25, 2013 at 11:28 AM, Michael D. [email protected]
wrote:

Some MacPorts folks did reply back to my query, and the state of Apple’s
“as” is the same as before. So, GCC is correctly recognizing and
generating the “xgetbv” instruction, but Apple’s assembler is erroring on
it. Apple’s Clang assembler recognizes this instruction correctly, but my
computer’s CPU does not support it.

Hope this helps. - MLD

By the way, if you grep for xgetbv in the ‘next’ branch, we did some
work
for this problem there but apparently not on ‘master.’ Not sure if it’s
for
this exact problem or just a related one, but might be something to look
at.

Tom

33

On 01/25/2013 08:30 AM, Michael D. wrote:

BTW> See also Intel’s documentation on how to go about detecting AVX: <
http://software.intel.com/sites/default/files/m/0/5/7/7/f/19151-AVX_319433_005.pdf
, page 2-2 specifically. Maybe this could be made a runtime check, paired with a
configure-time preliminary check? - MLD

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

There’s already a runtime check for AVX in Volk, same as for the rest of
the SIMD instruction sets. Compile-time support and runtime support
arecompletely decoupled from each other.

–n

34

On Jan 25, 2013, at 1:10 PM, Nick F. [email protected] wrote:

There’s already a runtime check for AVX in Volk, same as for the rest of the
SIMD instruction sets. Compile-time support and runtime support are completely
decoupled from each other.

Ah; good! Always best to do it that way :slight_smile: - MLD

35

BTW> See also Intel’s documentation on how to go about detecting AVX: <

, page 2-2 specifically. Maybe this could be made a runtime check,
paired with a configure-time preliminary check? - MLD

36

On Jan 25, 2013, at 12:20 PM, Tom R. [email protected] wrote:

By the way, if you grep for xgetbv in the ‘next’ branch, we did some work for
this problem there but apparently not on ‘master.’ Not sure if it’s for this exact
problem or just a related one, but might be something to look at.

It looks like there are 3 primary files related to this issue, in both
master and next (found via “grep -inr xgetbv .” from the top-level
source directory of each):

volk/tmpl/volk_cpu.tmpl.c
volk/gen/archs.xml
volk/lib/CMakeLists.txt

and, these are about the same between those 2 branches. So, not sure to
what changes you’re referring, but in my reading they don’t seem to
impact this particular issue significantly. - MLD

BTW> Supposedly Qt does both configure-time and runtime detection and
handling of AVX (as well as SSE 1/2/3/4 and so forth). I know of their
configure-time parameters (handled in QMake), but I’m not aware of their
runtime system. Might be worth investigating.

37

Mike,

I’ve been avidly following this thread, since I recently had to
upgrade (company policy) to OSX 10.8, and I wanted to get my
gnuradio install running again at the 3.6.3 release.

It looked like things had mostly settled down, so I made sure any
old files were uninstalled, and tried
the steps below, gleaned from this thread, but in the end
there was no executable command “gnuradio-companion” anywhere
to be run. All that showed up was gnuradio-config-info, even after
reboot.

Any ideas? $PATH & $PYTHONPATH appear to be set right:

[eds-mac:~] edwardc% echo $PATH
/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin

[eds-mac:~] edwardc% echo $PYTHONPATH
/opt/local/lib/python2.7/site-packages:/usr/local/lib/python2.7/site-packages
[eds-mac:~] edwardc%

I’m stumped! Even spotlight can’t find gnuradio-companion, so something
must have failed, but what? I got no error messages during the builds.

@(^.^)@ Ed

STEP 1. Downgrade Boost

bash-3.2$ mkdir tmpboost
bash-3.2$ cd tmpboost/
bash-3.2$ svn co -r 98466 http://svn.macports.org/repository/macports
… svn messages…
bash-3.2$ cd boost
bash-3.2$ sudo port build
… port messages …
bash-3.2$ sudo port installed boost*
The following ports are currently installed:
boost @1.50.0_0
boost @1.52.0_1+no_single+no_static+python27 (active)
bash-3.2$ sudo port
[tmpboost/boost] > activate [email protected]_0
—> Computing dependencies for boost
—> Deactivating boost @1.52.0_1+no_single+no_static+python27
—> Cleaning boost
—> Activating boost @1.50.0_0
—> Cleaning boost
[tmpboost/boost] >

STEP 2. Install uhd

[tmpboost/boost] > variants uhd
uhd has the variants:
debug: Enable debug binaries
docs: build documentation
examples: enable examples
libusb: enable USB support via libusb version 1.0
manual: build manual
python26: Build UHD for Python 2.6
* conflicts with python27
[+]python27: Build UHD for Python 2.7
* conflicts with python26
tests: enable tests
universal: Build for multiple architectures
[tmpboost/boost] > install uhd +libusb +docs +python27
configure.compiler=llvm-gcc-4.2
… lots of ports messages …
[tmpboost/boost] > installed boost*

The following ports are currently installed:
boost @1.50.0_0
boost @1.52.0_1+no_single+no_static+python27 (active)

[tmpboost/boost] > activate [email protected]_0

—> Computing dependencies for boost
—> Deactivating boost @1.52.0_1+no_single+no_static+python27
—> Cleaning boost
—> Activating boost @1.50.0_0
—> Cleaning boost
[tmpboost/boost] >

STEP 3. Install gnuradio

[tmpboost/boost] > variants gnuradio
gnuradio has the variants:
debug: Enable debug binaries
docs: Install GNU Radio documentation
full: Enable all variants except python (and, for next, ctrlport)
* requires docs grc jack orc portaudio qtgui sdl swig uhd wavelet
wxgui
grc: Install GNU Radio Companion
* requires swig
jack: Install GNU Radio with support for JACK audio
orc: Install GNU Radio Volk with support for ORC
portaudio: Install GNU Radio with support for portaudio audio
python26: Build GNU Radio using Python 2.6
* conflicts with python27
[+]python27: Build GNU Radio using Python 2.7
* conflicts with python26
qtgui: Install GNU Radio with support for Qt GUI
sdl: Install GNU Radio with support for SDL-based video
swig: Install GNU Radio with support for SWIG-base Python bindings
uhd: Install GNU Radio with support for UHD
universal: Build for multiple architectures
wavelet: Install GNU Radio Wavelet component
wxgui: Install GNU Radio with support for Wx GUI

[tmpboost/boost] > install gnuradio +orc +uhd +docs +grc +jack
+portaudio +python27 +qtgui +sdl +swig +wavelet +wxgui
configure.compiler=llvm-gcc-4.2
… Lots of port messages …
[tmpboost/boost] > installed boost*

The following ports are currently installed:
boost @1.50.0_0
boost @1.52.0_1+no_single+no_static+python27 (active)
[tmpboost/boost] > activate [email protected]_0

—> Computing dependencies for boost
—> Deactivating boost @1.52.0_1+no_single+no_static+python27
—> Cleaning boost
—> Activating boost @1.50.0_0
—> Cleaning boost
[tmpboost/boost] >

STEP 4. Reboot

38

Hi Ed - It sounds like the gnuradio port was installed, but for some
reason GRC didn’t pass configuration. The PATH and PYTHONPATH look fine
to me. Do the following (watch wrap):

{{{
sudo port -d configure gnuradio +full configure.compiler=llvm-gcc-4.2 >
~/Desktop/gnuradio_conf.txt 2>&1
}}}

and then, off list, send me the file “~/Desktop/gnuradio_conf.txt” along
with the output of “env” and “port installed”. If we find something
relevant we’ll post back here or I can fix the portfile. - MLD

39

A quick BTW for Mac OS X users trying to install GNU Radio via use
MacPorts – a lesson learned from the off-list discussion between Ed and
I:

If installation of GNU Radio (not a dependency) fails, then before you
do anything else, do

sudo port clean gnuradio gnuradio-devel gnuradio-next

and then try to install or upgrade GNU Radio again from a -really- clean
slate. Sometime MacPorts leaves behind some cruft which gets in the way
of a successful install. It’s not supposed to do this, and while I
cannot replicate this behavior it certainly does happen and this
solution is often enough to get things working again.

My typical way of working with MacPorts is the following:

sudo port selfupdate
foo=port outdated | sed -e '\''1d'\'' | awk '\''{ print $1 }'\'' &&
echo $foo
sudo port clean $foo
sudo port fetch $foo
sudo port clean $foo
sudo port -p upgrade $foo
bar=port installed | grep -v active | sed -e 1d && echo $bar
sudo port uninstall $bar

and, if any step fails then clean or uninstall or reinstall before
continuing. The above is probably more than is necessary, but it
generally works to keep all installed ports up to date and with no older
cruft left behind.

Hope this helps others! - MLD