Discussion:
Qt5 performance on imx6 with full hd
(too old to reply)
Jacob Kroon
2014-05-23 08:32:42 UTC
Permalink
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. 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.

* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no background
image, but instead write the background image manually into /dev/fb0. In
this way, the IPU will blend the result onto the display. This seemed to be
even worse than letting the GPU render the background.

Can the scenegraph be smart enough in such a way that it will only "clear"
dirty rectangles with a user supplied background image ? Or are there any
other tricks I am not aware of ?

Regards Jacob
Gunnar Sletta
2014-05-23 09:39:56 UTC
Permalink
Post by Jacob Kroon
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.
Post by Jacob Kroon
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.
Post by Jacob Kroon
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no background image, but instead write the background image manually into /dev/fb0. In this way, the IPU will blend the result onto the display. This seemed to be even worse than letting the GPU render the background.
Can the scenegraph be smart enough in such a way that it will only "clear" dirty rectangles with a user supplied background image ? Or are there any other tricks I am not aware of ?
The default scene graph renderer renders the full screen. Doing partial updates requires a lot of support from the underlying drivers and hardware. If you really want to, you can give it a shot of course. You can copy the existing renderer, adapt it to expose dirty areas and make use of partial swap buffers extension if this is available (and the underlying display stack actually does propagate the sub regions all the way to the display).
Post by Jacob Kroon
Regards Jacob
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Jacob Kroon
2014-05-27 08:28:17 UTC
Permalink
Hi Gunnar,
Post by Jacob Kroon
Post by Jacob Kroon
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".
Post by Jacob Kroon
I've experimented with
Post by Jacob Kroon
* 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.
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)
Post by Jacob Kroon
Post by Jacob Kroon
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no
background image, but instead write the background image manually into
/dev/fb0. In this way, the IPU will blend the result onto the display. This
seemed to be even worse than letting the GPU render the background.
Post by Jacob Kroon
Can the scenegraph be smart enough in such a way that it will only
"clear" dirty rectangles with a user supplied background image ? Or are
there any other tricks I am not aware of ?
The default scene graph renderer renders the full screen. Doing partial
updates requires a lot of support from the underlying drivers and hardware.
If you really want to, you can give it a shot of course. You can copy the
existing renderer, adapt it to expose dirty areas and make use of partial
swap buffers extension if this is available (and the underlying display
stack actually does propagate the sub regions all the way to the display).
Writing a custom renderer would have to be a final resort ..

Thanks,
Jacob
Gunnar Sletta
2014-05-27 08:36:52 UTC
Permalink
Post by Jacob Kroon
Hi Gunnar,
Post by Jacob Kroon
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".
Post by Jacob Kroon
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?
Post by Jacob Kroon
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.
Post by Jacob Kroon
Post by Jacob Kroon
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no background image, but instead write the background image manually into /dev/fb0. In this way, the IPU will blend the result onto the display. This seemed to be even worse than letting the GPU render the background.
Can the scenegraph be smart enough in such a way that it will only "clear" dirty rectangles with a user supplied background image ? Or are there any other tricks I am not aware of ?
The default scene graph renderer renders the full screen. Doing partial updates requires a lot of support from the underlying drivers and hardware. If you really want to, you can give it a shot of course. You can copy the existing renderer, adapt it to expose dirty areas and make use of partial swap buffers extension if this is available (and the underlying display stack actually does propagate the sub regions all the way to the display).
Writing a custom renderer would have to be a final resort ..
Thanks,
Jacob
Jacob Kroon
2014-06-05 09:39:55 UTC
Permalink
Hi Gunnar,
Post by Jacob Kroon
Post by Jacob Kroon
Hi Gunnar,
Post by Jacob Kroon
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.
Post by Jacob Kroon
If it cannot render a single image at that resolution, then it is not a
suitable hardware for that resolution :)
Post by Jacob Kroon
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)
Post by Jacob Kroon
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.
Post by Jacob Kroon
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".
Post by Jacob Kroon
Post by Jacob Kroon
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.
Post by Jacob Kroon
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.
Post by Jacob Kroon
See the performance guidelines of your GPU for the actual recommendation
for your chip.
Post by Jacob Kroon
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.
Post by Jacob Kroon
Post by Jacob Kroon
Also, playing with QSG_RENDERER_BATCH_VERTEX_THRESHOLD and
QSG_RENDERER_BATCH_NODE_THRESHOLD,
Post by Jacob Kroon
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,
Post by Jacob Kroon
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
Gunnar Sletta
2014-06-05 09:49:28 UTC
Permalink
Post by Jacob Kroon
Hi Gunnar,
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
The generated noise there is using several "complex" math functions, so it might be on the tough side if you are on the edge of what the GPU can handle. You could try to replace the noise with a small 8-bit noise-tile of say 16x16 pixels.

cheers,
Gunnar

