Qt5.3 on AM335x: QML performance issues

As everything seemed to be OK with Qt4.8 we thought it might be a bug in Qt5.2/5.3 and reported one.

The guys were quite quick, took the sample code and tested it on their mobile (Jolla, clocked down to under 400MHz). See https://bugreports.qt-project.org/browse/QTBUG-38523

With the environment variable QSG_RENDER_TIMING=1 we were able to see the render-time for the QML scene of the example at the link of the former post. The row "Breakdown of render time" showed that the rendering of the scene takes always about 20ms (preprocess, updates, binding is always zero), which is VERY high compared to the guys testing it on the clocked down Jolla-mobile, where rendering takes about 2-3ms.

So, the question arised if our hardware (AM335x with SGX530) is too slow? As, on the other hand, it worked with Qt4.8, it should NOT be the hardware, but possibly the new graphics drivers??

So I will post this in the AM335x-hardware forum ...

We realised that changing the windowsystem from FLIPWSEGL to FRONTWSEGL changes a lot regarding the rendering time (which is "higher" when using FLIPWSEGL, as most time the renderer is in block/sync state; the effective render time is in both cases the same) AND the CPU-load.

That is OK: CPU load is higher with FRONTWSEGL, as much more frames per secodn (fps) are drawn ...

Anyway, the problem with abnormal high CPU-load during touch-events does persist. But it is highly likely that this a QT5.3.0-beta problem ...

Did you find a solution?  We have seen the same things From Qt5.2 to Qt5.4

Thanks,

Craig

Hi Craig

Sorry that I cannot really answer your question, as I do not really remember what we changed and if we changed anything.

I can tell you that with QT 5.3.0 (release version) it is actually working properly. During Drag&Drop (that means a lot of touch-events AND a lot of rendering) we see about 80% CPU load (FRONTWSEGL) or 50% CPU load (FLIPWSEGL - this is what we are using now). That is OK for us. CPU running at 720MHz, LCD 480x800x16bpp, RAM is DDR3.

Uh, just now I remember that I changed the touch-driver from working in polling-mode to IRQ-driven mode - but this might not make a big difference when sliding over the surface, as in this case both driver implementations generate a new-position-event at a rate of 90-100Hz.

Hi Matthias,

Thanks for your reply we are running at 720p on a 600MHz 8148.  We did find a solution that seems to work better for us.  We were also running in FLIPWSEGL mode as well and found performance better for use by making the following changes:

For powervr.ini we switch back to FRONTWSEGL.

For Qt we enabled QT_QPA_EGLFS_SWAPINTERVAL=1 and QSG_RENDER_LOOP=basic.  By default Qt uses a RENDER_LOOP of threaded and we would experience a bunch of blockToSync calls.  Once we switched to the basic LOOP and allowed Qt to do the swap instead of using the FLIPWSEGL we had a much better user experience.

We also notice a lower CPU using FLIPWSEGL, but that was not the issue as much as the blocking.  We are looking for a snappier performance so using a bit more CPU is was ok.

Just thought I would share with you waht we came up with, to help out our problem.

Thanks,

Craig

Hello,

Does anyone have instruction how to install Qt for ARM ?
If we need only support for QML is it suffecient to use Qt4.8 or must is be Qt5 or higher ?
If we need QML does it mean SGX and OpenGL ?
Thank you,
Ran