Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 11/16/2013 03:11 PM, Antti Palosaari wrote:
> On 15.11.2013 21:17, Antti Palosaari wrote:
>> On 15.11.2013 21:13, Devin Heitmueller wrote:
>>> On Fri, Nov 15, 2013 at 2:11 PM, Antti Palosaari <crope@iki.fi> wrote:
>>>> When I do it inside Kernel, in URB completion handler at the same
>>>> time when
>>>> copying data to videobuf2, using pre-calculated LUTs and using mmap
>>>> it eats
>>>> 0.5% CPU to transfer stream to app.
>>>>
>>>> When I do same but using libv4lconvert as that patch, it takes ~11% CPU.
>>>
>>> How are you measuring?  Interrupt handlers typically don't count
>>> toward the CPU performance counters.  It's possible that the cost is
>>> the same but you're just not seeing it in "top".
>>
>> Yes, using top and it is URB interrupt handler where I do conversion. So
>> any idea how to measure? I think I can still switch LUT to float and see
>> if it makes difference.
>
> I did some more tests. I added LUT to libv4lconvert and CPU usage of process dropped to ~3.5%. It is very simple app that just feeds data from device using mmap and conversion is done by libv4lconvert. Output is feed to standard out which I dumped to /dev/null on tests.
>
> So it is quite clear that runtime float conversion is CPU hungry when conversion rate goes that high (up to 30M conversions per sec).
>
> It is still not very much when compared to CPU needed for average signal processing after that, but it will increase directly CPU usage of that application. So is there idea to add threads for libv4lconvert in order to get conversion out from application context ?

I do not want to start using threads for libv4lconvert, if an app wants to do
the conversion in another thread, it can simply do all the v4l stuff in a
separate capture thread, like gstreamer does for example.

Regards,

Hans