Jason H
2014-05-23 11:02:03 UTC
Permalink
<html>
<head>
</head>
<body>Three was some static flag that I seem to b remember that could be set to hekp with spending less time in repaonts. Maybe it was for text maybe it was qlabels. But it is something to that effect. <br>
-- <br>
Sent from my Android phone with GMX Mail. Please excuse my brevity.<br><br><div class="gmail_quote">Jacob Kroon &lt;***@gmail.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>
<div>
<div>
Hi,<br/>
<br/>
</div>
I&#39;m experimenting with a Qt application running on the Wandboards,<br/>
at full hd resolution, 1920x1080x32. I have a static background image, and some small animated Qml-elements on the screen. I&#39;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. I&#39;ve experimented with<br/>
<br/>
</div>
<div>
* 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.<br/>
<br/>
</div>
<div>
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no background image, but instead write the background image manually into /dev/fb0. In this way, the IPU will blend the result onto the display. This seemed to be even worse than letting the GPU render the background.<br/>
<br/>
</div>
<div>
Can the scenegraph be smart enough in such a way that it will only &quot;clear&quot; dirty rectangles with a user supplied background image ? Or are there any other tricks I am not aware of ?<br/>
<br/>
</div>
<div>
Regards Jacob<br/>
</div>
</div>
_______________________________________________ Interest mailing list ***@qt-project.org<a href="http://lists.qt-project.org/mailman/listinfo/interest" target="_blank"> http://lists.qt-project.org/mailman/listinfo/interest</a>
</blockquote></div></body>
</html>
Smoke Water
2014-05-26 12:05:22 UTC
Permalink
Hello,

I'm facing similiar performance challanges with that "super duper high
performance" imx6 controller...
Reducing the bit depth sounds quite interesting to me. Is further
information available how to tell Qt to use for example 16 bit instead of
32 bit for calculations? What happens with opacity/alpha information in
that case?

The same applies to the framerate. Is there a Qt interface to reduce the
framerate? Or is it a global framebuffer setting?
It seems to me that the eglfs plugin renders as fast as possible while for
example the wayland plugin is limited to the display refresh rate.


Thank you very much,
Martin Ertl
Date: Fri, 23 May 2014 09:39:56 +0000
Subject: Re: [Interest] Qt5 performance on imx6 with full hd
Content-Type: text/plain; charset="us-ascii"
Post by Jacob Kroon
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.
Post by Jacob Kroon
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.
Post by Jacob Kroon
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no
background image, but instead write the background image manually into
/dev/fb0. In this way, the IPU will blend the result onto the display. This
seemed to be even worse than letting the GPU render the background.
Post by Jacob Kroon
Can the scenegraph be smart enough in such a way that it will only
"clear" dirty rectangles with a user supplied background image ? Or are
there any other tricks I am not aware of ?
The default scene graph renderer renders the full screen. Doing partial
updates requires a lot of support from the underlying drivers and hardware.
If you really want to, you can give it a shot of course. You can copy the
existing renderer, adapt it to expose dirty areas and make use of partial
swap buffers extension if this is available (and the underlying display
stack actually does propagate the sub regions all the way to the display).
Post by Jacob Kroon
Regards Jacob
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
------------------------------
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Gunnar Sletta
2014-05-26 12:43:20 UTC
Permalink
Post by Smoke Water
Hello,
I'm facing similiar performance challanges with that "super duper high performance" imx6 controller...
Reducing the bit depth sounds quite interesting to me. Is further information available how to tell Qt to use for example 16 bit instead of 32 bit for calculations? What happens with opacity/alpha information in that case?
You can request different GL surface formats through QSurfaceFormat in Qt, but what the GL context actually takes into use is decided by the platform plugin. What is used in the rest of the display stack is out of Qt's control.
Post by Smoke Water
The same applies to the framerate. Is there a Qt interface to reduce the framerate? Or is it a global framebuffer setting?
It seems to me that the eglfs plugin renders as fast as possible while for example the wayland plugin is limited to the display refresh rate.
We generally request a vsynced opengl context and then render as fast as possible (being throttled, for instance by eglSwapBuffer). You can control this through public Qt API in 5.3 using QSurfaceFormat::setSwapInterval(), but the platform plugin is free to ignore this hint.

Another thing that might be relevant to check is if the problem is that of un-even animation steps. Does setting QSG_FIXED_ANIMATION_STEP=1 in the environment have an impact?

