Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - CM/OpenKODE "performance": (10 Items)
   
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?
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.
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.


Attachment: Text winmgr.conf 12.77 KB
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...
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.

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?
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()??
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?
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.
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.