Re: VOLK C++ core

[Marcus Müller]

Hey Nick,

> Yes, that's kind of my fault.

"Dault" is kind of a hard word when it's your achievement that a C API VOLK got as far as 
it took us!


> C++20 finally makes C++ a much less Lovecraftian nightmare

We're going to have template metaprogramming! SFinaE fhtagn!

Seriously, though. Operations as base classes, kernels / hardware specializations as 
subclasses, and the actual call being a virtual operator() call...


Thinks about this: Instead of the dispatcher bending the addresses symbols from shared 
libraries point to (as we do now), there could be a dispatcher object (possibly, but not 
necessary a singleton) with members of the operation class type, which get assigned 
instances of the optimal (according to prior volk_profile and/or heuristics) kernel 
implementation subclass.
I.e., instead of using our current nice trick to save the address of the correct 
_sig_in_kernel_sig_out_arch_alignment in volk_sig_in_kernel_sig_out_aligment, we just 
use the standard vtable/C++ polymorphism. Same performance at runtime - one CALL.

Immediate benefit: all these things suddenly become self-aware.
Let's add a self-documenting call that returns a const char* describing what this thing 
does. That makes people very happy when they wrap things for Python, because now the type 
comes with documentation in your IDE through little effort.
We can tell the user that this kernel prefers but doesn't need aligned memory. Or, much 
more bug-relevant, we could communicate the acceptable input multiples, and stop doing the 
cute "for the rest, we do the _general approach after the main loop is through in every 
single _arch_alignment" implementation.


(of course, I have far more somber dreams, don't assume the Lovecraftian horrors are too 
far from here. If each kernel implementation is a type, we can make these types have the 
capability (optional trait) to give us the type encapsulating what the VOLK kernel does in 
its "inner loop" (if applicable). Because C++ allows us to pass things like __mm256& and 
const __mm256&, we can then simply compose new inner loops. And of course, instead of 
implementing the same loop skeleton 200 times, we could just, for those kernels where the 
inner loop is "simple", have one templated


template
class loop_kernel {
   using op = nucleus_operation;
   operator()(std::span in, ...) {
for(auto ptr = in.begin(); ptr < in.end(); ptr += op::simd_width)
  op::operate(*ptr, ...)
   }
};

or so.)

Cheers!
Marcus


On 21.12.21 20:25, Nick Foster wrote:


On Tue, Dec 21, 2021 at 3:29 AM Marcus Müller > wrote:


Hi Johannes,

I, for one, like it :) Especially since I honestly find void
volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit 
clunky and would
rather call a type-safe, overloaded function in a volk namespace called
multiply_conjugate_add.


Yes, that's kind of my fault. It was the best option we could come up with to be 
rigorously type-specific in C, kind of a bespoke implementation of name mangling. The 
original motivation, of course, was the VOLK dispatcher. C was a hard requirement at the 
time, and I confess I don't remember why. I think it came down from namccart's original 
donation of vectorized code.


I would be very happy to see VOLK move to C++ (or at least provide wrappers). I strongly 
advocate for using C++20 -- std::span, variadic arguments, lambdas etc. seem tailor-made 
for VOLK. Runtime dispatching could be positively elegant, compared to how it must be done 
in C. And C++20 finally makes C++ a much less Lovecraftian nightmare of a language than 
the one I learned from Stroustrop.


Nick

Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?) 
to collect
these
comments?

You mention spans, so C++-VOLK would be >= C++20?

Cheers,
Marcus

On 21.12.21 10:55, Johannes Demel wrote:
 > Hi everyone,
 >
 > today I'd like to propose an idea for the future of VOLK. Currently, 
VOLK is a C
library
 > with a C++ interface and tooling that is written in C++.
 >
 > I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a 
C interface if
 > the need arises.
 >
 > This email serves as a request for comments. So go ahead.
 >
 > Benefits:
 > - sane std::complex interface.
 > - same compilation mode on all platforms.
 > - Better dynamic kernel load management.
 > - Option to use std::simd in the future
 > - Less manual memory management (think vector, ...).
 >
 > Drawbacks:
 > - It is a major effort.
 > - VOLK won't be a C project anymore.
 >
 > Why do I propose this shift?
 > VOLK segfaults on PowerPC architectures. This issue requires a breaking 
