[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Segmentation fault for aligned volk kernel with c
Re: [Discuss-gnuradio] Segmentation fault for aligned volk kernel with custom arrays
Tue, 13 Nov 2012 22:25:23 -0500
On Mon, Nov 12, 2012 at 4:55 AM, "Martin Lülf" <address@hidden> wrote:
>> On Fri, Nov 9, 2012 at 11:47 AM, "Martin Lülf" <address@hidden> wrote:
>>> Hi list,
>>> I am trying to speed up my own gnuradio block using volk. Besides using
>>> volk on gnuradios input and output buffers I also want do use it with my
>>> own arrays. I found this Thread in the mailing list archive
>>> which shows how to allocate aligned memory and I also tried using
>>> posix_memalign directly as well (see the code below). Both end in the
>>> result: If I run my block with the aligned volk_32fc_x2_multiply_32fc_a
>>> kernel my application crashes with a Segmentation fault. I checked with
>>> debugger and it is the volk call at which the segfault happens. I get no
>>> segfaults for the unaligned version volk_32fc_x2_multiply_32fc_u. My
>>> flowgraph is created with grc and just contains of
>>> Running volk_profile, sse3 is selected for both kernels (and the aligned
>>> version does not segfault here), so there has to be an issue with my
>>> I am working on an Intel Xeon X5690 CPU with an 3.2.0-32-generic
>>> #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64
>>> and gnuradio-3.6.0
>>> I know that there is a newer version of gnuradio available but before
>>> turning my whole system upside-down I'd like to know if there is
>>> wrong with the minimal code example below.
>>> Any help is appreciated.
>> The problem is in your constructor. You have not told the block to
>> work with your alignment. In blocks that use VOLK, we have this in the
>> const int alignment_multiple =
>> volk_get_alignment() / sizeof(gr_complex);
>> set_alignment(std::max(1, alignment_multiple));
>> We divide the alignment by sizeof(output type) specifically. We should
>> be able to hide this in the future, but there's some uncertainty as to
>> whether the output type is always the right answer if there are
>> multiple types defined, so we do the right thing for each block.
>> Also, a general note on using fftwf_malloc that I found out the hard
>> way. If you have an AVX processor and want to use AVX kernels, FFTW
>> needs to be build using --enable-avx. I've had to build FFTW by hand
>> on my AVX processors where I want to use VOLK.
> Hi Tom,
> thank you very much for your help. Adding the few lines to my constructor
> solved the segfault problem. Now I am trying to understand what I did :)
> I assumed with calling set_alignment I tell the scheduler on which bounds
> he should try to align, which will result in more aligned arrays being
> passed to work. However even without telling the scheduler which alignment
> I would like to have is_unaligned() should never return false, when the my
> input or output arrays are unaligned and thus in the worst case the
> unaligned kernel is called, although the arrays are indeed aligned, but
> not the other way around. What am I missing here?
set_alignment sets up the alignment boundaries, but it also
initializes the variables for when the item streams are aligned;
without the initialization, the scheduler has no idea how to keep
track of anything.
You can use the volk_is_aligned, which will actually test the
pointer's alignment and tell you if it's aligned or not.