Also known as: GPU DSP, GPU signal processing, GPU-accelerated DSP
GPU DSP is the practice of running digital signal processing on a graphics processing unit instead of, or alongside, a CPU, exploiting the GPU’s thousands of small cores to process many samples at once.1 Radio DSP is full of operations that apply the same arithmetic to huge blocks of independent samples — FFTs, FIR filtering, mixing, channelization, correlation — and that “same operation, many data” shape is exactly what a GPU is built for. It is the large-scale cousin of SIMD vectorization on the CPU: where SIMD widens one core to a handful of lanes, a GPU spreads the work across thousands.
How it works
A GPU program (a kernel) is written once and launched across a grid of thousands of threads; each thread handles one sample, one FFT bin, or one filter output. The programming model is CUDA on NVIDIA hardware or the vendor-neutral OpenCL/SYCL elsewhere — both are forms of general-purpose GPU computing. Vendor libraries do the heavy lifting: cuFFT and clFFT compute batched FFTs, and a channelizer is often expressed as a large batch of small transforms plus a polyphase filter, which maps beautifully onto the GPU’s batching model.
The catch is data movement. Samples must be copied across the PCIe bus into GPU memory and results copied back, and each kernel launch has fixed overhead. GPU DSP therefore only wins when the block of work is large enough that compute dwarfs transfer time — wide bandwidths, long FFTs, many channels, or deep filter banks. For a single narrowband channel the copies cost more than they save, and a CPU with SIMD finishes first. Good GPU pipelines hide the transfers by overlapping copy and compute (streaming) and by keeping intermediate results resident on the device across successive stages.
In practice
GPU acceleration pays off at the extremes of scale: real-time processing of tens or hundreds of MHz, spectrum-monitoring systems that FFT enormous bands continuously, phased-array and radar back ends, and RF machine-learning training where the same tensor math the GPU was designed for is the workload. It is far less common — and often counterproductive — on the small, power-constrained computers that host most scanners, where the PCIe copy overhead and extra watts outweigh the gains and no discrete GPU is even present.
Relevance to SDR
GPU DSP shows up wherever bandwidth or model size is large: research SDR platforms, massive-MIMO and cellular test beds, wideband signal-intelligence receivers, and the training side of RF machine learning. It is a scaling tool, not a default — most decoding of a single voice or trunking channel needs only a few percent of one CPU core.
GopherTrunk does not use the GPU. GopherTrunk is a pure-Go decoder whose DSP — down-conversion, filtering, timing and carrier recovery, symbol slicing, framing — runs on the CPU, and it is designed to stay light enough to run comfortably on small single-board computers and other embedded SDR hosts that have no discrete GPU at all. Its performance strategy is efficient per-channel CPU code, not offloading, and it does not implement CUDA/OpenCL kernels or any GPU-based machine learning. For the wideband, many-channel or model-training regimes where GPUs genuinely help, that work belongs to specialized frameworks; GopherTrunk deliberately keeps its footprint CPU-only and portable.
Sources
-
General-purpose computing on graphics processing units — Wikipedia, on running non-graphics parallel workloads on GPUs. See also NVIDIA cuFFT for batched GPU FFTs, the workhorse primitive of GPU DSP. ↩