iMX6 Various Device Specific Content

• iMX6 Specific Best Practices
• Candera Device Packages
• FeatStd Overview
• Compile Shaders
• Render Targets

iMX6 Specific Best Practices

Description

CGI Studio supports 2D and 3D content creation, composition, and rendering. For iMX6 the Candera graphics engine renders both 2D and 3D content via OpenGL ES API.

This chapter includes design and programming guidelines. It is strongly recommended to follow those hints to utilize iMX6 in a performance-optimized manner.

Candera Graphics Engine supports both OpenGL ES 2.0 and OpenGL ES 3.0. Selected performance features of OpenGL ES 3.0 are available in OpenGL ES 2.0 as extensions.

Those OpenGL ES 2.0 extensions that are supported by iMX6 and Candera are listed below:

Multi Frequency Rendering 

Multi frequency rendering requires either multiple buffered hardware layers (display planes) or software layers. While one layer is rendered and swapped with a higher frequency (e.g. swapping each frame results in 60 FPS), another layer is drawn partially and not swapped unless rendering is complete (e.g. swapping each second frame results in 30 FPS).

When software-layers are used, different update rates of the software-layers can be achieved through multi frequency rendering. It should be considered that the software layers still need to be drawn and blended in every frame and will consume memory bandwidth even when rendering to the software-layer is done at a lower rate.

Special Alpha Blending Techniques 

MSAA Blending

The iMX6 platform supports multi-sampling anti-aliasing (MSAA) to avoid jagged edges. MSAA renders multiple samples per pixel and combines them to a final color. This circumstance can be used to render transparent objects in a very performant manner, too. Instead of alpha blending via blend-mode, MSAA can be used to render only a selected percentage of samples per pixel. With that approach blend operations and read/write operations, which are typically required for blending, can be omitted.

Example:
MSAA is defined to accommodate 4 samples per pixel. The alpha value can define the coverage of samples to be written into frame buffer. Coverage of 50% means that half the samples are written, resulting in 2 of 4 samples being rendered. When the samples are finally combined to one pixel, the rendered object contributes only with 2 of 4 samples, which results in 50 % transparency.

Layer Blending

When blending multiple layers a correct alpha value must be written to the layer. By default objects overwrite the current alpha value of a pixel in the layer. In case of layer blending the alpha value of a pixel must be correctly combined with the existing alpha value.

Default alpha blend setting (optimized for performance):

Alpha blend setting for blending multiple layers:

Shader 

Shader Precision

It is strongly recommended to use precision "high" in iMX6 shaders.

As medium and low precisions are converted to 32 bit internally, work load for conversion is required, while only saving little amount of memory compared to textures.

Utilization

One strength of iMX6 is the fast shader computation unit. Utilize it best, by computing color values instead of texture fetches. Take care of pixel throughput and bandwidth utilization. Reduction of pixel coverage in frame-buffer is of utter importance.

Example:
Do not use full-screen backgrounds or big textures. In 2D reduce coverage by tessellated, smaller shaped images or in 3D even better by right-shaped geometry, with least pixel coverage.

Binary Shaders

Candera supports both binary shaders (pre-compiled) and binary shader programs (pre-compiled and linked) on the iMX6 platform. Use them to reduce start-up time significantly.

Textures 

Procedural Textures

For iMX6 it is advised to use procedural textures whenever possible in order to both, overcome limited bandwidth and to utilize fast shader units.

Example:
Instead of storing a color gradient in a texture, calculate color in shader related to the texture coordinate given.

Texture Compression

Use ETC2 texture compression on iMX6. This measure saves bandwidth and memory consumed.

Consider Tile Size

The iMX6 platform internally uses a tile-based rendering approach. Make sure to align render-area with the optimal tile size of 16x8 pixels. Small intersections of adjacent tiles shall be avoided. Partial coverage of tiles results in wasted performance.

Scene Partitioning 

Recommended Partitioning of a 2D Scene

Attempt to reduce dimension of rectangles by omitting areas that are invisible (e.g. same color as background) or occluded (another opaque image is rendered on top of it). This spares pixel coverage.
Furthermore, only those regions need to be redrawn that are not covered by moving needle.
Example: A classical, round tachometer with a needle shall be rendered. The tachometer basically consists of a tachometer image and a needle image. Except of the tachometer’s dial most pixels within tachometer’s image have same color as background. Tip: Scissor the tachometer into multiple smaller rectangles to avoid rendering of a huge rectangular image, which renders big portion of same color on top of background. This measure spares pixel coverage. Furthermore, only those clipped tachometer image rectangles must be redrawn that are not covered by moving needle.
Advantages:

Recommended Partitioning of a 3D Scene

Use materials instead of textures, no image data required.
Material can be defined directly in shader to reduce number of shader parameters.
Geometry allows occluding exactly those areas visible; no wasted pixels are rendered into framebuffer.
To mitigate aliasing effects (jagged edges), fade out silhouette with transparency.
Advantages:

Layer Configuration 

The iMX6 hardware and layer capabilities are reflected in SceneComposer configuration.

Hardware Layers via Planes:
One IPU (Image Processing Unit) blends two planes efficiently with Display Processor (DP).
Restrictions of the planes:

Split of content in two layers allows rendering in multiple frequencies. See chapter Multi Frequency Rendering for more details.

