Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Estimating image-bus bandwidth usage in CWM: (2 Items)
   
Estimating image-bus bandwidth usage in CWM  
In order to have control over flicker in our i.mx35-based system with limited image-bus bandwidth
we would like  come up with an estimate on the upper bound of bandwidth usage.

We have some limited understanding of the factors, as follows:

Bandwidth usage with multiple physical layers is the sum of bandwidth usage for each layer.  The bandwidth usage may be 
different
for each layer, depending on the applications running on the given layer.

For each layer the bandwidth usage is the sum 3 components of:
   1.   display controller refresh bandwidth:

         display_refresh_rate * pixel_count * bits_per_pixel

         where
 
         pixel_count is about display_width * display_height
         (e.g. 640*480 in VGA mode)

   2.  content updates of all applications rendering to the given
        physical layer:

            sum of bandwidth use of each application's update,
            regardless of whether the application's window is
            fully occluded or fully visible


         How to compute the BW usage resulting from a single
         application updating a 100 * 100 pixels window?

         Is the BW usage the same whether we draw just a diagonal
         line from the top-left to the bottom right corner and when
         we draw a square filling the complete 100 x 100 area?

         Will the bandwidth usage increase if we redraw (parts) of the
         100 * 100 pixels window multiple times in a single update
         cycle, such as when clearing the background completely first
         and then rendering a vector-based map?

         What other factors influence the bandwidth use resulting from
         content updates?

         
   3.   Compositing of dirtied rectangles at the application's update
         rate

         How to estimate bandwidth usage by the compositing
         process depending on the area of diritied rectangles?

         Is the bandwidth usage here dependent on whether the
         dirtied rectangles of different applications overlap or not?

Is there any other factor to consider for estimating the bandwidth
usage?

Is the bandwidth usage the same regardless of using the OpenVG
accelerator or doing all rendering by software?


Re: Estimating image-bus bandwidth usage in CWM  
For component #2, it is very difficult to estimate the total bandwidth usage for rendering a 100 x 100 window. Things to
 consider:

* Are all pixels touched ? If the surface is single-buffered, you could skip the clear and just redraw parts of the 
buffer. If the surface is double-bufferd (the default), all pixels have to be redrawn. EGL_SWAP_BEHAVIOR_PRESERVED may 
let the application think that it doesn't have to redraw all the pixels, but under the hood it's just a blit.

* What is the architecture of the graphics core ? Graphics core that do deferred rendering like PowerVR will only write 
each pixel once. If the rendering is not deferred, then clearing the surface before drawing a line will take a little 
more bandwidth because of the pixel overdaws.

* Are there any per-pixel image-based operations ? If a pixel requires memory lookups (texture sampling, blits, 
transparency masks), then the bandwidth usage will be higher. Other per-pixel operations like blending will have an 
impact as well.

* Are other buffers involved in the rendering process like stencil buffers, depth buffers ? What rendering API is used ?
 Using OpenVG, or OpenGL ES, or doing everything in software will probably affect bandwidth.

* Is anti-aliasing enabled ? Each anti-aliasing technique (full-scene, multi-sampling, coverage) and the sampling 
resolve will affect memory bandwidth.

For component #3, the scene layout is an important factor. The composition manager clips all the windows into rectangles
 so that there are no overdraws. However, overlaps when blending is enabled cannot be eliminated.