[Interest] Qt5 performance on imx6 with full hd

[Jacob Kroon]

Hi Gunnar,

On Tue, May 27, 2014 at 10:36 AM, Gunnar Sletta <gunnar.sletta at jolla.com>
wrote:

>
> On 27 May 2014, at 10:28, Jacob Kroon <jacob.kroon at gmail.com> wrote:
>
> > Hi Gunnar,
> >
> > On Fri, May 23, 2014 at 11:39 AM, Gunnar Sletta <gunnar.sletta at jolla.com>
> wrote:
> >
> > On 23 May 2014, at 10:32, Jacob Kroon <jacob.kroon at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I'm experimenting with a Qt application running on the Wandboards,
> > > at full hd resolution, 1920x1080x32. I have a static background image,
> and some small animated Qml-elements on the screen. I'm not entirely
> satisfied with the resulting performance, and I think it is because of the
> background image being constantly fully redrawn in each frame.
> >
> > If it cannot render a single image at that resolution, then it is not a
> suitable hardware for that resolution :)
> >
> > If this is the case your options are to reduce the bit depth, reduce the
> resolution or reduce the framerate (such as going for 30FPS instead of
> 60FPS)
> >
> > Is the image alpha blended? If it is a JPEG it should be opaque, but if
> it is a PNG it will most likely have an alpha channel (even thought it
> really doesn't. I know, stupid, but that how it is). For some GPUs blending
> can add a bit of overhead, and doing it fullscreen can be what tips the
> balance.
> >
> >
> > For the background image, what I did was that I used a tiled noise
> image, and did a radial blend on it. The resulting image was cached though.
> But yes, the resulting image showed up as "alpha" in the renderer debug
> output, I've switched to having a static prepared png image, and now the
> background image shows up as "opaque".
> >
> > > I've experimented with
> > >
> > > * setClearBeforeRendering(false), since the background will be drawn
> anyway, there is no point in clearing before rendering. This seemed to have
> little impact on performance though.
> >
> > The effect of turning off clearing is highly hardware dependent. Some
> drivers/GPUs will benefit from not clearing as the clear is just yet
> another pass over all pixels. Others will use the clear as an indication of
> "new frame" and will have to do all manner of nasty stuff, like storing the
> depth buffer into system memory because you didn't clear it before the
> frame began.
> >
> > See the performance guidelines of your GPU for the actual recommendation
> for your chip.
> >
> >
> > It seems that setting "QSG_ANTIALIASING_METHOD=msaa" gives a huge
> improvement on the cpu usage.
>
> That is a bit interesting... What are you drawing on top of this image?
> msaa based antialiasing generally adds a bit to the cost on the GPU, but it
> makes the work a lot simpler for the renderer when you have Rectangle and
> Image elements with antialiasing: true in QML.
>
> Is there a lot of overdrawing?
>
>
Yes, I think is exactly what I saw, when I enabled msaa the number of
vertexes sent to the gpu dropped, and lowered the cpu usage.
Indeed I am doing some overdrawing, that I probably can work around
somehow. I'm still pretty knew to qml.


> > Also, playing with QSG_RENDERER_BATCH_VERTEX_THRESHOLD and
> QSG_RENDERER_BATCH_NODE_THRESHOLD,
> > allows me to lower the cpu usage even further. Still, the background
> image is taking a considerable time it seems. With bg image I get ~27 fps,
> > without it I get ~85 fps (with vsync turned off)
>
> How is the performance if you use an image which is a lot smaller? Since
> the big image causes such a big impact, maybe texture loading is a
> bottleneck. If this is the problem, then using a ShaderEffect to create the
> tiled-noise background might be an option as that would then not suffer
> from massive texture fetching.
>
>
A smaller image that I scale up seems to improve performance as well.
However, I'm not sure if generating the tiled-noise using a shader would
improve things on the Wandboard, I did try the qt5-launch-demo, normal and
simple version, and the one without the tiled-noise bg ran a lot smoother.

Thanks
/Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140605/40c9338f/attachment.html>