seems a normal pair of
float multiplication.
Is it a bug or a feature?
Thanks,
Marco Ribero
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Sorry, it was my fault. I've only looked generic implementation, without
pay attention that is the operator * is also defined for complex.
Have a good day
Il giorno sab 26 set 2015 alle ore 23:35 Marcus Müller <
marcus.muel...@ettus.com> ha scritto:
> Hi Marco,
>
> volk_32fc_x2_multiply_32fc is
Hi all,
I'm playing with CUDA and GNURadio. For the moment I've used separatly nvcc
in order to compile device code: I've tried different tutorials which
explain how to use CUDA with CMake, but I was not able to obtain a good
result.
Can someone explain me how to modify Cmake's file of a basic GNU
Hi all,
I'd like to establish a bidirectional communication between two attached
blocks, without asking the user to write code like msg_connect(). One way
could be: the upstream block generate an id like
ID=typeBlock+pseudorandomNumber
and send it to the next block using a tag.
After what the upst
Thank you very much. Your solution is much cleaner.
Have a good day,
Marco
Il giorno lun 20 apr 2015 alle ore 09:29 Marcus Müller <
marcus.muel...@ettus.com> ha scritto:
> Hi marco,
>
> what you describe as ID already exist: every block has a function alias(),
> giving it a string "name", which
ock, you can for example first
> construct your cuda block, and then give your "downstream" block the
> pointer to that in its constructor.
>
> To the user, this will look like one block, though there are two (or more)
> inside.
>
> Greetings,
> Marcus
>
>
>
I try to give more details.
In order to create blocks using the standard way(cmake/make/install) with
Cuda,I've modified the CMakeList in /lib as shown before. My block is
created using gr_modtool and the language is c++.
The fact is that "make test" works well,while in GnuRadio interface give me
t
Il giorno lun 20 apr 2015 alle ore 16:30 Tom Rondeau ha
scritto:
>
>>
> We've never been hot on the idea of using VOLK for GPU stuff. VOLK kernels
> tend to do one thing at a time and don't worry about data movement (too
> much) because the SIMD registers are right there. Going to GPUs takes a lo
27; object has no attribute 'mod_ff'
Reattached kernel driver
Thanks for your effort,
marco
Il giorno mar 21 apr 2015 alle ore 16:37 Tom Rondeau ha
scritto:
> On Mon, Apr 20, 2015 at 1:42 PM, marco Ribero
> wrote:
>
>> I try to give more details.
>> In order to create b
Hi all,
I have another question. How can I connect the input and output port of
different blocks,from inside a C++ block? In the documentation I've only
seen the msg_connect() for python
Thanks,
marco
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gn
>> I prefer to change your topology to refuse the need you've mentioned.
>> Otherwise describe your problem with more details.
>>
>>
>> Best,
>> Mostafa
>>
>>
>>
>> On Thu, Apr 30, 2015 at 3:43 PM, marco Ribero
>> wrote:
>>
Looking better about implementation of blocks like fft,fir,etc a question
rise in my brain.
Why in blocks with selectable input/output data type there are C++ multiple
file, each one with the specialization of a single data type(file finishing
with _cc,_ff,etc), instead of use template(and eventual
Ok I've understood. Thank you for your answer.
Have a good day,
Marco
Il giorno gio 30 apr 2015 16:47 Tom Rondeau ha scritto:
> On Thu, Apr 30, 2015 at 9:30 AM, marco Ribero
> wrote:
>
>> Looking better about implementation of blocks like fft,fir,etc a question
>> r
Marcus, thank you very much for your deep answer.
Your proposal about the usage of
your_block::detail()->input(0)->buffer()->link seem very interesting, so I
shoulld evaluate if use this mechanism or only some memory allocation
created with malloc.
I'd prefer to simplify the life of user as much a
Looking inside gnuradio,I've found blocks like divide_XX where relative
files have an extension .t (like divide_XX_impl.cc.t )..in this way,is
possible to manage different types for the same block.
How is posssible to create blocks like them? is necessary to use particular
parameters in gr_modtools
Tahnk you very much for your reply.
I've tried different time with templates,but I was not able to obtain a
result(cmake and make finish errors,but I suppose that swig crash,because
python scripts are not able to access to any block written in C,also blocks
without template)..
At the end I've solv
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
perf
_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
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 corr_mag(noutput_items+1);
volk_32
Thank you for your replies!! I really appreciate them.
If you want to give a look about my porting,here is possible to see
something:
https://github.com/m-ri/gr-CUDA
Greetings,
marco
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lis
Hi,
I've a question about thread management..I like the fact that scheduler can
launch blocks in different threads, but I'd like to execute some blocks
inside the same thread(CUDA require to perform all operations from a single
thread)..for the moment I'm using GR_SCHEDULED=STS,but it blocks at all
t both approaches(parallel and cascade)
require only the previous output,I think what the implementaion would be
not difficult: thanks to the expansion of recurrence expression, is
"sufficient" something like a parallel sum prefix.
Thanks,
Marco Ribero
_
Il giorno dom 24 mag 2015 alle ore 19:52 Tom Rondeau ha
scritto:
> Don't use the STS scheduler. It is, after all, the Single-Threaded
> Scheduler. And setting the thread affinity under that condition is a nop.
> That will only work with the default TPB scheduler.
>
> Tom
>
> I need that different
Il giorno mer 27 mag 2015 alle ore 16:29 Marcus Müller <
marcus.muel...@ettus.com> ha scritto:
> Yes. The Thread-per-Block-scheduler gets its name from the fact that
> every block gets its own thread.
> You should really use it -- using STS will probably kill the performance
> you can gain by acce
Hi,
now I need to install also the UHD module of gnuradio(before I've used only
RTL). Is possible to install this module without reinstall the entire
gnuradio?
I've tried the easiest apprach, mkdir/cmake/make.. in gnuradio/gr-uhd, but
it doesn't work.
Thanks,
marco
> Radio, so it's simply a good idea to update GNU Radio, rebuild it in whole
> (if you've got more than 4GB of RAM and more than one CPU core, try "make
> -j ") and re-install it. You'll also have to re-compile
> every OOT module (eg. gr-osmosdr).
>
> Best
26 matches
Mail list logo
