[prev in list] [next in list] [prev in thread] [next in thread]
List: gnuradio-discuss
Subject: Re: [Discuss-gnuradio] Problem with volk and fftw memory alignment
From: Tom Rondeau <tom () trondeau ! com>
Date: 2015-05-30 22:34:32
Message-ID: CA+SzT6iYW_ZW+G8nUg9CaEEtk128d+R8yp7wk=tgnV90oegMyQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, May 29, 2015 at 4:33 PM, <djch-gnuradio@hutchhome.co.uk> wrote:
> I've been trying out the (bleeding edge) corr_est() code and the
> test_corr_est.grc sometimes segvs. Not repeatable, won't crash under gdb
> :-) From a core file, it's crashing loading the first element of aVector in
> volk_32fc_x2_multiply_32fc_a_avx
> instruction is vmovaps (%eax),%ymm1 where eax is 0x8b8b590.
>
> My CPU supports the 256bit AVX instructions, and I believe such data needs
> to be 256bit=32 byte aligned. EAX here isn't. Looking at the backtrace,
> it's crashing in fft_filter_ccc::filter, where the d_fwdfft is generated
> from fft::fft_complex
>
> In turn this creates d_inbuf by calling fftwf_malloc. I believe this only
> guarantees 16 byte alignment. (I'm on fftw3.3.4, on a 32 bit Linux 3.18.1,
> CPU Intel i5-3470)
>
> As we move to use volk and the fast SIMD, should the code in fft.cc (and
> perhaps other places) move to using a volk memory allocator to get the
> right alignment, rather than fftwf_malloc?
>
> I'm on gentoo, so I could fix the source to fftwf_malloc to return 32 byte
> aligned, but that's not a general solution.
>
> I'm not sure how I should report this issue, please pass on my report if
> there's a better place to discuss such things
> --
> G8SQH
> <djch-gnuradio@hutchhome.co.uk>
>
Yes, this is absolutely a problem with using the fftw_malloc functions.
Unless told, FFTW doesn't build AVX support, which means that it can return
vectors that are not AVX-aligned, and the code is calling the _a kernel and
so requires it to be appropriately aligned.
Can you change and fftw_malloc'd arrays used in volk calls to volk_malloc
and a) make sure that works and b) submit a patch with where you're running
into this? I thought we had fixed these already (also, what version are you
running?).
Tom
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 29, 2015 \
at 4:33 PM, <span dir="ltr"><<a href="mailto:djch-gnuradio@hutchhome.co.uk" \
target="_blank">djch-gnuradio@hutchhome.co.uk</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">I've been trying out the (bleeding edge) corr_est() code \
and the test_corr_est.grc sometimes segvs. Not repeatable, won't crash under gdb \
:-) From a core file, it's crashing loading the first element of aVector in \
volk_32fc_x2_multiply_32fc_a_avx<br> instruction is vmovaps (%eax),%ymm1 where \
eax is 0x8b8b590.<br> <br>
My CPU supports the 256bit AVX instructions, and I believe such data needs to be \
256bit=32 byte aligned. EAX here isn't. Looking at the backtrace, it's \
crashing in fft_filter_ccc::filter, where the d_fwdfft is generated from \
fft::fft_complex<br> <br>
In turn this creates d_inbuf by calling fftwf_malloc. I believe this only guarantees \
16 byte alignment. (I'm on fftw3.3.4, on a 32 bit Linux 3.18.1, CPU Intel \
i5-3470)<br> <br>
As we move to use volk and the fast SIMD, should the code in fft.cc (and perhaps \
other places) move to using a volk memory allocator to get the right alignment, \
rather than fftwf_malloc?<br> <br>
I'm on gentoo, so I could fix the source to fftwf_malloc to return 32 byte \
aligned, but that's not a general solution.<br> <br>
I'm not sure how I should report this issue, please pass on my report if \
there's a better place to discuss such things<br> <span class="HOEnZb"><font \
color="#888888">--<br> G8SQH<br>
<<a href="mailto:djch-gnuradio@hutchhome.co.uk">djch-gnuradio@hutchhome.co.uk</a>><br></font></span></blockquote><div><br></div><div>Yes, \
this is absolutely a problem with using the fftw_malloc functions. Unless told, FFTW \
doesn't build AVX support, which means that it can return vectors that are not \
AVX-aligned, and the code is calling the _a kernel and so requires it to be \
appropriately aligned.</div><div><br></div><div>Can you change and fftw_malloc'd \
arrays used in volk calls to volk_malloc and a) make sure that works and b) submit a \
patch with where you're running into this? I thought we had fixed these already \
(also, what version are you running?).</div><div><br></div><div>Tom</div><div> \
</div></div></div></div>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic