[Interest] hogging CPU on Arm board with Qt app and DRM/KMS sw rendering.. how to debug

[Andrea Venturi]

hello,

i've just recently subscribed to the ML because i have an issue with
Qt app in an embedded environment.

i'm just trying the analogclock sample on an embedded ARM board
(Allwinner A20 SOM  EVB for precisione sake) and i find it's hogging
the CPU.
the SW stack is based on buildroot 2017.08 environment that provides a
lib qt5.9.1 / sw rasterizer on the basic DRM/KMS driver running on
mainline 4.15rcx kernel

i run callgrind for profiling , but i can't figure out from the
resulting data what's going on.. i.e. kcachegrind provides beautiful
graphs and maps.. but i suppose it takes some time to understand how
the CPU time is spent
i'm wondering if the issue is related to the underlying DRM/KMS is
still missing some hooks/features for the Qt stack be happy..
i set the env var "GALLIUM_HUD="cpu,fps" but the fps stays 0 (and CPU
is stuck on 50%, i suppose because it means one core of the two is
100% hogged)
see this shot: https://drive.google.com/open?id=1vitoJrWyYO_WE5-60XlRHahmVrzGnv2m
eventually the callgrind profiling data are here:
https://drive.google.com/file/d/1VMkD8sNwZBsH5dRo8EJzz6Vi3_E5M0XT
to make issue more puzzling, if i define
"QT_QPA_PLATFORM='linuxfb:fb=/dev/fb0'", as the kernel has also "fbdev
emulation", the clock is running fine with 0% of CPU usage.. i suppose
because it takes another code path..
any suggestion where to move forward for debugging?

andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180122/ecd3e883/attachment.html>