[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] volk kernels and num_bytes vs num_points
From: |
Josh Blum |
Subject: |
Re: [Discuss-gnuradio] volk kernels and num_bytes vs num_points |
Date: |
Mon, 02 Jul 2012 19:19:39 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
>> 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
>
> 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.
>
FYI. Enabling this unit test:
> diff --git a/volk/lib/testqa.cc b/volk/lib/testqa.cc
> index d1eb1ca..507c787 100644
> --- a/volk/lib/testqa.cc
> +++ b/volk/lib/testqa.cc
> @@ -54,7 +54,7 @@ VOLK_RUN_TESTS(volk_32fc_x2_square_dist_32f_a, 1e-4, 0,
> 20460, 1);
> VOLK_RUN_TESTS(volk_32fc_x2_s32f_square_dist_scalar_mult_32f_a, 1e-4, 10,
> 20460, 1);
> VOLK_RUN_TESTS(volk_32f_x2_divide_32f_a, 1e-4, 0, 20460, 1);
> VOLK_RUN_TESTS(volk_32f_x2_dot_prod_32f_a, 1e-4, 0, 204600, 1);
> -//VOLK_RUN_TESTS(volk_32f_x2_dot_prod_32f_u, 1e-4, 0, 204600, 1);
> +VOLK_RUN_TESTS(volk_32f_x2_dot_prod_32f_u, 1e-4, 0, 204600, 1);
> 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