Hi,
for my thesis I’m making “porting” of gnuradio blocks over CUDA…
For the moment,I’ve bring basick blocks,FIR filter,FFT,an FM
receiver(not
so good due to latency) and I’m working with ofdm…I still need to
implement IIR filter
Which other blocks do you think that could be nice(useful,get
performance,…) to bring over CUDA?
The tone reservation PAPR reduction block used with the DVB-T2
transmitter in gr-dtv may be interesting for you. It uses a ton of
floating point calculations.
Even though it uses Volk kernels extensively, it’s performance is still
lacking. Right now, it’s capable of light PAPR reduction, but for
heavier reduction, it’s takes too much CPU and the transmitter flow goes
non real-time.
The target performance would be a clipping value of 2.57 over 50
iterations, which is what is used in the Ofcom mode 2 profile. Current
performance is a clipping value around 2.9 over 20 iterations (on my
workstation).
classically, correlation is an expensive thing, so probably an
implementation of some correlation synchronizer would be interesting!
(also, the raw correlation, but depending on your FIR implementation you
might already have that)
Though this might be nontrivial to come up with an architecture for
that, as it doesn’t really fit the typical CUDA fixed size buffer in -
fixed size buffer out approach.
Message: 4
Date: Mon, 18 May 2015 09:52:26 +0200
From: Marcus M?ller [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] Which blocks do you like?
[snip]
have the last item greater than the previous…
corr_mag[i+1]). Thanks for spotting that!If you don't mind, I'd like to ask you to fix that line (while(i<noutput_items)->while(i<noutput_items-1)`)and submit a pull
request on github [2] (if possible, base it off the “maint” branch).
Hi Marcus and Marco,
The corr_est block fixes this bug, and a few others, that the original
correlate_and_sync block has. The corr_est block should perform
reliably, whereas the correlate_and_sync block does not, due to bugs.
They are different blocks because the corr_est block has different input
arguments, to handle more general cases.
If you wish to spend time optimizing the performance of a block, I’d
recommend you optimize the corr_est block, not the correlate_and_sync
block. Optimally doing something unreliably is still doing something
unreliably.
have the last item greater than the previous…
corr_mag[i+1])`. Thanks for spotting that!If you don’t mind, I’d like to
arguments, to handle more general cases.
If you wish to spend time optimizing the performance of a block, I’d
recommend you optimize the corr_est block, not the correlate_and_sync
block. Optimally doing something unreliably is still doing something
unreliably.
Regards,
Andy
Plus this block will be removed in 3.8, so it doesn’t have a long life
left.
Tom
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.