Re: [Discuss-gnuradio] Which blocks do you like?

[Marcus Müller]

Hi Marco,

I've looked about correlate_and_sync method(are you speaking about it,isn't it?)

Pretty much, yeah :)

here the problem is not only data outgoing from the block,but relative tags.also because for the moment I'm not supporting tags on the flow above CUDA.If u have good idea about how manage them,feel free to speak.

I don't know exactly what your blocks look like, but assuming you take a gr::sync_block and let it handle the whole CUDA thing, GNU Radio would automatically make this work.
If you instead have a block that "sends" data to the CUDA GPU (a sink from GNU Radio's perspective), and another one that "receives" data from CUDA (a source from the perspective of GNU Radio), you could simply get_tags_in_range on the sink block, take these tags, and send them as message to your source block (before you start the CUDA processing). You would then write a message handler in your source block which just takes these tags and does add_item_tag to each of them.
If you want to add tags by detecting things in CUDA, that'll be a bit more complicated, and sounds like your CUDA threads would need to coordinate with a lot of barriers to write the index of a tag you want to add into a specific memory position... I don't know how effective that would be compared to doing the same on a GHz CPU.

std::vector<float> corr_mag(noutput_items);
int i = d_sps;
while(i < noutput_items) {
        if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) {
          while(corr_mag[i] < corr_mag[i+1])
            i++; 

is not possible that the variable i will go outside the array corr_mag?I know that is necessary a strange pattern in order to have the last item greater than the previous..

I agree, relying on the signal to limit execution of this loop feels a bit "dangerous", but I also agree that as long as your "known symbol" has a sane shape, this won't be a problem. The problem is that this is indeed a bit of a CPU-hungry bit of code, so every additional condition might slow things down; I think it should be possible to come up with a nearly-as-effective implementation that is more secure, but I can't think of one right now. Any hints? [1]
At any rate, the outer `while` shouldn't run till `noutput_items`, but till `noutput_items - 1`, because of the inner `while(corr_mag[i] < 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).

Best regards,
Marcus

[1] Hard to properly optimize; intuitively, it's not clear whether a highly optimized "precompute the  complete corr_mag[0:end-d_sps]-corr_mag[d_sps:end] and sign(corr_mag[:end-1]-corr_mag[1:end])" would be faster than selectively only computing the relevant parts (like this branching-intense algorithm does) on a CPU. Pretty sure that on CUDA, you'd just precompute the whole arrays.
[2] https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#How-can-I-use-github-to-submit-patchesfeatureschanges

On 05/17/2015 10:58 PM, marco Ribero wrote:

@Ron Economos: Thanks for your reply.I've looked about the code.I think that maybe I'll implement it in the future,but not now: is too specific to a single application

@Marcus Müller:I've looked about correlate_and_sync method(are you speaking about it,isn't it?)Ye it can take good advantage from CUDA..

Ye,I've a FIR implementatio and I'm looking also for an FFT(with device code,so unlucky without cuFFT library).
here the problem is not only data outgoing from the block,but relative tags.also because for the moment I'm not supporting tags on the flow above CUDA.If u have good idea about how manage them,feel free to speak.

While I was reading the code,a question arise about this code( method work in cc implementation):

while(i < noutput_items) {

        if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) {

          while(corr_mag[i] < corr_mag[i+1])

            i++; 

is not possible that the variable i will go outside the array corr_mag?I know that is necessary a strange pattern in order to have the last item greater than the previous..

Greetings,

marco ribero

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio