It is with much excitement (and after only 4 RCs!!) that we release the next step forward for GNU Radio - 3.10.0.0!
Not only does this release bring in some extremely useful new modules (gr-iio, gr-pdu, and arguably gr-soapy thought that thankfully made it also into recent 3.9 maintenance releases), but also sets a path forward for using GNU Radio in heterogeneous compute environments by providing "custom buffers" for more efficiently interacting with accelerators (GPUS, FPGAs, TPUs, etc.). 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 features (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 highlights of the 3.10 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 supporting the way of 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. 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, Dave Winter, Volker Shroer 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 gr-cuda repository here: https://github.com/gnuradio/gr-cuda - which contains the CUDA custom buffers (that can be re-used in your OOT) and some example 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, and also for his ongoing architectural leadership on this project. The move to spdlog 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. Previous: GR_LOG_INFO(this->d_logger, boost::format("this happened: %d") % code) New: this->d_logger->info("this happened {:d}", code) Much appreciation to all that contributed through code, documentation, review, and just generally being a part of this wonderful community. The code contributors for 3.10 includes AT LEAST the following: 0xloem 0xl...@gmail.com a-andre 13609565+a-an...@users.noreply.github.com Adam Horden adam.horden@horden.engineering Adarsh Singh 79402080+furiousl...@users.noreply.github.com Aditya Thomas sepia_t...@protonmail.com Adrien Michel adrien...@users.noreply.github.com André Apitzsch andre.apitz...@etit.tu-chemnitz.de Andrej Rode m...@andrejro.de Artem Pisarenko artem.k.pisare...@gmail.com Bernard Tyers - Sane UX Design bernard+w...@ei8fdb.org beroset bero...@users.noreply.github.com Bill Muzika bill.muz...@outlook.com Callyan sufo...@gmail.com Chris christopher.dono...@gmail.com Christophe Seguinot christophe.segui...@univ-lille.fr Christoph Koehler ckoe...@sandia.gov Chuang Zhu geneloca...@yandex.com Clayton Smith arg...@gmail.com cmrincon cmrincon...@hotmail.com Codey McCodeface codey.mccodef...@gmail.com Daniel Estévez dan...@destevez.net David Pi david.pi...@gmail.com David Sorber david.sor...@blacklynx.tech David Winter david.win...@analog.com Derek Kozel <derek.ko...@gmail.com> Doron Behar doron.be...@gmail.com duggabe ba...@dcsmail.net efardin efar...@ieee.org Elof Wecksell e...@wecksell.se Emmanuel Blot emmanuel.b...@free.fr Ferenc Gerlits fgerl...@gmail.com GitHub <nore...@github.com> gnieboer gnieb...@corpcomm.net Håkon Vågsether hakon.vagset...@gmail.com Igor Freire i...@blockstream.com Ipsit mmkip...@gmail.com Jacob Gilbert jacob.gilb...@protonmail.com japm48 jap...@users.noreply.github.com JaredD jaredd...@gmail.com Jason Uher jason.u...@jhuapl.edu Jeff Dumps jeffdu...@gmail.com Jeff Long <willco...@gmail.com> Jeppe Ledet-Pedersen j...@satlab.com jfmadeira jf.made...@campus.fct.unl.pt jmadeira jmade...@pdmfc.com Johannes Demel de...@ant.uni-bremen.de John Sallay jasal...@gmail.com Josh Blum j...@joshknows.com Josh Morman jmor...@gnuradio.org karel 5636152+ka...@users.noreply.github.com lenhart malte.lenh...@t-online.de Liu, Andrew Z liu.and...@vast-inc.com luz paz luz...@users.noreply.github.com Marc L mar...@vt.edu Marcus Müller <mmuel...@gnuradio.org> Mark Bauer mar...@illinois.edu Mark Pentler tehhust...@hotmail.com Martin Braun <mar...@gnuradio.org> Martyn van Dijke martijnvdijke...@gmail.com masw m...@masw.tech Matt Ettus mattet...@users.noreply.github.com Matt Mills mmi...@2bn.net muaddib1984 70996692+muaddib1...@users.noreply.github.com Nicholas Bruce saltair93+git...@gmail.com Nicholas Corgan n.cor...@gmail.com Nick Foster bistrom...@gmail.com Nick M tacl...@users.noreply.github.com Nick Østergaard oe.n...@gmail.com Niki n...@aveer.io Notou barth...@laposte.net Oleksandr Kravchuk open.sou...@oleksandr-kravchuk.com Pavon pa...@protonmail.com Philip Balister phi...@balister.org rear1019 rear1...@posteo.de Rohan Sharma rhnsharma5...@gmail.com Ron Economos w...@comcast.net Ryan Volz ryan.v...@gmail.com schneider42 schnei...@blinkenlichts.net Sebastian Koslowski sebastian.koslow...@gmail.com Seth Hitefield sdhitefi...@gmail.com shwhiti shwh...@sandia.gov Solomon Tan solomonbsto...@yahoo.com.au Sylvain Munaut t...@246tnt.com Terry May terryd...@gmail.com Thomas Habets tho...@habets.se Tim Huggins tim.hugg...@systemminnovationgroup.org Travis F. Collins travis.coll...@analog.com Vasilis Tsiligiannis acino...@openwrt.gr Vasil Velichkov vvvelich...@gmail.com Victor Wollesen victo...@pervices.com Volker Schroer 3470424+dl1...@users.noreply.github.com Zackery Spytz zsp...@gmail.com Thanks again - and please reach out on email (here) or chat ( chat.gnuradio.org) if you have questions, run into issues, or to join the ongoing discussion of what should be next for GNU Radio. One minor note - the master branch will be renamed early next week as "main" to align with the github defaults and the direction that most projects have moved. This should be minimally if at all disruptive. Josh