cheers,
Gunnar
Post by Smoke Water
Thank you very much,
Martin Ertl
Date: Fri, 23 May 2014 09:39:56 +0000
Subject: Re: [Interest] Qt5 performance on imx6 with full hd
Content-Type: text/plain; charset="us-ascii"
Post by Jacob Kroon
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.
Post by Jacob Kroon
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.
Post by Jacob Kroon
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no background image, but instead write the background image manually into /dev/fb0. In this way, the IPU will blend the result onto the display. This seemed to be even worse than letting the GPU render the background.
Can the scenegraph be smart enough in such a way that it will only "clear" dirty rectangles with a user supplied background image ? Or are there any other tricks I am not aware of ?
The default scene graph renderer renders the full screen. Doing partial updates requires a lot of support from the underlying drivers and hardware. If you really want to, you can give it a shot of course. You can copy the existing renderer, adapt it to expose dirty areas and make use of partial swap buffers extension if this is available (and the underlying display stack actually does propagate the sub regions all the way to the display).
Post by Jacob Kroon
Regards Jacob
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
------------------------------
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Martin Ertl
2014-05-27 08:07:52 UTC
Permalink
Hello,

thank you for the quick response.

At the moment I have to use a quite old version of Qt (5.0.2) and it seems
to me that this does not support QSG_FIXED_ANIMATION_STEP, at least I
cannot find that string in any source file but I do in up to date source
files.
I'll try to get a newer version running to check what happens in that case.

Thanks again,
best Regards
Martin
Post by Smoke Water
Hello,
I'm facing similiar performance challanges with that "super duper high
performance" imx6 controller...
Reducing the bit depth sounds quite interesting to me. Is further
information available how to tell Qt to use for example 16 bit instead of
32 bit for calculations? What happens with opacity/alpha information in
that case?
The same applies to the framerate. Is there a Qt interface to reduce the
framerate? Or is it a global framebuffer setting?
It seems to me that the eglfs plugin renders as fast as possible while for
example the wayland plugin is limited to the display refresh rate.
Thank you very much,
Martin Ertl
Date: Fri, 23 May 2014 09:39:56 +0000
Subject: Re: [Interest] Qt5 performance on imx6 with full hd
Content-Type: text/plain; charset="us-ascii"
Post by Jacob Kroon
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.
Post by Jacob Kroon
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.
Post by Jacob Kroon
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no
background image, but instead write the background image manually into
/dev/fb0. In this way, the IPU will blend the result onto the display. This
seemed to be even worse than letting the GPU render the background.
Post by Jacob Kroon
Can the scenegraph be smart enough in such a way that it will only
"clear" dirty rectangles with a user supplied background image ? Or are
there any other tricks I am not aware of ?
The default scene graph renderer renders the full screen. Doing partial
updates requires a lot of support from the underlying drivers and hardware.
If you really want to, you can give it a shot of course. You can copy the
existing renderer, adapt it to expose dirty areas and make use of partial
swap buffers extension if this is available (and the underlying display
stack actually does propagate the sub regions all the way to the display).
Post by Jacob Kroon
Regards Jacob
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
------------------------------
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Filip Piechocki
2014-05-27 09:24:30 UTC
Permalink
Previously (I think pre-5.2) this env variable name started with QML
instead of QSG, so try:
QML_FIXED_ANIMATION_STEP

BR,
Filip Piechocki
Post by Smoke Water
Hello,
thank you for the quick response.
At the moment I have to use a quite old version of Qt (5.0.2) and it seems
to me that this does not support QSG_FIXED_ANIMATION_STEP, at least I
cannot find that string in any source file but I do in up to date source
files.
I'll try to get a newer version running to check what happens in that case.
Thanks again,
best Regards
Martin
Hello,
Post by Smoke Water
I'm facing similiar performance challanges with that "super duper high
performance" imx6 controller...
Reducing the bit depth sounds quite interesting to me. Is further
information available how to tell Qt to use for example 16 bit instead of
32 bit for calculations? What happens with opacity/alpha information in
that case?
The same applies to the framerate. Is there a Qt interface to reduce the
framerate? Or is it a global framebuffer setting?
It seems to me that the eglfs plugin renders as fast as possible while
for example the wayland plugin is limited to the display refresh rate.
Thank you very much,
Martin Ertl
Date: Fri, 23 May 2014 09:39:56 +0000
Subject: Re: [Interest] Qt5 performance on imx6 with full hd
Content-Type: text/plain; charset="us-ascii"
Post by Jacob Kroon
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.
Post by Jacob Kroon
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.
Post by Jacob Kroon
* Letting Qt5 render into /dev/fb1 overlay on the imx6, with no
background image, but instead write the background image manually into
/dev/fb0. In this way, the IPU will blend the result onto the display. This
seemed to be even worse than letting the GPU render the background.
Post by Jacob Kroon
Can the scenegraph be smart enough in such a way that it will only
"clear" dirty rectangles with a user supplied background image ? Or are
there any other tricks I am not aware of ?
The default scene graph renderer renders the full screen. Doing partial
updates requires a lot of support from the underlying drivers and hardware.
If you really want to, you can give it a shot of course. You can copy the
existing renderer, adapt it to expose dirty areas and make use of partial
swap buffers extension if this is available (and the underlying display
stack actually does propagate the sub regions all the way to the display).
Post by Jacob Kroon
Regards Jacob
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
------------------------------
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Loading...