Ok, I have a branch 'volk_32bit_fixes' published at:
git://github.com/trondeau/gnuradio.git

This should fix the fft_filter issue and another issue in one of the volk
convert functions (that is not used in GNU Radio but was failing anyway).

I'm still seeing the 32fc_x2_dot_product_32fc failure. It looks like this
is in the SSE_32 proto-kernel. I'm seeing if we can get a quick fix for it.
This is the same problem Martin was seeing. If we can't get a fix for it,
I'm going to temporarily disable it until we get it fixed.

Tom

On Thu, Mar 8, 2012 at 8:24 PM, Tom Rondeau <t...@trondeau.com> wrote:

> On Thu, Mar 8, 2012 at 2:35 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
>
>> On 08/03/12 02:25 PM, Tom Rondeau wrote:
>> >
>> > That still might be indicative of the problem, though, that the flags
>> > are being read incorrectly by the proc system. Very strange, that.
>> >
>> > Marcus, if you would, change the volk kernel from the aligned (_a) to
>> > the unaligned one (_u) and see what that does. In the FFT, since it's
>> > an FFTW buffer, it _should_ be aligned, but this will let us know.
>> >
>> > Tom
>> >
>> Ok, changed from the "_a" to the "_u" variant in
>> gri_fft_filter_{ccc,fff}, and voila!   It now works!
>>
>> --
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
> Thanks to Marcus' help, I figured out the error here was due to a very
> silly assumption that I had made regarding our own array for the Fourier
> taps. Apparently, this is always handled "correctly" (for Volk's definition
> of correct) on 64-bit machines but not 32-bit ones.
>
> Attached is a patch that uses fftw_malloc to create an array to store the
> taps in. I created some helper functions in gri_fft to abstract the
> specific use of fftw in the filter code itself like we've done with the
> rest of fftw's invocation.
>
> Please try this out and let me know. I've only verified it on a 32-bit VM,
> so I just want to make sure there's nothing I'm missing (although it was
> failing previously as expected, so I think this works).
>
> There are still a couple of other 32-bit issues that I'm seeing in other
> blocks. I'll look into those next.
>
> Thanks,
> Tom
>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to