API change
to be
 > fixable. I tried to update the API to fix this isse.
 > https://github.com/gnuradio/volk/pull/488 

 > It works with GCC and 

Re: VOLK C++ core

[Nick Foster]

On Tue, Dec 21, 2021 at 3:29 AM Marcus Müller  wrote:

> Hi Johannes,
>
> I, for one, like it :) Especially since I honestly find void
> volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit
> clunky and would
> rather call a type-safe, overloaded function in a volk namespace called
> multiply_conjugate_add.
>
>
Yes, that's kind of my fault. It was the best option we could come up with
to be rigorously type-specific in C, kind of a bespoke implementation of
name mangling. The original motivation, of course, was the VOLK dispatcher.
C was a hard requirement at the time, and I confess I don't remember why. I
think it came down from namccart's original donation of vectorized code.

I would be very happy to see VOLK move to C++ (or at least provide
wrappers). I strongly advocate for using C++20 -- std::span, variadic
arguments, lambdas etc. seem tailor-made for VOLK. Runtime dispatching
could be positively elegant, compared to how it must be done in C. And
C++20 finally makes C++ a much less Lovecraftian nightmare of a language
than the one I learned from Stroustrop.

Nick


> Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?)
> to collect these
> comments?
>
> You mention spans, so C++-VOLK would be >= C++20?
>
> Cheers,
> Marcus
>
> On 21.12.21 10:55, Johannes Demel wrote:
> > Hi everyone,
> >
> > today I'd like to propose an idea for the future of VOLK. Currently,
> VOLK is a C library
> > with a C++ interface and tooling that is written in C++.
> >
> > I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a
> C interface if
> > the need arises.
> >
> > This email serves as a request for comments. So go ahead.
> >
> > Benefits:
> > - sane std::complex interface.
> > - same compilation mode on all platforms.
> > - Better dynamic kernel load management.
> > - Option to use std::simd in the future
> > - Less manual memory management (think vector, ...).
> >
> > Drawbacks:
> > - It is a major effort.
> > - VOLK won't be a C project anymore.
> >
> > Why do I propose this shift?
> > VOLK segfaults on PowerPC architectures. This issue requires a breaking
> API change to be
> > fixable. I tried to update the API to fix this isse.
> > https://github.com/gnuradio/volk/pull/488
> > It works with GCC and Clang but fails on MSVC.
> > One might argue that PowerPC is an obscure architecture at this point
> but new
> > architectures might cause the same issue in the future. Also, VOLK tries
> to be portable
> > and that kind of issue is a serious roadblock.
> >
> > How did we get into this mess?
> > The current API is a workaround to make things work for a specific
> compiler: MSVC. MSVC
> > does not support C `complex.h` at all. The trick to make things work
> with MSVC is:
> > compile VOLK in C++ mode and pretend it is a C++ library anyways.
> > In turn `volk_complex.h` defines complex data types differently
> depending if VOLK is
> > included in C or C++. Finally, we just hope that the target platform
> provides the same
> > ABI for C complex and C++ complex. C complex and C++ complex are not
> compatible.
> > However, passing pointers around is.
> > Thus, the proposed change does not affect Windows/MSVC users because
> they were excluded
> > from our C API anyways. The bullet point: "same compilation mode on all
> platforms"
> > refers to this issue.
> >
> > Proposed timeline:
> > Together with our re-licensing effort, we aim for a VOLK 3.0 release.
> VOLK 3.0 is a good
> > target for breaking API changes.
> >
> > Effects:
> > I'd like to make the transition to VOLK 3.0 as easy as possible. Thus,
> I'd like to keep
> > an interface that hopefully doesn't require any code changes for VOLK
> 2.x users. A
> > re-built of your application should be sufficient. However, we'd be able
> to adopt a
> > C++-ic API as well. e.g. use vectors, spans etc.
> >
> > The current implementation to detect and load the preferred
> implementation at runtime is
> > hard to understand and easy to break. C++ should offer more accessible
> tools to make
> > this part easier.
> >
> > What about all the current kernels?
> > We'd start with a new API and hide the old kernel code behind that
> interface. We come up
> > with a new implementation structure and how to load it. Thus, we can
> progressively
> > convert to "new-style" implementations.
> >
> > Another bonus: std::simd
> > Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib
> would allow us to
> > eventually use std::simd in VOLK and thus make Comms DSP algorithms more
> optimized on
> > more platforms.
> >
> > Cheers
> > Johannes
> >
>
>

