Gary Faulkner
|
CM/OpenKODE "performance"
|
Gary Faulkner
01/22/2010 7:42 AM
post45753
|
CM/OpenKODE "performance"
I was doing some performance comparisons this morning (imx35 based) between drawing images in the CM environment using
blit2() vs. vgDrawImage(). First thing I noticed is that blit2 is *slightly* faster than vgDrawImage() (for the same
image -- on the order of 11-12 fps for blit2() vs. 7-8 fps for vgDrawImage() on a 780x380 RGB/A png).
However, while watching all of this, I notice that io-winmgr consumes a TON of CPU. I guess I'm wondering a couple of
things:
1) Is it fully utilizing the HW capabilities I have for doing the compositing?
2) It seems like the expensive call here is eglSwapBuffers(). Why is that, and is there any tuning I can do to get
around that fact?
I ask about #1 because of the banding issue I discuss in http://community.qnx.com/sf/discussion/do/listPosts/projects.
graphics/discussion.cwm_openkode.topc11707
At any rate.. I'm wondering, even in this relatively simple case, if there is some io-winmgr tuning I can/should be
doing to get better performance/results (less CPU utilization too). Also, I'd still like to understand how to get
around the banding issue that I'm seeing.
I haven't yet run a comparable test using just gf, but I fully expect it to be significantly faster (in terms of fps).
Thoughts?
|
|
|
Etienne Belanger(deleted)
|
Re: CM/OpenKODE "performance"
|
Etienne Belanger(deleted)
01/22/2010 8:48 AM
post45762
|
Re: CM/OpenKODE "performance"
Please provide us with your winmgr.conf configuration file to better help us determine what the composition manager
might be trying to do.
Other questions:
What is the EGL_SWAP_BEHAVIOR set to ? If EGL_BUFFER_PRESERVED is requested this will add to the amount of work EGL has
to do when swapping buffers.
What are the values for KD_WINDOWPROPERTY_BUFFER_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_SIZE_QNX,
KD_WINDOWPROPERTY_SOURCE_POSITION, KD_WINDOWPROPERTY_SIZE, and KD_WINDOWPROPERTY_POSITION_QNX ?
What is the value of EGL_RED_SIZE, EGL_BLUE_SIZE, EGL_GREEN_SIZE, and EGL_ALPHA_SIZE of the EGLConfig that your
application is using to create the window surface ?
Note that using the composition manager does have a performance impact, even if compositing is disabled. In this case,
EGL is forced to wait for renders to complete before sending a post message to the composition manager. This eliminates
any potential overlapping of CPU and GPU and causes the GPU to be idle for some time, unless other applications are
running in parallel. Consequently, free running frame rates of applications without composition manager will always be
equal or higher than their composition manager counterpart. This can be overcome with triple buffering, which might be
added to our EGL at some point.
|
|
|
Gary Faulkner
|
Re: CM/OpenKODE "performance"
|
Gary Faulkner
01/22/2010 10:51 AM
post45779
|
Re: CM/OpenKODE "performance"
Hello:
I've attached my current winmgr.conf. Other responses inline:
> Please provide us with your winmgr.conf configuration file to better help us
> determine what the composition manager might be trying to do.
>
> Other questions:
>
> What is the EGL_SWAP_BEHAVIOR set to ? If EGL_BUFFER_PRESERVED is requested
> this will add to the amount of work EGL has to do when swapping buffers.
EGL_SWAP_BEHAVIOR is set to EGL_BUFFER_DESTROYED
>
> What are the values for KD_WINDOWPROPERTY_BUFFER_SIZE_QNX,
> KD_WINDOWPROPERTY_SOURCE_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_POSITION,
> KD_WINDOWPROPERTY_SIZE, and KD_WINDOWPROPERTY_POSITION_QNX ?
KD_QNX_WINDOWPROPERTY_SOURCE_SIZE is 780,380
KD_QNX_WINDOWPROPERTY_SOURCE_POSITION is 0,0
KD_WINDOWPROPERTY_SIZE is 780,380
KD_QNX_WINDOWPROPERTY_POSITION_QNX is 0,0
>
> What is the value of EGL_RED_SIZE, EGL_BLUE_SIZE, EGL_GREEN_SIZE, and
> EGL_ALPHA_SIZE of the EGLConfig that your application is using to create the
> window surface ?
They are 8,8,8,8 respectively.
>
> Note that using the composition manager does have a performance impact, even
> if compositing is disabled. In this case, EGL is forced to wait for renders to
> complete before sending a post message to the composition manager. This
> eliminates any potential overlapping of CPU and GPU and causes the GPU to be
> idle for some time, unless other applications are running in parallel.
> Consequently, free running frame rates of applications without composition
> manager will always be equal or higher than their composition manager
> counterpart. This can be overcome with triple buffering, which might be added
> to our EGL at some point.
Yup... I expected some performance impact, but not close to an order of magnitude. I have run that same test image
through a simple gf blitting directly to a layer (without io-winmgr running) and get about 65 fps on that.
So, overall I have several applications all running at the same time using CM. Aside from some transitions putting
application windows on and off the screen, when an application window is visible, it owns the entire displayable area
(800x480). Obviously my little image test program is only creating a window as large as the image it is displaying, so
that may not count. Actually, I just ran a test with a full-screen sized image (and window) and it's fps using CM and
openvg is about 4.5 fps, and with just a native gf it is about 54 fps.
|
|
|
Etienne Belanger(deleted)
|
Re: CM/OpenKODE "performance"
|
Etienne Belanger(deleted)
01/22/2010 11:39 AM
post45783
|
Re: CM/OpenKODE "performance"
I thought the blit2 test gave you 11-12 fps, not 54. One shouldn't compare native to composition manager if the format
is configured to swap surfaces while the latter is configured to blit.
In any case, the first thing is to confirm that you want blitting enabled instead of surface swapping. From past posts,
it seems you want to have multiple windows on one layer. If this is not the case, I suggest you remove the egl-config =
... line and replace it with wfd-pipeline = 1.
Otherwise, you might want to try an EGL config id that matches your 8888 pixel format, instead of using auto. It is
possible that blits that require format conversion revert to software on this driver. Alternatively, you can always
modify your blit2 GF test to blit from an 8888 surface to a 565 surface to see if you get similar results...
|
|
|
Gary Faulkner
|
Re: CM/OpenKODE "performance"
|
Gary Faulkner
01/22/2010 11:50 AM
post45785
|
Re: CM/OpenKODE "performance"
> I thought the blit2 test gave you 11-12 fps, not 54. One shouldn't compare
> native to composition manager if the format is configured to swap surfaces
> while the latter is configured to blit.
Sorry, I got confusing there; yes, I got 11-12 fps using blit2 with CM, and 54ish with blit2 on gf. I was only pointing
out that I didn't expect that much of a drop off (penalty) just from using CM.
>
> In any case, the first thing is to confirm that you want blitting enabled
> instead of surface swapping. From past posts, it seems you want to have
> multiple windows on one layer. If this is not the case, I suggest you remove
> the egl-config = ... line and replace it with wfd-pipeline = 1.
So... I guess I don't really understand this. What is the difference. I guess what I'm saying is that I only want to
use 1 layer of the hardware (one of the reasons for us migrating to CM); However, I want to be able to display windows
from multiple applications on that one layer.
If I have wfd-pipeline=1 there instead of egl-config, what are the ramifcations of that? Does that mean I don't really
get "compositing"??
>
> Otherwise, you might want to try an EGL config id that matches your 8888 pixel
> format, instead of using auto. It is possible that blits that require format
> conversion revert to software on this driver. Alternatively, you can always
> modify your blit2 GF test to blit from an 8888 surface to a 565 surface to see
> if you get similar results...
Actually, I have verified that the configuration that I pick is the right one with 8888 surface.
|
|
|
Gary Faulkner
|
Re: CM/OpenKODE "performance"
|
Gary Faulkner
01/22/2010 1:09 PM
post45795
|
Re: CM/OpenKODE "performance"
so, when I change to use wfd-pipline = 1, I no longer have any egl configs?? (at least according to sysres). Why would
that be?
|
|
|
Gary Faulkner
|
Re: CM/OpenKODE "performance"
|
Gary Faulkner
01/22/2010 1:25 PM
post45797
|
Re: CM/OpenKODE "performance"
heh... helps if I spell pipeline correctly (apparently -- go figure).
So, now my question becomes... do I no longer do eglSwapBuffers()??
|
|
|
Gary Faulkner
|
Re: CM/OpenKODE "performance"
|
Gary Faulkner
01/22/2010 1:46 PM
post45799
|
Re: CM/OpenKODE "performance"
so, apparently, for me, the right combination *might* be egl-config=1 (the one that matches the color-depth I want), and
wfd-pipeline=1.
In the blit2() case, with an image that is 780x380, this resolved two things:
1) my banding issue is now gone.
2) the frame rate is up to about 29 fps -- which I can definitely live with.
Does this make any sense?
|
|
|
Joel Pilon(deleted)
|
Re: CM/OpenKODE "performance"
|
Joel Pilon(deleted)
01/22/2010 2:06 PM
post45800
|
Re: CM/OpenKODE "performance"
You can try setting your swap interval to 0 for benchmarking purposes.
You can set swap interval with:
eglSurfaceAttrib(egl_disp, egl_window_surf, EGL_SWAP_INTERVAL_QNX, 0);
It's no recommended to always run with interval 0, since updates will be inconsistent and artifacts can be introduced.
You'll still need to call eglSwapBuffers since your window is still double buffered. Running with rgb565/argb1555 would
offer better performance also, assuming you don't need source-alpha blending.
|
|
|
Etienne Belanger(deleted)
|
Re: CM/OpenKODE "performance"
|
Etienne Belanger(deleted)
01/25/2010 8:28 AM
post45850
|
Re: CM/OpenKODE "performance"
You do need to call eglSwapBuffers. It doesn't matter if your window is single- or double-buffered, eglSwapBuffers is
what's going to trigger composition by io-winmgr. If you don't call it, all your updates will remain offscreen.
|
|
|
|