Volk kernels and num_bytes vs num_points

GNU Radio
1

Hey VOLK enthusiasts,

It looks like in just a few kernels we use num_bytes as the length
parameter rather than num_points. I think this may have been a source of
confusion and perhaps a few test failures.

See, we pass random number of points into these kernels for test. But,
when random numbers of points were interpreted as bytes, you get caught
slicing points/items down the middle… I found this out the hard way
when doing some alignment work.

I have pushed a branch that fixes 12 kernels that do this. I hope we can
merge this into the “next” branch. Since, I suppose its an API change.
Or we call it a fix and merge it into maint/master. Anyways…

It looks like the only code affected is in gr-filter. I suggest Tom take
a second look at the usage of volk_32fc_x2_dot_prod_32fc. Whether or not
we take the changeset, it might be good to verify that the following
code isnt being bitten by this usage:

./gr-filter/lib/fir_filter.cc: volk_32fc_x2_dot_prod_32fc_a(d_output, ar,
./gr-filter/lib/fir_filter_with_buffer.cc:
volk_32fc_x2_dot_prod_32fc_a(d_output, ar,
./gr-filter/lib/fir_filter_with_buffer.cc:
volk_32fc_x2_dot_prod_32fc_a(d_output, ar,

And here is the commit for reference:
http://gnuradio.org/cgit/jblum.git/commit/?h=volk_next_use_num_points

-josh

2

On Mon, Jul 2, 2012 at 6:34 PM, Josh B. [email protected] wrote:

Hey VOLK enthusiasts,

It looks like in just a few kernels we use num_bytes as the length
parameter rather than num_points. I think this may have been a source of
confusion and perhaps a few test failures.

Yes, this has been bugging me, too. Thanks for tackling it.

a second look at the usage of volk_32fc_x2_dot_prod_32fc. Whether or not

-josh

It’d be great to get this in, but yes, it does constitute and “API
change” so it might have to wait. We’re steadily pushing on with 3.7,
though, so putting it in next shouldn’t keep it from being used for
too long. On the other hand, as you say, it’s used in gr-filter. We’re
trying to remove an bugs there, and perhaps the reason for some bugs
is due to this. If we only apply this to next, we’ll have to ask
anyone having problems to try it out there and see.

So that’s my thought right now for taking this patch based on our
policy of what goes in master. I’ll think some on this to see if it’s
critical/necessary and if we should make an exception.

Thanks,
Tom

3

And here is the commit for reference:
anyone having problems to try it out there and see.

FYI. Enabling this unit test:

VOLK_RUN_TESTS(volk_32f_x2_dot_prod_16i_a, 1e-4, 0, 204600, 1);
//VOLK_RUN_TESTS(volk_32f_s32f_32f_fm_detect_32f_a, 1e-4, 2046, 10000);
VOLK_RUN_TESTS(volk_32f_index_max_16u_a, 3, 0, 20460, 1);

RUN_VOLK_TESTS: volk_32f_x2_dot_prod_32f_u
generic completed in 0s
sse completed in 0s
sse3 completed in 0s
offset 0 in1: 26.845 in2: 8.02013
volk_32f_x2_dot_prod_32f_u: fail on arch sse
Best arch: generic
/home/jblum/src/gnuradio/volk/lib/testqa.cc(57): error in
“volk_32f_x2_dot_prod_32f_u_test”: check
run_volk_tests(volk_32f_x2_dot_prod_32f_u_get_func_desc(), (void
(*)())volk_32f_x2_dot_prod_32f_u_manual,
std::string(“volk_32f_x2_dot_prod_32f_u”), 1e-4, 0, 204600, 1, 0, “NULL”) == 0
failed [true != 0]

Not sure why it fails. The u_sse code looks just like the u_sse3
implementation. I guess you arent using the _u kernel so its not
breaking anything in the gr-filter.

-josh