UHD 4.1.0.5 released!

[Aaron Rossetto]

Hello GNU Radio Community and friends of UHD,

UHD 4.1.0.5 has been released!

Apart from some minor enhancements and bugfixes (see below for the complete
changelog), UHD 4.1.0.5 adds support for the NI Ettus USRP X410 Rev G,
which uses a different CPLD on the motherboard than previous revisions.
Please note that the X410 filesystem image that ships with versions of UHD
prior to 4.1.0.5 **will not** support newer revisions of the USRP X410;
thus, we strongly recommend that **all** USRP X410 users upgrade their
devices with the filesystem that ships with 4.1.0.5. Please refer to the
instructions under 'Updating Filesystems' in the USRP X4xx section of the
UHD manual at https://files.ettus.com/manual/page_usrp_x4xx.html for
information on how to perform the update.

* ad9361
  -  Add comment re overclocking
  -  Modify set-tx-gain procedure to update gain in one go
* b200
  -  Re-sync times
  -  Move the B200 radio control core into usrp/b200/
* cal
  -  Use safe version of set_thread_priority()
* ci
  -  Device wait to redlock scope for Vivado close
  -  Add Fedora 34 and remove Fedora 32
  -  Refactor installers and add Windows support
  -  Add custom boost version support
  -  Remove documentation-only changes from pipeline runs
  -  enable batch CI
  -  Split CI and PR pipelines for mono pipeline
  -  Enable custom CXX flags, enable -Werror
  -  Let make keep building upon failure
  -  Add clang as a compiler to all Fedora and Ubuntu containers
* cmake
  -  use LooseVersion to ensure correct version comparisons
  -  Fix rfnoc-example (CMake paths)
  -  Fix issues with static builds and CMRC
  -  Replace CMAKE_{SOURCE,BINARY}_DIR with UHD_*_DIR
  -  tests: Add build-python path to PYTHONPATH
  -  Add check for libatomic linking requirement
  -  remove duplicate entry in LIBUHD_PYTHON_GEN_SOURCE
  -  Fix VS names and use relative for images
* dbsrx
  -  Fix issue with loop variable
* debs
  -  Update upload_debs script
* devtest
  -  Clarify data type in multi_usrp_test::send_waveform()
  -  Add receive stability test to B2xx devtest
  -  Add receive stability test
* dissectors
  -  Fix whitespace formatting in CMake files
  -  Fix inclusion of glib.h and Python version
* docs
  -  Several minor manual improvements
  -  Collect all RFNoC block controllers in a module in the manual
  -  Align dependencies and bump deb package versions
  -  Clarify set/get_gpio_attr() and GPIO banks
  -  Fix GPIO documentation example
  -  x410: Fix info on loading SD card images with bmaptool
  -  Improve docs for rx_streamer::recv() on overruns
  -  sync: Update page on synchronization
  -  Fix typo in ZBX Block Diagram
  -  x4xx: Document configuring eth0 static IP
  -  Remove bmaptool instructions for writing filesystems
* examples
  -  Use cmul for gain block in-tree IP example
  -  Test all variants in gain testbench
  -  Make IQ order clear in gain RFNoC block
  -  Improve txrx_loopback_to_file (late recv, Boost, timing)
  -  Show how to use in-tree Verilog header
  -  Add x400/x410 target to RFNoC example
  -  gpio: Separate bank and port arguments
  -  usrp_power_meter: fix channel indexing when reading USRP power
* fpga
  -  Revert "Add ability to get time from Radio block"
  -  Add ability to get time from Radio block
  -  rfnoc: Add RFNoC CHDR resize module
  -  rfnoc: Add CHDR management util functions
  -  lib: Clean up axi_mux
  -  rfnoc: Add labels to axi_switch generate blocks
  -  rfnoc: Add labels to chdr_mgmt_pkt_handler
  -  rfnoc: Add documentation to chdr_xb_routing_table
  -  Shorten line length for Launchpad linter
  -  x300: Update synchronizer constraint
  -  n3xx: Update synchronizer constraint
  -  lib: Update example constraint in synchronizer
  -  Update help message for setupenv.sh
  -  Remove stale references to UHD_FPGA_DIR
  -  tools: Add UHD_FPGA_DIR definition to synthesis
  -  Set default part for sim in setupenv.sh
  -  Fix Xilinx bitfile parser for Python 3
  -  rfnoc: Fix EOB loss in DUC
  -  sim: Add PkgComplex, PkgMath, and PkgRandom
  -  lib: Clean up and document lib files
  -  x400: Remove stale information in register map
  -  ci: Add testbench pipeline
* host
  -  Revert "Add ability to get time from Radio block"
  -  Add ability to get time from Radio block
  -  python: Return mb_controller with reference_internal
  -  x4xx: Implement GPIO API
  -  Add GPIO functions to MPM RPC shim
  -  gpio: Create gpio_atr_offsets to store GPIO registers
* images
  -  Update image packager script for Python 3
* lib
  -  Remove all remaining usage of boost::numeric::bounds<>
  -  transport: Mark typecast as intended
  -  transport: Initialize _hshake_args_server
  -  rfnoc: Make implicit typecasts explicit
  -  rfnoc: Change enum node_type to enum class
  -  Add various missing includes
* libusb
  -  Remove unused context variable
* mpm
  -  x4xx: update mboard_max_rev
  -  x4xx: Allow GPIO0 and GPIO1 as port names
  -  x4xx: add DIO GPIO API configuration methods
  -  mpm: x4xx: Add checks 

Re: VOLK C++ core

[Marcus Müller]

True, but with Pybind11, we at least get direct python->C++ bindings which *can* allow for 
in-place modification of appropriately typed numpy arrays. For other languages, the C 
layer should be pretty much a zero-overhead redirection (or so I hope), just like it's 
theoretically useful right now.



On 21.12.21 16:08, Albin Stigö wrote:

I like the idea. It will make it difficult to use volk with other language's 
FFI though.

--Albin

On Tue, Dec 21, 2021, 12:27 Marcus Müller > wrote:


Hi Johannes,

I, for one, like it :) Especially since I honestly find void
volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit 
clunky and would
rather call a type-safe, overloaded function in a volk namespace called
multiply_conjugate_add.

Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?) 
to collect
these
comments?

You mention spans, so C++-VOLK would be >= C++20?

Cheers,
Marcus

On 21.12.21 10:55, Johannes Demel wrote:
 > Hi everyone,
 >
 > today I'd like to propose an idea for the future of VOLK. Currently, 
VOLK is a C
library
 > with a C++ interface and tooling that is written in C++.
 >
 > I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a 
C interface if
 > the need arises.
 >
 > This email serves as a request for comments. So go ahead.
 >
 > Benefits:
 > - sane std::complex interface.
 > - same compilation mode on all platforms.
 > - Better dynamic kernel load management.
 > - Option to use std::simd in the future
 > - Less manual memory management (think vector, ...).
 >
 > Drawbacks:
 > - It is a major effort.
 > - VOLK won't be a C project anymore.
 >
 > Why do I propose this shift?
 > VOLK segfaults on PowerPC architectures. This issue requires a breaking 
API change
to be
 > fixable. I tried to update the API to fix this isse.
 > https://github.com/gnuradio/volk/pull/488 

 > It works with GCC and Clang but fails on MSVC.
 > One might argue that PowerPC is an obscure architecture at this point 
but new
 > architectures might cause the same issue in the future. Also, VOLK tries 