Software Layers:
Software Layers are supported via off-screen surfaces. Up to eight software layers can be blended in one single pass. In successive blend-passes even more software layers are possible. The use of software layers is fully integrated in SceneComposer.

Arbitrary Warping:
Full support for arbitrary warping as required for Head-up display.
CGI Studio supports arbitrary warping for Head-up displays on iMX6. Warping is internally realized via morphed warping mesh.

Candera Device Packages

Supported Device Packages

Candera provides device implementations for following device types:

Device-Specific CMake Settings

To build a certain device package selected it from the drop-down list of the CMake property "CGIDEVICE_NAME":

For each device package, either building OpenGL based host simulation or target binaries can be selected via the Boolean CMake property "CGIDEVICE_TARGET_BUILD".

The following table illustrates configurations available for the supported device package:

The CMake properties "PUB_CGI_CPU", "PUB_CGI_OS" usually cannot be configured via the CMake user interface, but are autonomously detected by
the build system. The same applies for the variable "PUB_CGI_COMPILER".

If you don't use the CGI Studio 3rd party software folder structure, the driver paths can be specified in the variables

Depending on these properties, either MS Visual Studio solutions or Unix makefiles will be generated into the specified build
directory.

FeatStd Overview

Introduction

For general information and an overview of FeatStd please refer to FeatStd Overview.

See here a typical output of a CMake configuration run of FeatStd:

Building project: FeatStd vW.X.Y.Z
---------------------------------
Pre-sets from calling project FeatStd:
    Pre-set include-dirs: 
    Pre-set definitions: 
---------------------------------
FeatStd external configuration CMake variables:
    BUILD_SHARED_LIBS: OFF
    FEATSTD_3PSW_DIR: D:/cgi-studio/cgi_studio_3psw
    FEATSTD_ADD_BUILD_MODE_DEFINE: 
    FEATSTD_USE_PREBUILT_LIBS: OFF
    FEATSTD_PREBUILT_LIB_DIR: 
---------------------------------
FeatStd feature settings:
    FEATSTD_IPC_ENABLED=OFF
    FEATSTD_LOG_ENABLED=ON
    FEATSTD_MONITOR_ENABLED=OFF
    FEATSTD_THREADSAFETY_ENABLED=OFF
    FEATSTD_UNITTEST_FRAMEWORK_ENABLED=OFF
    FEATSTD_FRACTIONAL_NUMBER_TYPE=Float
    FEATSTD_MEMORYPOOL_ENABLED=OFF
    FEATSTD_SYSTEM_MEMORY_STATISTIC_ENABLED=OFF
    FEATSTD_SYSTEM_MEMORY_STATISTIC_FILE_AND_LINE_TRACKING_ENABLED=ON
---------------------------------
FeatStd compiler defines:
    ;_CRT_SECURE_NO_WARNINGS;FEATSTD__FILE__=__FILE__
---------------------------------
FeatStd configuration file:
    Generated to D:/cgi-studio/build/gensrc/FeatStd/Config.h
---------------------------------
Exported FeatStd CMake variables:
    FEATSTD_EXPORTED_CMAKE_DIR: D:/cgi-studio/featstd/cmake
    FEATSTD_EXPORTED_DEFINITIONS: -D_CRT_SECURE_NO_WARNINGS;-DFEATSTD__FILE__=__FILE__
    FEATSTD_EXPORTED_INCLUDE_DIRECTORIES: D:/cgi-studio/featstd/src;D:/cgi-studio/build/gensrc
    FEATSTD_EXPORTED_LIB_NAME: FeatStd_x86_Win32_iMX6_Simulation_MSVC
    FEATSTD_EXPORTED_LINK_DIRECTORIES: 
    FEATSTD_EXPORTED_LINK_LIBRARIES: winmm;Ws2_32;FeatStd_x86_Win32_iMX6_Simulation_MSVC
    FEATSTD_EXPORTED_OS: Win32
    FEATSTD_EXPORTED_ROOT_DIR: D:/cgi-studio/featstd

Compile Shaders

Shader compilation is triggered in the following situations:

The compilation result can be seen in the "Problems Browser" panel. For further information please refer to section Problems Browser.

After successful shader compilation, a regarding message is displayed.

iMX6 Shader Compiler

iMX6ShaderCompiler provides support for exporting compiled (and/or linked) shaders to the asset file.

It can be configured from File/Preferences section and provides some parameters which can be changed in order to achieve the desired behavior:

1. Output type:

2. Command line - a configurable string of the following format:

<path_to_executable_file> [arg0] [arg1] [arg2] ... [argN] | expectedFileName:<output_file_name>

Example: For binary output, "expectedFileName:output" - requires that a compiled vertex shader file will be named output.vgcSL and a compiled fragment shader file will be named output.pgcSL

The command line for "Binary" output is a little bit different than the one for "Binary program" output.

Binary output command line: this command line is invoked separately for each vertex and fragments shader.

Example: "C:\Vivante\vCompiler.exe" -s4 -c $ShaderPath$ -o output | expectedFileName:output

Identifiers

Binary program output command line:

This command is invoked for a shader pair (both vertex and fragment shader)

Example: "C:\Vivante\vCompiler.exe" -v $VsPath$ $FsPath$ -o output | expectedFileName:output

Identifiers

Render Targets

Render Targets Device Capabilities

Device Capabilities

Following is an overview about what kind of render targets are supported on which device: