mchehab
zbarcam uses a lot of CPU time
I am trying to use zbarcam in --nodisplay mode with a USB camera. The camera resolution is 1600x1200, zbarcam uses 100% CPU. Using --prescale=800x600 or -Sx-density=8 -Sy-density=8 the CPU usage goes down to around 70% which is still too much. The laptop is a Lenovo Edge E545, 4 core AMD A10-5750M APU, 2.5GHz. Is it planned to make zbar to use GPU acceleration for barcode decoding through Mesa?
The camera resolution is 1600x1200, zbarcam uses 100% CPU.
First of all, I don't know any Linux tool that measures CPU usage. What tools like top really does is to periodically check how many tasks are at the Linux scheduler. If it gets a 0, it means that the scheduler is idle, not doing anything. Then it divides the amount of frames with zero by the number of samples. If the CPU had something to do on all samples it took, it would show 100%.
This kind of measurement works reasonably well for some sorts of workloads that are random, but it doesn't produce a good result when you have any application receiving data on a synchronous way (like a camera, with receives 30 to 60 frames per second - usually causing hundreds of kernel wake ups per second to receive data from USB bus), plus processing it on userspace, on a separate task. The scheduler will almost all the times return you a big number for the CPU "usage".
If you really want to know how much time your CPU was spent doing something for ZBar, then you very likely need to use a tool like perf, which will measure the atual CPU time spent on each task, including the LInux Kernel handling.
Is it planned to make zbar to use GPU acceleration for barcode decoding through Mesa?
Even if we offload some processing to GPU, you would still be getting a high "CPU usage" time.
That's said, indeed using the GPU will free CPU to do other tasks.
Right now, nobody has proposed any patch to offload part of ZBar's handling to the GPU (either via Mesa, libva, vdpau or whatever). That sounds a nice feature, but one has to work at the patches.
Mauro, you are confusing load with runtime. Load reflects the number of processes which are waiting to be executed. The runtime, as available from /proc/[pid]/stat shows the amount of time (CPU cycles) spent running a specific process. Polling this value (e.g. every second) allows to calculate the relative amount (see man 5 proc).
"top" also shows CPU usage percentage, surprise surprise, in the "%CPU" column for processes. The value is calculated relative to one CPU. Multi-threaded processes can use more than 100%, e.g. "xz -T4" will use 4 threads and if the disk can keep up, it may use close to 400% CPU. This is a completely different metric from the load average values shown in the first header line.