to be
portable
 > and that kind of issue is a serious roadblock.
 >
 > How did we get into this mess?
 > The current API is a workaround to make things work for a specific 
compiler: MSVC.
MSVC
 > does not support C `complex.h` at all. The trick to make things work 
with MSVC is:
 > compile VOLK in C++ mode and pretend it is a C++ library anyways.
 > In turn `volk_complex.h` defines complex data types differently 
depending if VOLK is
 > included in C or C++. Finally, we just hope that the target platform 
provides the same
 > ABI for C complex and C++ complex. C complex and C++ complex are not 
compatible.
 > However, passing pointers around is.
 > Thus, the proposed change does not affect Windows/MSVC users because 
they were
excluded
 > from our C API anyways. The bullet point: "same compilation mode on all 
platforms"
 > refers to this issue.
 >
 > Proposed timeline:
 > Together with our re-licensing effort, we aim for a VOLK 3.0 release. 
VOLK 3.0 is a
good
 > target for breaking API changes.
 >
 > Effects:
 > I'd like to make the transition to VOLK 3.0 as easy as possible. Thus, 
I'd like to
keep
 > an interface that hopefully doesn't require any code changes for VOLK 
2.x users. A
 > re-built of your application should be sufficient. However, we'd be able 
to adopt a
 > C++-ic API as well. e.g. use vectors, spans etc.
 >
 > The current implementation to detect and load the preferred 
implementation at
runtime is
 > hard to understand and easy to break. C++ should offer more accessible 
tools to make
 > this part easier.
 >
 > What about all the current kernels?
 > We'd start with a new API and hide the old kernel code behind that 
interface. We
come up
 > with a new implementation structure and how to load it. Thus, we can 
progressively
 > convert to "new-style" implementations.
 >
 > Another bonus: std::simd
 > Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib 
would allow us to
 > eventually use std::simd in VOLK and thus make Comms DSP algorithms more 
optimized on
 > more platforms.
 >
 > Cheers
 > Johannes
 >

Re: VOLK C++ core

[John Sallay]

If nothing else I think there is a lot of value in adding c++ wrappers to
volk. I don't have a strong opinion on an underlying base of c or c++, but
would like for it to be easier to use in c++. A common approach with other
c libraries like zeromq is to make a header only c++ wrapper. This would
take a lot less work to implement, but only provides some of the advantages
you mention.

What version of c++ would you target? I would recommend c++20 so that you
can define a concept for a vector like object to use as arguments to these
functions (or at least a concept based wrapper)

On Tue, Dec 21, 2021, 5:21 AM Johannes Demel 
wrote:

> Hi everyone,
>
> today I'd like to propose an idea for the future of VOLK. Currently,
> VOLK is a C library with a C++ interface and tooling that is written in
> C++.
>
> I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a
> C interface if the need arises.
>
> This email serves as a request for comments. So go ahead.
>
> Benefits:
> - sane std::complex interface.
> - same compilation mode on all platforms.
> - Better dynamic kernel load management.
> - Option to use std::simd in the future
> - Less manual memory management (think vector, ...).
>
> Drawbacks:
> - It is a major effort.
> - VOLK won't be a C project anymore.
>
> Why do I propose this shift?
> VOLK segfaults on PowerPC architectures. This issue requires a breaking
> API change to be fixable. I tried to update the API to fix this isse.
> https://github.com/gnuradio/volk/pull/488
> It works with GCC and Clang but fails on MSVC.
> One might argue that PowerPC is an obscure architecture at this point
> but new architectures might cause the same issue in the future. Also,
> VOLK tries to be portable and that kind of issue is a serious roadblock.
>
> How did we get into this mess?
> The current API is a workaround to make things work for a specific
> compiler: MSVC. MSVC does not support C `complex.h` at all. The trick to
> make things work with MSVC is: compile VOLK in C++ mode and pretend it
> is a C++ library anyways.
> In turn `volk_complex.h` defines complex data types differently
> depending if VOLK is included in C or C++. Finally, we just hope that
> the target platform provides the same ABI for C complex and C++ complex.
> C complex and C++ complex are not compatible. However, passing pointers
> around is.
> Thus, the proposed change does not affect Windows/MSVC users because
> they were excluded from our C API anyways. The bullet point: "same
> compilation mode on all platforms" refers to this issue.
>
> Proposed timeline:
> Together with our re-licensing effort, we aim for a VOLK 3.0 release.
> VOLK 3.0 is a good target for breaking API changes.
>
> Effects:
> I'd like to make the transition to VOLK 3.0 as easy as possible. Thus,
> I'd like to keep an interface that hopefully doesn't require any code
> changes for VOLK 2.x users. A re-built of your application should be
> sufficient. However, we'd be able to adopt a C++-ic API as well. e.g.
> use vectors, spans etc.
>
> The current implementation to detect and load the preferred
> implementation at runtime is hard to understand and easy to break. C++
> should offer more accessible tools to make this part easier.
>
> What about all the current kernels?
> We'd start with a new API and hide the old kernel code behind that
> interface. We come up with a new implementation structure and how to
> load it. Thus, we can progressively convert to "new-style" implementations.
>
> Another bonus: std::simd
> Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib
> would allow us to eventually use std::simd in VOLK and thus make Comms
> DSP algorithms more optimized on more platforms.
>
> Cheers
> Johannes
>
>

