Now that we have a new stable release series, I want to alert developers
to some upcoming changes in the GNU Radio trunk which will impact your
software, requiring changes on your part in order to continue to compile
and link against a version of GNU Radio built from the trunk.
For those of you who need to maintain source code compatibility, you
should be using either the official release 3.2 tarball, the Ubuntu
binary packages, or a Subversion checkout of the release 3.2 branch.
This code branch will have backported bug fixes and new features, but
only those which can be implemented without breaking existing source
code.
In no particular order of time or importance, these are among some of
the changes planned for the development trunk and 3.3 release that may
affect you:
-
Removal of the omnithreads library/switchover to Boost threads. This
is a C++ auxiliary library used internally as a layer on top of
pthreads, but made available for users as well. Python API users will
be unaffected, as will most C++ API users, but if you’ve used this
library directly, you’ll need to investigate replacements from the Boost
threading library. This changeover has been going on for some time
already.
-
Elimination of the single-threaded flowgraph scheduler. The
“thread-per-block” scheduler is already the default in 3.2. While this
won’t require any code changes, if you’ve been manually selecting the
STS via the environment, you won’t be able to do this anymore.
-
Replacement of usrp-inband code for USRP1. Using the to-be-developed
merge of message passing capabilities into gr-blocks, the USRP1 (and
USRP2) will have timed transmit/receive and metadata capabilities from
within the traditional (non-mblock) GNU Radio C++ and Python APIs.
-
Migration of blks2 into C++. This has been a place to hold
hierarchical blocks constructed in Python. Many of these blocks will be
reimplemented as C++ API hierarchical blocks, and re-exported into
Python as part of the core ‘gr’ namespace. This will done where
possible without syntax changes needed in your Python code other than
the namespace to import from.
-
Movement of libusrp header files into ‘include/usrp’ directory.
Today, these are installed into the global $prefix/include directory,
with the possibility of name clashes with other header files. If you
are using libusrp directly, you’ll need to update your #include<>
statements in your C++ code.
-
Deprecation and eventual removal of gr-comedi. This component
provides GNU Radio blocks for the libcomedi interface to many ADC cards.
However, it is no longer compatible with the current libcomedi API, and
without a maintainer or the ability to test correctness, it is becoming
stale. If this component is important to you, we’d love to hear from
you.
There are of course many new capabilities planned for 3.3, which will be
the subject of another email, and Eric has already touched on a few in
his prior email after the release of 3.2.
Johnathan C.
Corgan Enterprises LLC
On Wed, 2009-05-27 at 06:44 -0700, Johnathan C. wrote:
In no particular order of time or importance, these are among some of
the changes planned for the development trunk and 3.3 release that may
affect you:
…
- Elimination of the single-threaded flowgraph scheduler. The
“thread-per-block” scheduler is already the default in 3.2. While this
won’t require any code changes, if you’ve been manually selecting the
STS via the environment, you won’t be able to do this anymore.
Is it really neccesary to remove this?
I need the single-threaded-scheduler for my GPGPU code. (Running
gnuradio on a videocard)
When doing doing calculations on en external device, you really need to
be in control of on which CPU/thread which block is running.
In practice you need to run everything that runs on the external device
from a single host thread.
The external device is running hundreds of threads and gnuradio only
needs a single thread to control the external device and move data
between the host and external device.
I have been waited with developing the GPGPU code further until the
changes in the scheduling code stabelizes. (At the moment the gpgpu
branche is incompatible with the most recent trunk)
My version of the scheduler is a modified single-threaded scheduler.
So I don’t neccesaraly need to keep the current single-threaded
scheduler, but I do need the possibility to choose which scheduler to
use.
- Migration of blks2 into C++. This has been a place to hold
hierarchical blocks constructed in Python. Many of these blocks will be
reimplemented as C++ API hierarchical blocks, and re-exported into
Python as part of the core ‘gr’ namespace. This will done where
possible without syntax changes needed in your Python code other than
the namespace to import from.
Will it be still possible to build your own python hierarchical blocks
and install them somewhere.?
Martin
On Wed, May 27, 2009 at 7:35 AM, Martin DvH
[email protected] wrote:
- Elimination of the single-threaded flowgraph scheduler. The
“thread-per-block” scheduler is already the default in 3.2. While this
won’t require any code changes, if you’ve been manually selecting the
STS via the environment, you won’t be able to do this anymore.
Is it really neccesary to remove this?
Not strictly necessary, no. A lot of the new features in 3.3 will
impact the scheduler, especially the new message passing between
blocks. It will be extra work to modify both schedulers. This is
Eric’s area, however, so I’ll let him comment further.
- Migration of blks2 into C++.
Will it be still possible to build your own python hierarchical blocks and install them somewhere.?
Yes, of course. To clarify the above, we’re reimplementing a number
of our own Python hierarchical blocks that are in now in the blks2
namespace as C++ hierarchical blocks that will then be re-made
available to Python via SWIG in the gr namespace. We’re not removing
the ability to write hierarchical blocks in Python. This mostly to
allow pure C++ API users to take advantage of them, such as the using
the digital packet radio capabilities we have.
As an example where we’ve already done this, we (well, Tom R.)
migrated the blks2 channel model:
http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/blks2impl/channel_model.py?rev=10863#L25
…into C++ here:
http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/hier/gr_channel_model.cc#L43
Johnathan
On Wed, 2009-05-27 at 08:12 -0700, Johnathan C. wrote:
Not strictly necessary, no. A lot of the new features in 3.3 will
impact the scheduler, especially the new message passing between
blocks. It will be extra work to modify both schedulers. This is
Eric’s area, however, so I’ll let him comment further.
OK, I get the picture.
Since my single-threaded gpgpu-scheduler needs modifications as it is.
Maybe you should implement the multi-threaded-scheduler and leave the
scheduler choosing mechanism in place, and only leave stubs for the
single-threaded case.
I then could have a go at (trying to) implementing it for the
single-threaded (gpgpu ) case.
Eric, what’s your view on this?
Martin
On Wed, May 27, 2009 at 06:44, Johnathan
Corgan[email protected] wrote:
Movement of libusrp header files into ‘include/usrp’ directory.
Today, these are installed into the global $prefix/include directory,
with the possibility of name clashes with other header files. If you
are using libusrp directly, you’ll need to update your #include<>
statements in your C++ code.
This will be happening over the next few days on the trunk, please be
prepared. This only affects people who are writing low-level C++ code
that directly accesses classes in libusrp. The GNU Radio C++ and
Python APIs and code that uses them will be unaffected.
Johnathan
On Thu, May 28, 2009 at 12:51:31AM +0200, Martin DvH wrote:
I then could have a go at (trying to) implementing it for the
single-threaded (gpgpu ) case.
Eric, what’s your view on this?
I’m going to remove the STS, but can probably leave the choosing
mechanism in place. I don’t see a reasonable way to get the new async
message passing + data flow model implemented on top of the STS.
FYI, there are some guys at the DSPCAD group at the Univ of Maryland
who are figuring out how to get their static data flow scheduler to
read a GR flow graph description and generate schedules for various
GPUs.
Eric
On Wed, Jul 8, 2009 at 12:13, Johnathan
Corgan[email protected] wrote:
Movement of libusrp header files into ‘include/usrp’ directory.
Today, these are installed into the global $prefix/include directory,
with the possibility of name clashes with other header files. If you
are using libusrp directly, you’ll need to update your #include<>
statements in your C++ code.
This will be happening over the next few days on the trunk, please be
prepared. This only affects people who are writing low-level C++ code
that directly accesses classes in libusrp. The GNU Radio C++ and
Python APIs and code that uses them will be unaffected.
This and the removal of the usrp-inband code has been done and merged
in trunk revision r11394.
A checkpoint tag has been created for anyone needing to use the
pre-merge code:
http://gnuradio.org/svn/gnuradio/tags/checkpoints/trunk-20090708-pre-usrp-reorg
Johnathan