Re: Which blocks do you like?

For the bug, wouldn’t be sufficient to substiture the above code

// Find the magnitude squared of the correlation
std::vector corr_mag(noutput_items);
volk_32fc_magnitude_squared_32f(&corr_mag[0], corr,
noutput_items);

with:

  std::vector<float> corr_mag(noutput_items+1);
  volk_32fc_magnitude_squared_32f(&corr_mag[0], corr, 

noutput_items);
corr_mag[noutput_items]=-1;
In theory the vector cannot contain negative value.

Actually I’m not usign sync_block,but only the generick gr::block…I try
to
explain how I am currently managing memory:
between each couple of attached block,where is a circular buffer(e.g. 32
position if we don’t have problems with latency),where each element is a
device memory page(e.g. with 4096 elements).
At the beginning,for each link the bottom block send his preference
about
memory(e.g. min/max size,history page,mandatory divisor for each
page[mandatory for FFT],other stuff)…the upon block will take decision
about memory,sending down its choices. (for multiple input blocks
attached
to same output things would be similar)
So it is possible that for a “synch_block” the number of input page is
different to n° output page.
Usually CUDA blocks send only one item each time to following block in
order to wake up.(data are passed throught device memory and others)

The final return and consume_each() are done according if all elements
in
CUDA buffer were consumed or not,and if there are new items in output

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs