As I am investigating GPU and OpenCL for acceerating correlation computations, I thought I'd give OpenCL-Enabled FFT block in GNU Radio Companion (still version 3.7.13.4) a try to see if I can see any performance change. When I run signal source -> throttle -> OpenCL FFT -> time sink, all goes well, the spectrum *looks* similar to the GNU Radio FFT (CPU) output. So far so good. If I now run the correlation graph found at http://jmfriedt.org/opencl/opencl_xcorr_grc.png the correlation surprisingly is non existent as seen at http://jmfriedt.org/opencl/nosubtract.png (top chart is CPU computation of the correlation as iFFT(FFT(signal).FFT(delayed signal)^* with a fine correlation peak on the right, and bottom chart is the same through the OpenCL FFT). Running the same chart but fed with a periodic signal (square wave) does show a set of correlation peaks spaced by the square wave period as shown at http://jmfriedt.org/opencl/nosubstract_square.png hinting at a synchronization issue with the two OpenCL blocks being fed random sequences sampled at different time. Trying to display the difference between the two correlations (output of the complex conjucate multiplication) actually seems to solve the issue as seen at http://jmfriedt.org/opencl/withsubtract.png where the correlation peak suddenly appears after a fraction of a second of running the flowchart, so the GNU Radio scheduler seems to be affected by this new subtraction chain. Yet, notice that the subtraction between the two correlation processing chains (top chart) is not 0, unlike running the same flowchart with subtraction on the periodic square wave (http://jmfriedt.org/opencl/withsubstract_square.png) which does show a null error.
I don't have an explanation, not even sure there is an obvious one, but at least wanted to share these observations with the community. JM _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