Re: VOLK C++ core

[Albin Stigö]

I like the idea. It will make it difficult to use volk with other
language's FFI though.

--Albin

On Tue, Dec 21, 2021, 12:27 Marcus Müller  wrote:

> Hi Johannes,
>
> I, for one, like it :) Especially since I honestly find void
> volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit
> clunky and would
> rather call a type-safe, overloaded function in a volk namespace called
> multiply_conjugate_add.
>
> Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?)
> to collect these
> comments?
>
> You mention spans, so C++-VOLK would be >= C++20?
>
> Cheers,
> Marcus
>
> On 21.12.21 10:55, Johannes Demel wrote:
> > Hi everyone,
> >
> > today I'd like to propose an idea for the future of VOLK. Currently,
> VOLK is a C library
> > with a C++ interface and tooling that is written in C++.
> >
> > I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a
> C interface if
> > the need arises.
> >
> > This email serves as a request for comments. So go ahead.
> >
> > Benefits:
> > - sane std::complex interface.
> > - same compilation mode on all platforms.
> > - Better dynamic kernel load management.
> > - Option to use std::simd in the future
> > - Less manual memory management (think vector, ...).
> >
> > Drawbacks:
> > - It is a major effort.
> > - VOLK won't be a C project anymore.
> >
> > Why do I propose this shift?
> > VOLK segfaults on PowerPC architectures. This issue requires a breaking
> API change to be
> > fixable. I tried to update the API to fix this isse.
> > https://github.com/gnuradio/volk/pull/488
> > It works with GCC and Clang but fails on MSVC.
> > One might argue that PowerPC is an obscure architecture at this point
> but new
> > architectures might cause the same issue in the future. Also, VOLK tries
> to be portable
> > and that kind of issue is a serious roadblock.
> >
> > How did we get into this mess?
> > The current API is a workaround to make things work for a specific
> compiler: MSVC. MSVC
> > does not support C `complex.h` at all. The trick to make things work
> with MSVC is:
> > compile VOLK in C++ mode and pretend it is a C++ library anyways.
> > In turn `volk_complex.h` defines complex data types differently
> depending if VOLK is
> > included in C or C++. Finally, we just hope that the target platform
> provides the same
> > ABI for C complex and C++ complex. C complex and C++ complex are not
> compatible.
> > However, passing pointers around is.
> > Thus, the proposed change does not affect Windows/MSVC users because
> they were excluded
> > from our C API anyways. The bullet point: "same compilation mode on all
> platforms"
> > refers to this issue.
> >
> > Proposed timeline:
> > Together with our re-licensing effort, we aim for a VOLK 3.0 release.
> VOLK 3.0 is a good
> > target for breaking API changes.
> >
> > Effects:
> > I'd like to make the transition to VOLK 3.0 as easy as possible. Thus,
> I'd like to keep
> > an interface that hopefully doesn't require any code changes for VOLK
> 2.x users. A
> > re-built of your application should be sufficient. However, we'd be able
> to adopt a
> > C++-ic API as well. e.g. use vectors, spans etc.
> >
> > The current implementation to detect and load the preferred
> implementation at runtime is
> > hard to understand and easy to break. C++ should offer more accessible
> tools to make
> > this part easier.
> >
> > What about all the current kernels?
> > We'd start with a new API and hide the old kernel code behind that
> interface. We come up
> > with a new implementation structure and how to load it. Thus, we can
> progressively
> > convert to "new-style" implementations.
> >
> > Another bonus: std::simd
> > Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib
> would allow us to
> > eventually use std::simd in VOLK and thus make Comms DSP algorithms more
> optimized on
> > more platforms.
> >
> > Cheers
> > Johannes
> >
>
>

