3.10.0.0-rc2 is now available: https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc2 and you can see the current changelog here: https://github.com/gnuradio/gnuradio/blob/master/CHANGELOG.md The plan is to make a final release mid-January, so this may involve one more RC if there are any more major issues to sort out.
Have a great weekend! Josh On Sat, Nov 27, 2021 at 10:29 AM Josh Morman <jmor...@gnuradio.org> wrote: > Greetings GNU Radio Community! > > Release 3.10 is expected to drop sometime in the new year, but to get the > ball rolling with testing and packaging - we are expecting a longer than > usual Release Candidate cycle, and likely there will be *at least* one > more RC, so here is v3.10.0.0-rc1 > <https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc1> > > We have been fortunate this year to have extremely active backporting and > consistent maintenance releases from co-maintainter Jeff Long - so many of > the fixes and smaller feature (and larger ones) have already seen the light > of day in the 3.9.x.x and even 3.8.x.x releases. Here are some of the > bigger features that are bringing about this major release. > > *gr-pdu* > PDUs (protocol data units) in GNU Radio are a special type of PMT that > have a dictionary and a uniform vector type representing a burst of data > with some metadata. Up to this point, support of pdus has been scattered > throughout the codebase with minimal support for handling this type of data > consistently. Fortunately, Jacob Gilbert has been able to upstream much of > the amazing work from himself and the team at Sandia National Labs which > brings in-tree a suite of tools for manipulating these data objects (see > https://github.com/sandialabs/gr-pdu_utils). Also, many of the previous > PDU processing blocks that existed in other in-tree modules have been > migrated to this module, so there has been some block re-arrangement. > Please see https://www.youtube.com/watch?v=bT60hVVte48 for more detailed > information > > *gr-iio* > IIO is the industrial I/O framework that provides an industry standard > method for communicating with a wide-range of devices including many of the > ADI SDR platforms. Analog Devices has supported out of tree a gr-iio > module that brings this capability into GNU Radio and now upstreamed this > module so support for devices like the PlutoSDR are available out of the > box. Special thanks here to Adam Horden, Travis Collins, Dave Winter, > Volker Shroer, and Jeff Long for bringing this in-tree and working through > many of the complexities. > Please see https://www.youtube.com/watch?v=2gKbollW6wg for a more > technical description of IIO and gr-iio. > > *Custom Buffers Support* > NOTE: this is an advanced "experimental" feature that if not actively > employed will not affect normal GNU Radio usage. > David Sorber from Black Lynx has introduced a feature that enables > streamlined data movement between GNU Radio blocks and hardware > accelerators. By creating a "custom buffer" class (or using one that is > provided by someone else), blocks can be made to abstract the data movement > behind the scenes so that when the `work` function is reached, data already > exists in the device memory. > Let me give a quick example - previously if you wanted to write a GPU > accelerated block with CUDA, you would have to get into the work function, > move the data from the GNU Radio circular buffers to GPU device memory, > execute the CUDA kernels, then move the data back to GR buffers. Now that > data movement is done behind the scenes if the block is set up right so > that when the work function is hit, the data is in GPU device memory and > will get transferred back to CPU memory behind the scenes as well. This > allows back to back HW accelerated blocks to not have to ingress/egress in > and out of GR memory unnecessarily. Also, the single mapped buffer > abstraction brings huge performance benefits as can be seen here: > https://www.youtube.com/watch?v=VO1zMXowezg for a much better description > For examples of this in action, please see the following repositories: > https://github.com/BlackLynx-Inc/gr-cuda_buffer > https://github.com/BlackLynx-Inc/gr-blnxngsched > This out of tree support will soon find its way into the gnuradio github > repo as a set of CUDA buffers and blocks. > > *Logging Infrastructure* > Log4CPP has previously been our logging backend library, but has become a > troublesome dependency. A huge thanks to Marcus Müller for fixing all of > this up, replacing Log4CPP with spdlog - a more modern logging library. > This also opens up the door for more modern logging statements that don't > rely on Boost.format, and libfmt (which is now also a dependency) can be > used for general string manipulation as well. All the previous methods and > macros still exist (except for the log4cpp specific ones), but there is now > new capability to log in a more convenient way using the libfmt statements. > > Old: GR_LOG_INFO(this->d_logger, boost::format("this happened: %d") % > code) > New: this->d_logger->info("this happened {:d}", code) > > As always, please reach out here or on chat.gnuradio.org if you have any > questions - and file GitHub issues if you find bugs or problems with the > release. The step from 3.9 should be pretty minimal, but if you are > migrating your OOTs - please update the porting guide if you come across > differences that need to be documented: > https://wiki.gnuradio.org/index.php/GNU_Radio_3.10_OOT_Module_Porting_Guide > > Have a happy Holiday season and much thanks to all who have contributed > toward this next major release. > > Josh > > >
