Tutorial
FM4, S6E2DH/S6E2DF/S6E2D5/S6E2D3 Series, 32-Bit Microcontroller, Graphic Driver User Manual, Doc. No. 002-04387 Rev. *A
59
The sample draws 10 bars, 2 background images and a debug bar in one half of the frame. It means the driver
needs approximately 500 Byte (or 125 registers writes) for one blit in this sample. Please note, the required bytes for
a blit depends on the operation and properties. We need 3 sources to render the bars. In many cases only 2 sources
are used. However, a blit with a surface with an index table of 256 colors needs much more instruction buffer
because the palette with 256
∗
4 register values already requires 1 kB command sequencer space.
To allow a fancy background animation the init function also allocates a 128
∗
128
∗
4 (alpha) bpp surface and renders
the following pattern in this surface:
Figure 26. Background pattern
All these memory blocks together need about 411 kB VRAM.
6.9.1.3
Render time analysis
To generate a render job that generates a real GPU load for the 2D render hardware this sample uses a background
animation using 2 bilinear full screen rotations. For real applications this is not a typical use case and the GPU load
will be smaller. The animated bars of the chart are the foreground for this sample. Approximately up to 75% of the
screen size are filled by the bars. It means that the buffer will be filled about 2.75 times by bilinear blit operations.
Bilinear blits (here rotation and sub-pixel movement) need 2 clock cycles for one pixel so we expect 480
∗
272
∗
2
∗
2.75
clock cycles to render one frame. For a 160 MHz clocked blit engine it requires about 5 ms or 1/3 frame if we use a
60 Hz panel. In practice the render time will be much longer because the cylinderical bitmap used to blit the bars will
be read from external flash and access to external resources are not as fast as VRAM access. To see the render
time of about 5 ms you can simple change the line
UTIL_SUCCESS(ret, s_sCylinder.SurfLoadBitmap(cylinder));
to
UTIL_SUCCESS(ret, s_sCylinder.SurfLoadBitmap(cylinder, MM_TRUE));
This change copies the bitmap to VRAM with fast access time. The example does not make a VRAM copy to
generate the high GPU load.
6.9.1.4
Single buffer render mode
One possible implementation for single buffer render mode is to use the blanking period of the timing only. This
procedure is used in the Speedometer sample.
In many cases the banking period is too short to redraw all animated buffers. In this case the application can force
the HW only to update a part of the frame buffer, if this part of the frame buffer is currently not read by the display
controller.
This example uses a single full screen buffer, splitted into an upper and a lower part. It is also possible to divide the
screen resolution by using smaller windows. Using different windows is the preferred version because it allows to
render a window one time per frame. However, the size and position of the windows must fit the memory scan order
for the panel. Typical panels are landscape panels that means the windows must be arranged vertical.
For a single buffer window solution the render function must ensure that only parts of the buffer a updated. This can
be realized by using the STORE clipping function of the driver:
