# Volk kernels and num\_bytes vs num\_points **URL:** \ **Category:** GNU Radio\ **Created:** [July 3, 2012, 12:35am UTC](https://www.ruby-forum.com/t/volk-kernels-and-num-bytes-vs-num-points/221158 "2012-07-03T00:35:48Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [July 3, 2012, 12:35am UTC](https://www.ruby-forum.com/t/volk-kernels-and-num-bytes-vs-num-points/221158/1 "2012-07-03T00:35:48Z")
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](http://gnuradio.org/cgit/jblum.git/commit/?h=volk_next_use_num_points) -josh ---
**Author:** ![Josh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8797f3/32.png) [@Josh\_B](https://www.ruby-forum.com/u/Josh_B)\ **Post date:** [July 3, 2012, 3:40am UTC](https://www.ruby-forum.com/t/volk-kernels-and-num-bytes-vs-num-points/221158/2 "2012-07-03T03:40:03Z")
On Mon, Jul 2, 2012 at 6:34 PM, Josh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![Josh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8797f3/32.png) [@Josh\_B](https://www.ruby-forum.com/u/Josh_B)\ **Post date:** [July 3, 2012, 4:20am UTC](https://www.ruby-forum.com/t/volk-kernels-and-num-bytes-vs-num-points/221158/3 "2012-07-03T04:20:21Z")
> > 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