ghostop14/gr-clenabled

OpenCL/GPU-enabled common blocks for GNURadio

gr-clenabled's Issues

GRC: Error in CL FFT block for GNURadio 3.8

Problems in issue #2158 is now existing in GR 3.8. I am observing this in CL-FFT blocks.

Fixes in #1925 is already implemented in GR 3.8. However still the problem exists. Probably some modifications are necessary to this OOT module.

FFT size > 4096

Hello,

Whenever I run openCL_Test-FFT.grc with fftsize > 4096, I receive:

:88:21408: error: invalid digit '9' in octal constant
:88:21481: error: invalid digit '9' in octal constant
:88:21602: error: invalid digit 'f' in decimal constant
:88:21690: error: invalid digit 'f' in decimal constant
:88:21778: error: invalid digit 'f' in decimal constant
:88:21866: error: invalid digit 'f' in decimal constant
:88:21954: error: invalid digit 'f' in decimal constant
:88:22042: error: invalid digit 'f' in decimal constant

Any fixing suggestion?

BR, Josh

AttributeError: 'module' object has no attribute 'myclSignalSource'

After successful make and install i am facing this Attribute error for all the blocks in the package.
Though the test script for the package runs successfully.

Compiling Issues

I'm not an expert in OpenCL, so I'm having some issues compiling it on a Ubuntu 16.04:

┌─[lucas@nblucas] - [/media/ELTN/Works/gr-clenabled/build] - [Qui Set 07, 22:25]
└─[$] <git:(master*)> make  
[  1%] Building CXX object lib/CMakeFiles/clview.dir/clview.cc.o
In file included from /usr/local/cuda-8.0/include/CL/opencl.h:42:0,
                 from /usr/local/cuda-8.0/include/CL/cl.hpp:170,
                 from /media/ELTN/Works/gr-clenabled/lib/clview.cc:14:
/usr/local/cuda-8.0/include/CL/cl.h:183:0: warning: "CL_VERSION_1_2" redefined
 #define CL_VERSION_1_2                              1
 ^
/media/ELTN/Works/gr-clenabled/lib/clview.cc:9:0: note: this is the location of the previous definition
 #define CL_VERSION_1_2
 ^
/media/ELTN/Works/gr-clenabled/lib/clview.cc: In function ‘int main(int, char**)’:
/media/ELTN/Works/gr-clenabled/lib/clview.cc:93:14: error: ‘cl_device_svm_capabilities’ was not declared in this scope
              cl_device_svm_capabilities caps;
              ^
/media/ELTN/Works/gr-clenabled/lib/clview.cc:95:49: error: ‘CL_DEVICE_SVM_CAPABILITIES’ was not declared in this scope
              err = clGetDeviceInfo(devices[j](),CL_DEVICE_SVM_CAPABILITIES,
                                                 ^
/media/ELTN/Works/gr-clenabled/lib/clview.cc:96:56: error: ‘caps’ was not declared in this scope
                    sizeof(cl_device_svm_capabilities),&caps,0);
                                                        ^
/media/ELTN/Works/gr-clenabled/lib/clview.cc:98:69: error: ‘CL_DEVICE_SVM_FINE_GRAIN_BUFFER’ was not declared in this scope
              bool hasSVMFineGrained = (err == CL_SUCCESS && (caps & CL_DEVICE_SVM_FINE_GRAIN_BUFFER));
                                                                     ^
