Overview
FM4, S6E2DH/S6E2DF/S6E2D5/S6E2D3 Series, 32-Bit Microcontroller, Graphic Driver User Manual, Doc. No. 002-04387 Rev. *A
21
The following table gives an overview about supported surface properties and features:
Target
Surface and context properties
STORE
−
All RGBA formats.
SRC
−
All RGBA formats.
−
Geometry operations like translation, scaling, rotation and perspective transformation.
−
Decompression or indexed color. (Restriction: DST must not use these features, only scale and translation
operations are supported)
−
Warping. (No geometry operations possible)
DST
−
All RGBA formats.
−
Geometry operations like translation, mirroring and simple rotation (multiple of 90 degree).
−
Decompression or indexed color. (Restriction: SRC must not use these features, no mirroring or simple
rotation)
MASK
−
All RGBA formats except 18 bpp.
−
Geometry operations like translation, mirroring and multiple of 90 degree rotations
−
Scaling. (Restriction: SRC must use the same scale factors)
Note:
The pixel operations may not be finished after a mmlGdcPeFill or mmlGdcPeBlt call. That means the involved
buffers may still be in use. Please use synchronization objects or simply mmlGdcPeFinish to ensure that all
operations are complete.
Pixel Engine operations can be queued by the driver to enhance performance especially in a multi-threading
environment. The fast execution especially of long processing commands can be forced by an mmlGdcPeFlush call.
For more details about the usage of the Pixel Engine API see the tutorials and the respective sample code that are
part of this driver documentation.
4.5 Synchronization Overview
4.5.1 Processing Units
The S6E2D hardware consists of several independent, parallel running units. The driver is designed so that
applications can use this parallel processing also in single threaded environment. The driver distinguishes the
following processing pipelines:
CPU: The ARM core executing the program code.
The PixEng processing block. All blit instructions for this pipeline will be pushed by the driver into the Command
Sequencer queue. That means the application (the CPU) can initiate many fill and blit commands in a series,
without having to wait for completion of these commands. The graphics hardware starts operating in parallel,
typically it requires more time to process the pixels than to setup the processing by the CPU.
Windows: All graphics hardware layers are represented as Windows in the driver and handled as separate
processing units. Changing properties like the frame buffer address of a window must be committed using
mmlGdcDispWinCommit(). The new properties become active with the next frame start on the display. A commit
instruction may block the CPU, if the previously called mmlGdcDispWinCommit() is not yet active in the HW.
That means if two calls of mmlGdcDispWinCommit() are called one after the other, the second call will be
blocked until the next frame start. This behavior can be changed using the
MML_GDC_CONFIG_ATTR_DISPLAY_NOBLOCK attribute of mmlGdcConfigSetAttribute() or by using the
driver synchronization API.
Display: The display (more precisely: display controller) is also handled as a separate unit.