Hi,
(cross-posted to gta04-owner since we have a first result)
> Am 17.04.2018 um 10:45 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>
> Hi,
> I now have extracted the QtMoko accelerometer handler code [1]
> into a simple command line utility.
>
> <accel-test.c>
>
> This basically works, except for the following observations:
>
> 1. sometimes one axis is reported as "0" in between.
>
> This comes because there may be SYN_REPORT (EV_SYN) on
> the first read after opening the device before all
> 3 axis are reported. This may be a race between opening
> the event device and the driver providing the first events.
>
> This is harmless, because QtMoko or QtMaze opens the
> device only once and future events are collected while
> the accel-test program opens and closes the device for
> each call.
>
> 2. accel-test does not have a background thread to
> collect events.
>
> In QtMoko there is a background thread that tries
> every 12.5 ms to collect events. This seems to differ
> from GTA02 which has 2 ms.
>
> So the GTA02 may sample more often, but that should
> not have an influence on the game speed. Because
> it runs in a background thread *and* the game defines
> the frame rate which likely defines the visual physics.
>
> 3. it seems as if there is an active polling loop
> until data becomes available. This is
>
> 325 /* Call accelerometer_moo() until we have an
> 326 acceleration measurement. */
> 327 while (!accelerometer_moo(accel))
> 328 ;
> 329
>
> This makes the background thread poll until a SYN_REPORT
> has been received where we can assume that all axis
> information is available.
>
> For me this looks as if this is done at 100% CPU load
> because the select() call has a zero timeout.
>
> This could of course slow down the main application,
> i.e. drawing of the graphics.
>
> I am not sure, but I think this should either become
> a blocking select() call.
>
> Or there should not be an inner while loop in the thread
> handler.
>
> The Neo GTA02 code also does a non-blocking select() but
> then always makes the thread sleep for 2 ms.
>
> So maybe accel_work() should look like:
>
> 323 while ( !(my_thread_data->finished) ) {
> 324
> 325 /* Call accelerometer_moo() until we have an
> 326 acceleration measurement. */
> 327 if (accelerometer_moo(accel))
> 328 {
> 329
> 330 /* If the library user specified a callback, call
> 331 it. */
> 332 if (my_thread_data->callback)
> 333 (*my_thread_data->callback)(my_thread_data->closure,
> 334 acx, acy, acz);
> 335 }
> 336 /* Sleep before taking another measurement. */
> 337 usleep(my_thread_data->interval_us);
> 338 }
>
> Please comment while I'll test...
Ok, I have tested that piece of code.
- it works :)
- but I can't notice a difference in QtMaze graphics :(
Anyways, it is a big improvement!
With old version we had >80% CPU load by QtMaze sitting on the table:
top - 00:04:05 up 4 min, 2 users, load average: 1.08, 0.93, 0.42
Tasks: 79 total, 1 running, 53 sleeping, 0 stopped, 0 zombie
%Cpu(s): 14.7 us, 72.1 sy, 0.0 ni, 13.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 500096 total, 246072 used, 254024 free, 11908 buffers
KiB Swap: 0 total, 0 used, 0 free, 147280 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3386 root 20 0 45220 24m 16m S 83.8 4.9 0:09.61 qtmaze
17 root 20 0 0 0 0 I 1.0 0.0 0:01.11 kworker/0:1
472 root -51 0 0 0 0 S 0.7 0.0 0:00.40 irq/72-48070000
3384 root 20 0 2712 1776 1336 R 0.7 0.4 0:00.28 top
With new code we have just 3%:
top - 00:09:07 up 9 min, 2 users, load average: 1.60, 1.55, 0.84
Tasks: 77 total, 1 running, 53 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.7 us, 1.7 sy, 0.0 ni, 96.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 500096 total, 273088 used, 227008 free, 12724 buffers
KiB Swap: 0 total, 0 used, 0 free, 172472 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3497 root 20 0 45220 24m 16m S 3.6 4.9 0:01.57 qtmaze
3495 root 20 0 2712 1852 1412 R 1.3 0.4 0:00.55 top
951 root 20 0 0 0 0 I 1.0 0.0 0:00.27 kworker/0:2
476 root -51 0 0 0 0 S 0.3 0.0 0:00.53 irq/73-48072000
3472 root 20 0 116m 52m 27m S 0.3 10.8 0:03.66 qpe
1 root 20 0 1696 1016 912 S 0.0 0.2 0:04.13 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
So QtMaze was quite a heavy Energy consumer because of this unnecessary
busy loop... And now the omap3 is clocked down to 300 MHz most of the time.
For the "stuttering" problem of QtMaze I suspect that the graphics backend
of Qt waits for vertical retrace to guard the frame rate. This ioctl might
different from new kernels with kernel 3.7... AFAIR the whole omap3 display
system has been replaced since that times.
Maybe, next I should try if I can boot our latest QtMoko2 with a 3.7 kernel :)
Just for comparison.
BR,
Nikolaus
> BR,
> Nikolaus
>
> [1]:
> http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=src/libraries/accelerometer/accelerometers.cpp;h=4bd95bccf91d301512800b9fafdd7e4a610b1a70;hb=618ac5b867ba807e749213fde74fe9b0afe935c4
>
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> letux-ker...@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
_______________________________________________
Gta04-owner mailing list
Gta04-owner@goldelico.com
http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
