GNU Radio release 3.6.3 is available here: http://gnuradio.org/releases/gnuradio/gnuradio-3.6... Contributors this release: Alick Zhao <alick9188@gmail.com> Alexandru Csete <oz9aec@gmail.com> Ben Hilburn <ben.hilburn@ettus.com> Ben Reynwar <ben@reynwar.net> Brett L. Trotter <blt@webtrotter.com> Johnathan Corgan <johnathan@corganlabs.com> Josh Blum <josh@joshknows.com> Julien Olivain <Julien.Olivain@lacime.etsmtl.ca> Martin Braun <martin.braun@kit.edu> Michael Dickens <mlk@alum.mit.edu> Nicholas Corgan <nick.corgan@ettus.com> Tim O'Shea <tim.oshea753@gmail.com> Tim Newman <tim.newman@gmail.com> Tom Rondeau <tom@trondeau.com> Release 3.6.3 is a significant release, adding major new capabilities and many bug fixes, while maintaining strict source compatibility with user code already written for the 3.6 API. Much of the code was the result of two events, the September 2012 GNU Radio conference in Atlanta, GA, and the November 2012 GNU Radio hackfest held at Ettus Research in Mountain View, CA. Additional work (not discussed here) from these events has been incorporated into the 'next' branch of the code repository, and will become part of the 3.7 API release series. New features include asynchronous message passing between blocks, new blocks for interfacing with operating system networking stacks, the ability to write new signal processing blocks in Python, enhanced file source and sinks that can store metadata, flowgraph latency control, improvements to documentation, and further conversion of existing code into the 3.7 API organization (while leaving existing blocks in place.) Enjoy! Johnathan Corgan Corgan Labs Detailed changelog: Addition/upgrade of message passing infrastructure (Tim O'Shea, Tom Rondeau, Johnathan Corgan, Josh Blum) This introduces the ability to add and connect formally defined asychronous message ports to signal processing blocks and hierarchical blocks. These message ports can be connected to pass asynchronous data in the form of PMTs (polymorphic types) among blocks in a flowgraph. It is also possible to implement pure message passing blocks that have no requirement for streaming ports or work functions. We've also introduced the concept of PDUs (Protocol Data Units) as a convention for passing data+metadata using the new messaging ports. A PDU is a PMT pair that combines a PMT dictionary of metadata keys/values along with a PMT blob to hold a vector of data in memory. A few new general purpose blocks supporting these capabilties are in gnuradio-core: gr_message_debug gr_message_strobe gr_tagged_stream_to_pdu gr_pdu_to_tagged_stream Two new blocks for interfacing with networking stacks using the new PDU semantics: gr_socket_pdu gr_tuntap_pdu This new message passing capability and PDU convention is aimed at providing the infrastructure to better support software radio implementations using packet-oriented semantics, such as MAC-layer processing. Addition of new Python-based signal processing blocks (Josh Blum) This feature, originally introduced by Josh Blum as part of GrExtras, allows implementing signal processing blocks directly in Python, and has now become a standard feature of GNU Radio. Addition of gr-analog top-level component (Tom Rondeau) This implements the current gnuradio-core signal processing blocks used for analog signal processing into their own top-level component, gr-analog, and uses the new 3.7 API organization. The original blocks in gnuradio-core will be removed on the 3.7 branch prior to 3.7 release. Addition of gr-blocks top-level component (Johnathan Corgan) This implements a large portion of the gnuradio-core non-signal processing blocks in the 3.7 API form. The original blocks in gnuradio-core will be removed on the 3.7 branch prior to 3.7 release. Metadata file source and sink blocks (Tom Rondeau) Two new blocks implement enhanced file source and sink blocks that incorporate metadata passed using the stream tags feature in GNU Radio. It is now possible to store things like frequency and sample rate into capture files, or whatever key/value pairs you tag onto data streams inside a flowgraph. http://www.trondeau.com/home/2012/12/15/metadata-f... GNU Radio buffer latency control (Tim O'Shea, Tom Rondeau) For finer-grained control over latency inside a GNU Radio flowgraph, it is now possible to adjust, on a per-block basis, the maximum noutput_items that will be used to call a block work function. In addition, it is possible to set the maximum size an output buffer can grow to before a work function is called. New GNU Radio Companion (GRC) capabilities Added optional flag to pad source and sink (Josh Blum) Added wildcard type to pad source and sink (Josh Blum) Added ability to reload XML for block (Tim O'Shea) Added ability to automatically create hier_blocks from a flowgraph (Tim Newman) Added ability to open custom GRC hier block definitions (Tim O'Shea) Added new grcc command line GRC-to-Python utility (Tom Rondeau) New Documentation Updates (Tom Rondeau) We are introducing documentation into the Doxygen manual describing features and capabilities of GNU Radio, above and beyond just documenting the API functions. Tom Rondeau has written about this here: http://www.trondeau.com/home/2012/12/18/new-docume... Some examples of commits where this has been done: http://gnuradio.org/cgit/gnuradio.git/commit/?id=77ea309 (PMT type usage) http://gnuradio.org/cgit/gnuradio.git/commit/?id=a21c5f7 (Message passing interface) http://gnuradio.org/cgit/gnuradio.git/commit/?id=996e599 (Metatdata format) http://gnuradio.org/cgit/gnuradio.git/commit/?id=5fcb7eb (Max output buffer control) Other new features: Allow file source to open new files while running (Brett L. Trotter) Allow source blocks to return none/yield (Josh Blum) Improved capabilities of uhd_fft.grc example in gr-uhd (Ben Hilburn) Added parameter in qtgui sink's GRC block to set the update rate (Julien Olivain) Added source block hook in gr-uhd for issue stream cmd (Josh Blum) Added cmake package support for Ubuntu 12.10 (Nicholas Corgan) Added gr::blocks::patterned_interleaver (Tim O'Shea) Allow user to set Python path during cmake configuration (Tom Rondeau) Enabled serialize/deserialize for PMT vectors (Tom Rondeau) Added unsigned long long int support to the PMT sugar functions (Tom Rondeau) Allow using pmt_init_Xvector methods in python (Tom Rondeau) Bug fixes: Numerous cmake related bug-fixes (Josh Blum, Johnathan Corgan, Tom Rondeau) Overhaul of cmake include directory ordering (Michael Dickens) Fixed parallel build failures in cmake (Tom Rondeau) Fixed segfaults due to old, no longer nedded SWIG workaround (Tom Rondeau) Fixed memory leak issue in arbitrary resampler blocks (Tom ROndeau) Fixed use of default noise seed in channel model (Alick Zhao) Fixed scaling bug in QAM constellations (Ben Reynwar) Fixed installation of grc examples (Johnathan Corgan) Fixed finding Qwt6 installed on OSX using MacPorts (Ben Reynwar) Fixed implicit assumption in skiphead (Josh Blum) Fixed include tag include usage throughout core (Josh Blum) Fixed incorrect private usage in gr_endian_swap (Josh Blum) Fixed segfault in gr-filter due to memory free bug (Josh Blum) Fixed UHD pmt tuple ref namespace issue (Josh Blum) Fixed gr_tag_debug to handle lacking srcid (Martin Braun) Fixed gr-analog for 'sincos(f)' on MacOSX (Michael Dickens) Fixed gr-analog build issues on Windows (Nicholas Corgan) Fixed qtgui time sink to take the bandwidth parameter to set x-axis correctly (Tom Rondeau) Fixed float-in, complex-out fft block to use the right io sig (Tom Rondeau) Fixed Clang imcompatibility by removing '.version' lines in ASM code in core (Tom Rondeau) Fixed file_meta_source/sink incompatibilities with MSVC (Nicholas Corgan) Fixed some unused parameter warnings (Alexandru Csete)
on 2013-01-08 22:37
on 2013-01-09 15:42
On Jan 8, 2013, at 4:35 PM, Johnathan Corgan <johnathan@corganlabs.com> 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"). NOTES: * With the latest changes to the CMake build files, as well as the addition of scipy as a runtime requirement, I believe I've found all of the dependencies within GNU Radio whether for building or runtime. GNU Radio should be easy to install and use (for you) and maintain (for me) within the MacPorts environment. If you have any issues when installing via MacPorts please search for the issue < https://trac.macports.org/search >, and if you don't find it then report the issue in a ticket < https://trac.macports.org/newticket >; set the owner as "michaelld@macports.org". * Please do "port variants gnuradio" to understand your install options: by default, GNU Radio is installed with only the basic dependencies, which means no SWIG (Python interface), Wx, Qt, GRC, SDL, or the like. I recommend installing via "sudo port install gnuradio +full", but I recognize that not everyone wants to wait around for hours while Qt4 is installed; hence, I'm making none of these variants active by default. By "popular request" this behavior is a change from the past, when everything was installed by default. * For those trying "next", I've added a variant for ctrlport as EXPERIMENTAL -- it does not work for me, but maybe it will for you. This variant is not part of "+full"; you will have to specify it explicitly. Enjoy! - MLD
on 2013-01-09 17:03
On Jan 9, 2013, at 9:41 AM, Michael Dickens <mlk@alum.mit.edu> wrote: > On Jan 8, 2013, at 4:35 PM, Johnathan Corgan <johnathan@corganlabs.com> 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/... 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
on 2013-01-09 22:34
On Wed, Jan 9, 2013 at 5:02 PM, Michael Dickens <mlk@alum.mit.edu> wrote: > latest release -- which has bugs in the way it handles threads, does not > cd tmp_boost > sudo port -f deactivate $ff > 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 > > Hi Michael, Thanks for the detailed instructions. I didn't have macports installed so I started from scratch. I installed macports, then boost 1.51 according to your instructions. Then I try to install uhd before gnuradio: sudo ports install uhd +libusb and that installs boost 1.52 :( If you have any advice for what I should do before continuing with gnuradio, please let me know. Alex
on 2013-01-10 02:21
On Jan 9, 2013, at 4:33 PM, Alexandru Csete <oz9aec@gmail.com> wrote: > Thanks for the detailed instructions. > > I didn't have macports installed so I started from scratch. I installed macports, then boost 1.51 according to your instructions. Then I try to install uhd before gnuradio: > > sudo ports install uhd +libusb > > and that installs boost 1.52 :( > > If you have any advice for what I should do before continuing with gnuradio, please let me know. Hi Alexandru - You're welcome! I'm glad to hear from OSX GNU Radio users. Chances are that boost 1.51 is still installed, but not active in MacPorts. You can view all of the installed boost ports via: port installed boost to verify that it's still around. If not, try re-doing my instructions for installing boost 1.51. If it is around, you can try this to make sure boost 1.51 is the active boost: gg=`port installed boost | grep 51 | sed -e "s@(active)@@g"` sudo port activate $gg If Boost 1.51 is already active, the above will do nothing. If it is not active, it should be made so, an boost 1.52 deactivated (first). Both GNU Radio and UHD work with Boost 1.51, so all you should have to do is (re)activate the older Boost. You can verify which version of Boost is active via: port installed boost | grep active Hope this helps! - MLD
on 2013-01-10 21:36
On Thu, Jan 10, 2013 at 2:20 AM, Michael Dickens <mlk@alum.mit.edu> wrote: > > > If Boost 1.51 is already active, the above will do nothing. If it is not active, it should be made so, an boost 1.52 deactivated (first). Both GNU Radio and UHD work with Boost 1.51, so all you should have to do is (re)activate the older Boost. > > You can verify which version of Boost is active via: > > port installed boost | grep active Hi Mike, Thanks for your help. As it turns out, I simply forgot to run the last step that actually installs boost 1.51 after building it - that explains why boost 1.52 got installed with uhd. I have now rebuilt 1.51, deactivated 1.52 and installed 1.51. Everything is ok now and I installed gnuradio without problems. I used: "sudo port install gnuradio +orc +uhd" During configuration I saw the message: WARNING: GNU Radio's VOLK component (which handles vector optimized instructions and routines) compiles best when using GCC. The selected compiler is CLANG, which will result in a fully functioning GNU Radio install but the VOLK component will not utilize the CPU's capabilities. Do you have any experience whether this can be a real performance issue and what I can do to use gcc instead of clang? Alex
on 2013-01-10 21:46
On Jan 10, 2013, at 3:35 PM, Alexandru Csete <oz9aec@gmail.com> wrote: > instructions and routines) compiles best when using GCC. The selected > compiler is CLANG, which will result in a fully functioning GNU Radio > install but the VOLK component will not utilize the CPU's > capabilities. > > Do you have any experience whether this can be a real performance > issue and what I can do to use gcc instead of clang? You're welcome! I'm glad you've got GNU Radio installed on Mac OS X via MacPorts. I'll leave the performance question up to those who wrote Volk. I'm guessing that if Volk keys on GCC for optimizations, then using clang will disable most optimizations. But, I'm no expert here. You can select a compiler suite by appending to the usual "port" commands "configure.compiler=XXX", where XXX is one of: gcc-3.3 gcc-4.0 gcc-4.2 llvm-gcc-4.2 clang apple-gcc-4.0 apple-gcc-4.2 macports-gcc-4.1 macports-gcc-4.2macports-gcc-4.3 macports-gcc-4.4 macports-gcc-4.5 macports-gcc-4.6 macports-gcc-4.7 macports-gcc-4.8 macports-clang-2.9 macports-clang-3.0 macports-clang-3.1 macports-clang-3.2 Note that "clang" is Apple's installed clang, no matter the version (could be 2.1, 3.1, 4.1; maybe others). If you're running on Mac OS X 10.7 or 10.8, I'd recommend using the following: sudo port install gnuradio +orc +uhd configure.compiler=llvm-gcc-4.2 to get Volk using a compatible GCC & thence the optimizations therein. You can find out a little (but, not much) more about this topic at < http://guide.macports.org/#reference.phases.configure > and then scroll down to or search for "configure.compiler". Hope this helps! - MLD
on 2013-01-11 00:11
On Thu, Jan 10, 2013 at 9:44 PM, Michael Dickens <mlk@alum.mit.edu>
wrote:
>
Thanks for the tip - I will try to rebuild using gcc later and see
what difference it makes. For now I am happy that after installing
gnuradio, I could install the rtl-sdr and gr-osmosdr packages, and
since I already had Qt 4.8 installed I could also build gqrx without
major issues.
Concerning performance, I do see an "Using Volk machine: generic_orc"
message when I start gqrx; however, running an FM stereo receiver with
an rtlsdr dongle at 2 Msps, 4096 point fft at 30 fps with averaging
enabled consumes about 50% cpu on a dual core imac from early 2009.
I'm quite satisfied with that.
Alex
on 2013-01-17 21:20
Mike, >> maybe even the scan thing I noted above. See problem loading the dylib below: >> >> ImportError: dlopen(/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so, 2): Library not loaded: libgnuradio-osmosdr.0.dylib >> Referenced from: /opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so >> Reason: image not found >> >> Seems like I am missing one final detail that glues the proper loading of the dynamic libraries? > > I'm wondering where "libgnuradio-osmosdr.0.dylib" is located. Usually this would be installed into ${prefix}/lib (so, /opt/local/lib in your case). Yes it was in /opt/local/lib. Don't know why the system can't find it. If I cd to /opt/local/lib and then run gnu radio-companion, works great, if I am not cd to that directory it fails every time. I also tried adding /opt/local/lib to the PATH but that did not help. At least I can run successfully now, even though have to cd to that directory. I think Alex might have also said something similar not that I say this, I think he said he had to copy libs to the directory of his executable. If you think of any potential solution, let me know. Otherwise I guess I will play with things for a while with this work around, and revisit trying to figure out why later. Thanks for your suggestions and help, mlk
on 2013-01-17 21:41
On 16/01/13 09:02 PM, Michael L Kornegay wrote: > Yes it was in /opt/local/lib. Don't know why the system can't find it. > > If I cd to /opt/local/lib and then run gnu radio-companion, works great, if I am not cd to that directory it fails every time. > > > I also tried adding /opt/local/lib to the PATH but that did not help. \ PATH is used for locating executable programs, not libraries. UNIX-like systems often use LD_LIBRARY_PATH to extend the system-configured paths for libraries. > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
on 2013-01-17 22:08
On 01/16/2013 09:37 PM, Marcus D. Leech wrote: >>> I'm wondering where "libgnuradio-osmosdr.0.dylib" is located. Usually this would be installed into ${prefix}/lib (so, /opt/local/lib in your case). > if you come from a windows background, PATH is used for dlls and executables. However, for OSX, you will want to set DYLD_LIBRARY_PATH to contain your dylibs -josh
on 2013-01-18 05:49
Mike - What does "otool -L /opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so" return? If it does not contain "/opt/local/lib/libgnuradio-osmosdr.0.dylib", then there is a library linking issue. If it does, then I'll try installing it myself to see what's going on. On Jan 16, 2013, at 11:05 PM, Josh Blum <josh@ettus.com> wrote: > if you come from a windows background, PATH is used for dlls and > executables. However, for OSX, you will want to set DYLD_LIBRARY_PATH to > contain your dylibs Even better on OSX is that you want to make sure all of the link-to libraries are correctly linked-to. This is what MacPorts' "rev-upgrade" phase does: verifies the self-integrity of the MacPorts-installed libraries and binaries. In this way, when using MacPorts, one does not need to set any DYLD_* stuff since everything is supposed to "just work". For the purposes of "day to day" environment settings, I -highly- recommend against using DYLD_LIBRARY_PATH or any of the DYLD_* variables since that can really screw with the way things are meant to work. On OSX, the library internally contains the other libraries upon which it depends, with a full or relative path. So, for example, if there is a conflict between libiconv (/usr/lib/libiconv* and /opt/local/lib/libiconv*), if DYLD_LIBRARY_PATH is set to have /opt/local/lib before /usr/lib, then that version of libiconv will be "favored" (not guaranteed) over the other version. Which, if the 2 versions are not ABI compatible, has the potential to wreak havoc since you as the user will often have no idea that they both exist, and thus no idea why your program won't run. So, setting DYLD_LIBRARY_PATH can be useful when testing a project after it is built but before it is installed -- GNU Radio's test script uses this, both with CMake as well as prior with GNU Autotools. It's a wonderful short-term way to check out what you just compiled for issues, assuming you can set it correctly to find your new libraries before the old ones (e.g., if they were already installed). - MLD
on 2013-01-18 17:29
> ImportError: dlopen(/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so, 2): Library not loaded: libgnuradio-osmosdr.0.dylib > Referenced from: /opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so > Reason: image not found > > Seems like I am missing one final detail that glues the proper loading of the dynamic libraries? To follow up: I installed rtl-sdr using MacPorts, cloned gr-osmosdr and did the usual build. After installing (into ${PREFIX}=/usr/local, of course, to keep it in its own install space away from MacPorts), I checked "otool -L ${PREFIX}/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so" and the reference to "libgnuradio-osmosdr" is not correct; it reads "libgnuradio-osmosdr.0.dylib" and should read "${PREFIX}/lib/libgnuradio-osmosdr.0.dylib". So, I checked "otool -L ${PREFIX}/lib/libgnuradio-osmosdr.0.dylib", and it's self-id [1] is not correct; it reads "libgnuradio-osmosdr.0.dylib" and should be "${PREFIX}/lib/libgnuradio-osmosdr.0.dylib". Now, when I check the version of this library from the top build directory of osmosdr (call this ${OSMOSDR_BUILD_DIR}, "otool -L lib/libgnuradio-osmosdr.dylib", I get back the self-id of "${OSMOSDR_BUILD_DIR}/lib/libgnuradio-osmosdr.0.dylib" -- which is correct. So, CMake when it is installing this library is not getting its self-id correct, which in turn is messing up this library's reference in the SWIG library. I looked at "gr-osmosdr/lib/CMakeLists.txt", and nothing sticks out to me as being really wrong. Maybe someone else with more time than me can figure this one out? - MLD ps> To rectify this issue, post install, you can always do the following [with ${PREFIX} substituted correctly; you might need to "sudo" these, depending on how you installed them in the first place]: {{{ install_name_tool -change libgnuradio-osmosdr.0.dylib ${PREFIX}/lib/libgnuradio-osmosdr.0.dylib ${PREFIX}/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so install_name_tool -id ${PREFIX}/lib/libgnuradio-osmosdr.0.dylib ${PREFIX}/lib/libgnuradio-osmosdr.0.dylib }}} [1] In Mac OS X, a library's "self-id" is how it refers to itself, generally including the full path; it can be set via "/usr/bin/install_name_tool -id <NEW_ID> <FILE>". So, for example, gnuradio-core's self-id for a given ${PREFIX} will be something like "${PREFIX}/lib/libgnuradio-core.dylib". The self-id is used only when the library is being used for linking purposes; it is otherwise ignored by the DYLD subsystem.
on 2013-01-22 05:18
Michael Dickens <mlk@alum.mit.edu> writes: >> WARNING: GNU Radio's VOLK component (which handles vector optimized > > to get Volk using a compatible GCC & thence the optimizations therein. You can find out a little (but, not much) more about this topic at < http://guide.macports.org/#reference.phases.configure > and then scroll down to or search for "configure.compiler". > > Hope this helps! - MLD Hi, I tried to compile gnuradio 3.6.3 on MacPorts with the following command: sudo port install gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig +uhd +wxgui configure.compiler=macports-gcc-4.7 GNU Radio was installed successfully on my quad-core Core i7, but when I execute GNU Radio Companion signal flow, I see the following messages: _____ Message _____ Mac OS; Clang version 4.1 ((tags/Apple/clang-421.11.66)); Boost_105100; UHD_003.005.000-0-unknown Using Volk machine: generic_orc gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd Using device #0 Compro VMU6xx SN: 0020 Found Elonics E4000 tuner Exact sample rate is: 2000000.052982 Hz >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE >>> gr_fir_fcc: using SSE >>> Done _____ Message _____ How can I make gnuradio and volk be optimzed for Core i7? generic_orc seems not best optimized for core i7. Thanks in advace! Sincerely, Albert
on 2013-01-22 13:18
On Jan 21, 2013, at 11:17 PM, Albert Chun-Chieh Huang
<alberthuang314@gmail.com> wrote:
> How can I make gnuradio and volk be optimzed for Core i7? generic_orc seems not
best optimized for core i7.
Hi Albert - I'm glad to hear of your general success in using MacPorts
for GNU Radio. For your particular question, I'll let the VOLK folks
address the broad question regarding runtime selection of VOLK kernels /
machines. From my perspective, I'd like to know which kernels /
machines were detected at configuration time. You can get this info
independent of the install via:
{{{
sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl
+swig +uhd +wxgui configure.compiler=macports-gcc-4.7
}}}
and watch the output. Somewhere part way through, you'll see a list
like this one (which is for my "old" laptop's Intel Core 2 Duo (when
using the above command, btw):
{{{
-- 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
}}}
If you see these options, then there's probably a way to select kernels
/ machines are runtime; but, as I said, I'll leave that question up to
the VOLK developers. - MLD
on 2013-01-23 04:29
Michael Dickens <mlk@alum.mit.edu> writes: > On Jan 21, 2013, at 11:17 PM, Albert Chun-Chieh Huang <alberthuang314@gmail.com> wrote: >> How can I make gnuradio and volk be optimzed for Core i7? generic_orc seems not best optimized for core i7. > > Hi Albert - I'm glad to hear of your general success in using MacPorts > for GNU Radio. For your particular question, I'll let the VOLK folks > address the broad question regarding runtime selection of VOLK kernels > / machines. From my perspective, I'd like to know which kernels / > machines were detected at configuration time. You can get this info > independent of the install via: Hi, Michael, I'm thankful for what you've done to Mac users. Before this port, building GNU Radio was really distressing and normally I just gave up after several failed builds and use GNU Radio in Linux. Well, I tried to do a clean install MacPorts after this post. This time, after MacPorts is installed, gcc 4.7 was installed first and used as default compiler. Then I install every packages that gnuradio depends with gcc 4.7. When I try to use gcc 4.7 to compile gnuradio with the following command: sudo port install gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig +uhd +wxgui configure.compiler=macports-gcc-4.7 The build was failed. And then I tried gcc 4.5 and it failed. Only when I use llvm-gcc-4.2 would give me a successful build. When I run gnuradio-companion, I got this message: __________________________________ Mac OS; GNU C++ version 4.7.2; Boost_105200; UHD_003.005.000-0-unknown Using Volk machine: sse4_1_64_orc gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd Using device #0 Compro VMU6xx SN: 0020 Found Elonics E4000 tuner Exact sample rate is: 2000000.052982 Hz >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE >>> gr_fir_fcc: using SSE __________________________________ > -- 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 > }}} > > If you see these options, then there's probably a way to select > kernels / machines are runtime; but, as I said, I'll leave that > question up to the VOLK developers. - MLD If I run the following command: sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig +uhd +wxgui configure.compiler=macports-gcc-4.7 The messages for VOLK part is: ____________________ -- 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 ____________________ For the command: sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig +uhd +wxgui configure.compiler=macports-gcc-4.7 ____________________ -- GCC missing xgetbv, Overruled arch avx -- 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;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 ____________________ The difference seems to be AVX, and my configuration is listed below: CPU: Quad-core Core i7, Ivy bridge architecture OS: MacOSX 10.8.2 MacPorts version: 2.1.2 with latest sync on January 22 gcc version 4.7.2 (MacPorts gcc47 4.7.2_2) gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Thanks in advance. Albert
on 2013-01-23 15:52
On Tue, Jan 22, 2013 at 10:27 PM, Albert Chun-Chieh Huang < alberthuang314@gmail.com> wrote: > -- 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 > ____________________ > > For the command: > sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl > +swig +uhd +wxgui configure.compiler=macports-gcc-4.7 > Albert, This is the same command as above, or am I missing something? ____________________ > The difference seems to be AVX, and my configuration is listed below: > CPU: Quad-core Core i7, Ivy bridge architecture > OS: MacOSX 10.8.2 > MacPorts version: 2.1.2 with latest sync on January 22 > gcc version 4.7.2 (MacPorts gcc47 4.7.2_2) > gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) > > > Thanks in advance. > > Albert What if you configure without ORC? Also, run volk_profile after you've built 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
on 2013-01-23 16:28
Hi Albert - On Jan 22, 2013, at 10:27 PM, Albert Chun-Chieh Huang <alberthuang314@gmail.com> wrote: > I'm thankful for what you've done to Mac users. Before this > port, building GNU Radio was really distressing and normally I just gave > up after several failed builds and use GNU Radio in Linux. You're welcome; I'm thankful too, since I do use GNU Radio for a few projects off and on, and I like fixing the bugs and getting others' bug fixes in & thus keeping my install up to date. The new MacPorts installs make that really simple, and seem to work for most users in most cases. It's also nice to have the time to keep my favorite ports up to date, and maybe even add in a few new ones of relevance -- I'm thinking since rtl-sdr is part of MacPorts, I could maybe add in gr-osmosdr too since it seems to be of some use to folks. > Well, I tried to do a clean install MacPorts after this post. This time, > after MacPorts is installed, gcc 4.7 was installed first and used as > default compiler. Then I install every packages that gnuradio depends > with gcc 4.7. When I try to use gcc 4.7 to compile gnuradio with the > following command: > > sudo port install gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig > +uhd +wxgui configure.compiler=macports-gcc-4.7 > > The build was failed. And then I tried gcc 4.5 and it failed. Off list, can you send me the logfile from each failed build? I'll try it local to my computer, too, with gdd 4.7 (since that's what I have installed already and hence I can check this quickly) to see if I can replicate it. Better to fix these bugs than let them persist when reasonably possible! > Only when > I use llvm-gcc-4.2 would give me a successful build. When I run > gnuradio-companion, I got this message: > __________________________________ > > Using Volk machine: sse4_1_64_orc Well, I'm glad one of the compilers worked! I don't know much about VOLK, but if it's using SSE4 then that's probably pretty fast and efficient. More in another email. - MLD
on 2013-01-23 16:30
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 Rondeau <tom@trondeau.com> 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
on 2013-01-23 16:36
On Wed, Jan 23, 2013 at 10:29 AM, Michael Dickens <mlk@alum.mit.edu> wrote: > 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? 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. > output. > ACK. > 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 Tom
on 2013-01-23 16:44
On Jan 23, 2013, at 10:34 AM, Tom Rondeau <tom@trondeau.com> wrote: >> On Wed, Jan 23, 2013 at 10:29 AM, Michael Dickens <mlk@alum.mit.edu> 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
on 2013-01-23 16:57
On Wed, Jan 23, 2013 at 10:43 AM, Michael Dickens <mlk@alum.mit.edu> 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
on 2013-01-23 23:51
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 Dickens wrote in post #1091611:
> On Jan 9, 2013, at 9:41 AM, Michael Dickens <mlk@alum.mit.edu> wrote:
>> On Jan 8, 2013, at 4:35 PM, Johnathan Corgan <johnathan@corganlabs.com> 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/...
> 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
on 2013-01-24 14:48
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_out... 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 Dickens <mlk@alum.mit.edu> writes:
on 2013-01-24 16:38
[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
on 2013-01-24 19:15
On 01/24/2013 07:37 AM, Michael Dickens 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
on 2013-01-25 03:24
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
on 2013-01-25 07:20
Nick Foster <nick@ettus.com> 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... 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
on 2013-01-25 16:08
On Jan 25, 2013, at 1:19 AM, Albert Chun-Chieh Huang <alberthuang314@gmail.com> 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. :) - MLD
on 2013-01-25 17:36
On Jan 25, 2013, at 10:06 AM, Michael Dickens <mlk@alum.mit.edu> 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
on 2013-01-25 17:36
BTW> See also Intel's documentation on how to go about detecting AVX: < http://software.intel.com/sites/default/files/m/0/... >, page 2-2 specifically. Maybe this could be made a runtime check, paired with a configure-time preliminary check? - MLD
on 2013-01-25 18:22
On Fri, Jan 25, 2013 at 11:28 AM, Michael Dickens <mlk@alum.mit.edu> 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
on 2013-01-25 19:11
On 01/25/2013 08:30 AM, Michael Dickens wrote: > BTW> See also Intel's documentation on how to go about detecting AVX: < http://software.intel.com/sites/default/files/m/0/... >, page 2-2 specifically. Maybe this could be made a runtime check, paired with a configure-time preliminary check? - MLD > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > 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
on 2013-01-25 21:13
On Jan 25, 2013, at 1:10 PM, Nick Foster <nick@ettus.com> 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 :) - MLD
on 2013-01-25 21:26
On Jan 25, 2013, at 12:20 PM, Tom Rondeau <tom@trondeau.com> 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.
on 2013-01-25 22:29
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 boost@1.50.0_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 boost@1.50.0_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 boost@1.50.0_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
on 2013-01-26 03:16
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
on 2013-01-28 20:44
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
Enable email notification
Enable multi-page viewPlease 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
Log in with Google account | Log in with Yahoo account
No account? Register here.