Re: Peaks when increasing the FFT lenght ofdm example

[pv]

Hi Johannes,

First of all thanks for the quick response and time with my problem.

I've made a text file with all specifications of my OFDM example that  
can be found in the attachments of this mail.


Thanks again with your help and anything more just let me know.

Best regards,
Pedro Viegas






Citando Johannes Demel :


Hi Pedro,

we'd need more info to tell why you observe these peaks. How large  
are your input packets? Do they span multiple OFDM symbols? How many  
subcarriers are active?


Your peaks hint at some kind of repetition or lot's of zeros.

Cheers
Johannes


On 14.12.21 13:07, Pedro Viegas wrote:

Hi everyone,

I'm having a problem when I increase the number of carriers from 64  
to 512 in the gnuradio OFDM example. When the number of carriers is  
512, the complex envelope of the signal in the time domain has some  
peaks, which I can not have for the test I'm trying to make. Can  
anyone tell why there are those peaks and how I get rid of them?
A possible cause for the peaks, in my opinion, can be the fixed  
frame len of the header, that is filled with zeros when the FFT  
size increases, resulting in a peak in the beginning of each frame  
because of the ifft block. If this is the problem, how can I change  
that frame len?
To better show what I'm saying, there is an image on the  
attachments of the complex envelope with the peaks.


Thanks in advance,
Pedro Viegas



--
Pedro Viegas
DSP Engineer
Koala Tech
phone: +351 917 354 070
e-mail: p...@koalatech.pt



512 carriers GRC
Description: Binary data

Re: VOLK C++ core

[Marcus Müller]

Hi Johannes,

I, for one, like it :) Especially since I honestly find void 
volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit clunky and would 
rather call a type-safe, overloaded function in a volk namespace called 
multiply_conjugate_add.


Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?) to collect these 
comments?


You mention spans, so C++-VOLK would be >= C++20?

Cheers,
Marcus

On 21.12.21 10:55, Johannes Demel wrote:

Hi everyone,

today I'd like to propose an idea for the future of VOLK. Currently, VOLK is a C library 
with a C++ interface and tooling that is written in C++.


I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a C interface if 
the need arises.


This email serves as a request for comments. So go ahead.

Benefits:
- sane std::complex interface.
- same compilation mode on all platforms.
- Better dynamic kernel load management.
- Option to use std::simd in the future
- Less manual memory management (think vector, ...).

Drawbacks:
- It is a major effort.
- VOLK won't be a C project anymore.

Why do I propose this shift?
VOLK segfaults on PowerPC architectures. This issue requires a breaking API change to be 
fixable. I tried to update the API to fix this isse.

https://github.com/gnuradio/volk/pull/488
It works with GCC and Clang but fails on MSVC.
One might argue that PowerPC is an obscure architecture at this point but new 
architectures might cause the same issue in the future. Also, VOLK tries to be portable 
and that kind of issue is a serious roadblock.


How did we get into this mess?
The current API is a workaround to make things work for a specific compiler: MSVC. MSVC 
does not support C `complex.h` at all. The trick to make things work with MSVC is: 
compile VOLK in C++ mode and pretend it is a C++ library anyways.
In turn `volk_complex.h` defines complex data types differently depending if VOLK is 
included in C or C++. Finally, we just hope that the target platform provides the same 
ABI for C complex and C++ complex. C complex and C++ complex are not compatible. 
However, passing pointers around is.
Thus, the proposed change does not affect Windows/MSVC users because they were excluded 
from our C API anyways. The bullet point: "same compilation mode on all platforms" 
refers to this issue.


Proposed timeline:
Together with our re-licensing effort, we aim for a VOLK 3.0 release. VOLK 3.0 is a good 
target for breaking API changes.


Effects:
I'd like to make the transition to VOLK 3.0 as easy as possible. Thus, I'd like to keep 
an interface that hopefully doesn't require any code changes for VOLK 2.x users. A 
re-built of your application should be sufficient. However, we'd be able to adopt a 
C++-ic API as well. e.g. use vectors, spans etc.


The current implementation to detect and load the preferred implementation at runtime is 
hard to understand and easy to break. C++ should offer more accessible tools to make 
this part easier.


What about all the current kernels?
We'd start with a new API and hide the old kernel code behind that interface. We come up 
with a new implementation structure and how to load it. Thus, we can progressively 
convert to "new-style" implementations.


Another bonus: std::simd
Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib would allow us to 
eventually use std::simd in VOLK and thus make Comms DSP algorithms more optimized on 
more platforms.


Cheers
Johannes

VOLK C++ core

[Johannes Demel]

Hi everyone,

today I'd like to propose an idea for the future of VOLK. Currently, 
VOLK is a C library with a C++ interface and tooling that is written in C++.


I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a 
C interface if the need arises.


This email serves as a request for comments. So go ahead.

Benefits:
- sane std::complex interface.
- same compilation mode on all platforms.
- Better dynamic kernel load management.
- Option to use std::simd in the future
- Less manual memory management (think vector, ...).

Drawbacks:
- It is a major effort.
- VOLK won't be a C project anymore.

Why do I propose this shift?
VOLK segfaults on PowerPC architectures. This issue requires a breaking 
API change to be fixable. I tried to update the API to fix this isse.

https://github.com/gnuradio/volk/pull/488
It works with GCC and Clang but fails on MSVC.
One might argue that PowerPC is an obscure architecture at this point 
but new architectures might cause the same issue in the future. Also, 
VOLK tries to be portable and that kind of issue is a serious roadblock.


How did we get into this mess?
The current API is a workaround to make things work for a specific 
compiler: MSVC. MSVC does not support C `complex.h` at all. The trick to 
make things work with MSVC is: compile VOLK in C++ mode and pretend it 
is a C++ library anyways.
In turn `volk_complex.h` defines complex data types differently 
depending if VOLK is included in C or C++. Finally, we just hope that 
the target platform provides the same ABI for C complex and C++ complex. 
C complex and C++ complex are not compatible. However, passing pointers 
around is.
Thus, the proposed change does not affect Windows/MSVC users because 
they were excluded from our C API anyways. The bullet point: "same 
compilation mode on all platforms" refers to this issue.


Proposed timeline:
Together with our re-licensing effort, we aim for a VOLK 3.0 release. 
VOLK 3.0 is a good target for breaking API changes.


Effects:
I'd like to make the transition to VOLK 3.0 as easy as possible. Thus, 
I'd like to keep an interface that hopefully doesn't require any code 
changes for VOLK 2.x users. A re-built of your application should be 
sufficient. However, we'd be able to adopt a C++-ic API as well. e.g. 
use vectors, spans etc.


The current implementation to detect and load the preferred 
implementation at runtime is hard to understand and easy to break. C++ 
should offer more accessible tools to make this part easier.


What about all the current kernels?
We'd start with a new API and hide the old kernel code behind that 
interface. We come up with a new implementation structure and how to 
load it. Thus, we can progressively convert to "new-style" implementations.


Another bonus: std::simd
Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib 
would allow us to eventually use std::simd in VOLK and thus make Comms 
DSP algorithms more optimized on more platforms.


Cheers
Johannes