lib/CMakeFiles/clview.dir/build.make:62: recipe for target 'lib/CMakeFiles/clview.dir/clview.cc.o' failed
make[2]: *** [lib/CMakeFiles/clview.dir/clview.cc.o] Error 1
CMakeFiles/Makefile2:145: recipe for target 'lib/CMakeFiles/clview.dir/all' failed
make[1]: *** [lib/CMakeFiles/clview.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

3.10 Mint 21 build problems (boost and iomanip)

I'm trying to build on Mint 21 for gnuradio 3.10, and I'm running into several issues. The first is the need to use updated cl headers, as discussed in the existing issue.

The next issue is with boost. 1.74 is installed, and I get similar issues with undefined references to filesystem classes/operators as what is described in volk issue 242. I propose that we switch to std::filesystem and requires c++17, which if I understood correctly is required for gr 3.10 anyhow.

Lastly, it appears that we need to add a few includes for to resolve some other errors. I don't fully understand why this is necessary when it wasn't before.

I plan to update my fork with what will at least build, but I'm not sure these changes are actually the right answers to the problems so I'm not quite ready to make pull request. Advice/direction is welcome.

Compinling fails with CUDA 12

Hey, I want to implement a GNU Radio 250 Msps transceiver and the bottleneck is the filters, so I hope someone can help me get this to work, since this implementation looks quite promising to me.

I think the problem is that I have a newer setup with Ubuntu 22.04 and CUDA-12. CMake runs normally, but with make I get the following error. Could this be related to issue #4 ?

$ cmake ..
-- The CXX compiler identification is GNU 11.4.0
-- The C compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") 
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Checking for module 'gmp'
--   Found gmp, version 6.2.1
-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so  
-- Using GMP.
-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so  
-- Found Boost: /usr/local/lib/cmake/Boost-1.84.0/BoostConfig.cmake (found suitable version "1.84.0", minimum required is "1.84.0") found components: date_time program_options system regex thread unit_test_framework 
-- Found Volk: Volk::volk  
-- User set python executable /usr/bin/python3
-- Found PythonInterp: /usr/bin/python3 (found version "3.10.12") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.10.so (found suitable exact version "3.10.12") 
-- Found Git: /usr/bin/git  
-- Extracting version information from git describe...
fatal: No names found, cannot describe anything.
-- Looking for CL_VERSION_2_1
-- Looking for CL_VERSION_2_1 - found
-- Found OpenCL: /usr/lib/x86_64-linux-gnu/libOpenCL.so (found version "2.1") 
STATUS,"Found cl2.hpp"
CMake Warning (dev) at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (CLFFT) does
  not match the name of the calling package (clFFT).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/Modules/FindclFFT.cmake:59 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:136 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found CLFFT: /usr/lib/x86_64-linux-gnu/libclFFT.so  
-- Found OpenMP_C: -fopenmp (found version "4.5") 
-- Found OpenMP_CXX: -fopenmp (found version "4.5") 
-- Found OpenMP: TRUE (found version "4.5")  
-- Found Doxygen: /usr/bin/doxygen (found version "1.9.1") found components: doxygen dot 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.10.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /usr/include (found version "2.9.1")
-- Using install prefix: /usr/local
-- Building for version: gfbfa98d / 1.0.0git
-- PYTHON and GRC components are enabled
-- Python checking for pygccxml - found
-- Configuring done
-- Generating done
-- Build files have been written to: /home/hhi/Software/gr-clenabled/build


$ make 
[  1%] Building CXX object lib/CMakeFiles/gnuradio-clenabled.dir/clMathConst_impl.cc.o
In file included from /home/hhi/Software/gr-clenabled/lib/../include/clenabled/GRCLBase.h:49,
                 from /home/hhi/Software/gr-clenabled/lib/clMathConst_impl.h:25,
                 from /home/hhi/Software/gr-clenabled/lib/clMathConst_impl.cc:26:
/usr/include/CL/cl.hpp:1684:1: error: ‘CL_SEMAPHORE_DEVICE_HANDLE_LIST_KHR’ was not declared in this scope; did you mean ‘CL_DEVICE_HANDLE_LIST_KHR’?
 1684 | CL_HPP_PARAM_NAME_CL_KHR_SEMAPHORE_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/cl.hpp:1684:1: error: template argument 2 is invalid
 1684 | CL_HPP_PARAM_NAME_CL_KHR_SEMAPHORE_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [lib/CMakeFiles/gnuradio-clenabled.dir/build.make:76: lib/CMakeFiles/gnuradio-clenabled.dir/clMathConst_impl.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:265: lib/CMakeFiles/gnuradio-clenabled.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

GNC Window Crashes When Changing QT GUI Range

I just installed maint-3.7 using cuda 10.2, and started experimenting with the OpenCL Low Pass Filter.

It seems to run fine, except when I have a variable for Beta. When I move the slider, the frequency sink screen crashes. The file input is just a 2 second recording of noise that I had made at one time.

The output of GNC when it starts up and is running is as follows:

Generating: '/home/jas/flow/test_opencl_lowpass.py'
Executing: /usr/bin/python2 -u /home/jas/flow/test_opencl_lowpass.py

OpenCL INFO: Filter is using kernel code with faster constant memory.

But when it crashes, I get two additional lines before it gets to Done:

Executing: /usr/bin/python2 -u /home/jas/flow/test_opencl_lowpass.py

OpenCL INFO: Filter is using kernel code with faster constant memory.
OpenCL INFO: Filter is using kernel code with faster constant memory.
OpenCL INFO: Filter is using kernel code with faster constant memory.

>>> Done

Any ideas what might be happening?

Note that this does not happen if I simply select bypass for the OpenCL block.

I'm new to CUDA and openCL, but I want to get better... :)
Thanks.

missing Frequency Xlating FIR Filter

Hello ghostop14,
thank you for this great project!

Will the missing channelizers, especially the Frequency Xlating FIR Filter, also added to your project?

This would make me very happy. :-)

Discontinuities using Tap-based Filter

I was testing some filters out and noticed that there appear to be some discontinuities using the OpenCL Tap-based Filter. The discontinuity can be seen here:

where my flow graph is:

OpenCL_Test-FIR.grc.gz

And I am getting an interesting display on the Frequency sink, where at times (as opposed to the first attached pic), it will look like:

Does this seem like an issue? Or am I doing something incorrectly?

I'm using the following configurations:

• Ubuntu: 18.04 LTS
• gr-clenabled: maint-3.8 (11b091)
• gnuradio: v3.8.2.0-102-gcc5a816b

Thanks!

PFB Clock Recovery Block

Could you add the PFB Clock Recovery Block from GNU RADIO. It contains a lot of filters which can be paralellized.

Compilation error: cerr is not a member of std

I'm compiling from git and this happens:

[ 26%] Building CXX object lib/CMakeFiles/gnuradio-clenabled.dir/fast_atan2f.cc.o
/home/feanor/Development/gr-clenabled/lib/fft_filter.cc: In member function ‘virtual void gr::clenabled::fft_filter_ccf::compute_sizes(int)’:
/home/feanor/Development/gr-clenabled/lib/fft_filter.cc:79:10: error: ‘cerr’ is not a member of ‘std’
     std::cerr << "fft_filter_ccf: ntaps = " << d_ntaps
          ^~~~
/home/feanor/Development/gr-clenabled/lib/fft_filter.cc:79:10: note: suggested alternative: ‘errc’
     std::cerr << "fft_filter_ccf: ntaps = " << d_ntaps
          ^~~~
          errc
[ 28%] Building CXX object lib/CMakeFiles/gnuradio-clenabled.dir/clFFT_impl.cc.o

Adding #include <iostream> at that offending source code fixes the problem and now the code compiles

complex taps

If the filter tab in the opencl tap-based filter block is complexed, how should we import it?

using opencl 2 cl2.hpp

Hello,

First, thanks for your job.
I work for many personal project about gnuradio.

I would try to test your blocks but i can't compile them.
I work on ubuntu 16.04 and open library was version 2 with cl2.hpp.

Do you think it is possible to modify your code for use new opencl library ?

Thanks in advance!

(Request) Gr-Iridium clenabled blocks possible?

Would it be possible, assuming it would help offload processing off the cpu, to update some of the blocks specific to gr-iridium?

https://github.com/muccc/gr-iridium/tree/master/grc