discuss-gnuradio
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]