3.9. Graphics and Display¶

3.9.4.1. IMG PowerVR Demos¶

The Processor SDK filesystem comes packaged with example OpenGLES applications. The examples can be invoked using the below commands.

target # /usr/bin/SGX/demos/Raw/OGLES2Coverflow
target # /usr/bin/SGX/demos/Raw/OGLES2ChameleonMan
target # /usr/bin/SGX/demos/Raw/OGLES2ExampleUI
target # /usr/bin/SGX/demos/Raw/OGLES2Navigation

After you see the output on the display interface, hit q to terminate the application.

3.9.4.2. Finding Connector ID¶

Note: Most of the applications used in the Demos would require the user to pass a connector id. A connector id is a number that is assigned to each of the display devices connected to the system. To get the list of the display devices connected and the corresponding connector id one can use the modetest application (shipped with the file system) as mentioned below:

target #  modetest

Look for the display device for which the connector ID is required - such as HDMI, LCD etc.

Connectors:
id      encoder status          type    size (mm)       modes   encoders
4       3       connected       HDMI-A  480x270         20      3
  modes:
        name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 flags: phsync, pvsync; type: preferred, driver
...
16      15      connected       unknown 0x0             1       15
  modes:
        name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  800x480 60 800 1010 1040 1056 480 502 515 525 flags: nhsync, nvsync; type: preferred, driver

Usually, LCD is assigned 16 (800x480), and HDMI is assigned 4 (multiple resolutions).

3.9.4.3. Finding Plane ID¶

To find the Plane ID, run the modetest command:

target #  modetest

Look for the section called Planes. (Sample truncated output of the Planes section is given below)

Planes:
id      crtc    fb      CRTC x,y        x,y     gamma size
19      0       0       0,0             0,0     0
 formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY
 props:
 ...
20      0       0       0,0             0,0     0
 formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY
 props:
 ...

3.9.4.4. kmscube¶

Run kmscube on default display:

target # kmscube

Run kmscube on secondary display:

target # kmscube -c <connector-id>
target # kmscube -c 16 #For example, the connector id for secondary display is 16.

Run kmscube on all connected displays (LCD & HDMI):

target # kmscube -a

3.9.4.5. Wayland/Weston¶

The supported Wayland/Weston version brings in the multiple display support in extended desktop mode and the ability to drag-and-drop windows from one display to the other.

To launch weston, do the following:

On target console:

target # unset WAYLAND_DISPLAY

On default display:

target # weston --tty=1 --connector=<default connector-id>

On secondary display:

target # weston --tty=1 --connector=<secondary connector-id>

On all connected displays (LCD and HDMI):

target # weston --tty=1

The user can change the screensaver timeout using a command line option

--idle-time=<number of seconds>

For example, to set timeout of 10 minutes and weston configured to display on all connectors, use the below command:

weston --tty=1 --idle-time=600

To disable the screen timeout and to configure weston configured to display on all connectors, use the below command:

weston --tty=1 --idle-time=0

If you face any issues with the above procedure, please refer GLSDK_FAQs#Unable_to_run_Weston_on_the_GLSDK_release for troubling shooting tips.

The filesystem comes with a preconfigured weston.ini file which will be located in

/etc/weston.ini

# /usr/bin/weston-flower
# /usr/bin/weston-clickdot
# /usr/bin/weston-cliptest
# /usr/bin/weston-dnd
# /usr/bin/weston-editor
# /usr/bin/weston-eventdemo
# /usr/bin/weston-image /usr/share/weston/terminal.png
# /usr/bin/weston-resizor
# /usr/bin/weston-simple-egl
# /usr/bin/weston-simple-shm
# /usr/bin/weston-simple-touch
# /usr/bin/weston-smoke
# /usr/bin/weston-info
# /usr/bin/weston-terminal

target # gst-launch-1.0 playbin uri=file://<path-to-file-name> video-sink=waylandsink

3.9.4.6. Using IVI shell feature¶

The SDK also has support for configuring weston ivi-shell. The default shell that is configured in the SDK is the desktop-shell.

To change the shell to ivi-shell, the user will have to add the following lines into the /etc/weston.ini.

To switch back to the desktop-shell can be done by commenting these lines in the /etc/weston.ini (comments begin with a ‘#’ at the start of line).

[core]
shell=ivi-shell.so
modules=ivi-controller.so

[ivi-shell]
ivi-input-module=ivi-input-controller.so

After the above configuration is completed, we can restart weston by running the following commands

target# /etc/init.d/weston stop
target# /etc/init.d/weston start

NOTE: When weston starts with ivi-shell, the default background is black, this is different from the desktop-shell that brings up a window with background.

With ivi-shell configured for weston, wayland client applications use ivi-application protocol to be managed by a central HMI window management. The wayland-ivi-extension provides ivi-controller.so to manage properties of surfaces/layers/screens and it also provides the ivi-input-controller.so to manage the input focus on a surface.

Applications must support the ivi-application protocol to be managed by the HMI central controller with an unique numeric ID.

Some important references to wayland-ivi-extension can be found at the following links:

• https://at.projects.genivi.org/wiki/display/WIE/01.+Quick+start
• https://at.projects.genivi.org/wiki/display/PROJ/Wayland+IVI+Extension+Design

target# weston-simple-shm &

target# layer-add-surfaces -l 1000 -s 2 &

layer-add-surfaces: surface (10507) created
layer-add-surfaces: surface (10507) configured with:
    dst region: x:0 y:0 w:250 h:250
    src region: x:0 y:0 w:250 h:250
    visibility: TRUE
    added to layer (1000)
layer-add-surfaces: surface (10507) configured with:
    dst region: x:0 y:0 w:250 h:250
    src region: x:0 y:0 w:250 h:250
    visibility: TRUE
    added to layer (1000)

target# weston-flower &

target# LayerManagerControl set surface 10507 destination region 150 150 300 300
target# LayerManagerControl set surface 10507 opacity 0.5
target# LayerManagerControl set surface 10507 visibility 1

target# LayerManagerControl  help

3.9.5.1. PVRTune¶

The PVRTune utility is a real-time GPU performance analysis tool. It captures hardware timing data and counters which facilitate the identification of performance bottlenecks. PVRPerfServerDeveloper should be used along with the PVRTune running on the PC to gather data on the SGX loading and activity threads. You can invoke the tool with the below command:

target # /opt/img-powervr-sdk/PVRHub/PVRPerfServer/PVRPerfServerDeveloper

3.9.5.2. PVRTrace¶

The PVRTrace is an OpenGL ES API recording and analysis utility. PVRTrace GUI provides off-line tools to inspect captured data, identify redundant calls, highlight costly shaders and many more. The default filesystem contains helper scripts to obtain the PVRTrace of the graphics application. This trace can then be played back on the PC using the PVRTrace Utility.

To start tracing, use the below commands as reference:

target # cp /opt/img-powervr-sdk/PVRHub/Scripts/start_tracing.sh ~/.
target # ./start_tracing.sh <log-filename> <application-to-be-traced>

Example:

target # ./start_tracing.sh westonapp weston-simple-egl

The above command will do the following:

1. Setup the required environment for the tracing
2. Create a directory under the current working directory called pvrtrace
3. Launch the application specified by the user
4. Start tracing the PVR Interactions and record the same to the log-filename

To end the tracing, user can invoke the Ctrl-C and the trace file path will be displayed.

The trace file can then be transferred to a PC and we can visualize the application using the host side PVRTrace utility. Please refer to the link at the beginning of this section for more details.

3.9.9.1. from Processor SDK 1.x to 2.x for AM3, AM4¶

The SGX driver has been enhanced to support DRM based Full Window Display in processor SDK 2.0 and the FBdev based Full Window modes are no longer supported. The System startup and most of the Graphics applications are backward-compatible except with the following changes.

Window System Libraries

The FBdev based Full Screen window systems are no longer supported:

• libpvrPVR2D_FRONTWSEGL.so (for direct writes to FrameBuffer - FRONT mode of operation - directly writes to FrameBuffer without waiting for vsync - fastest mode of operation)
• libpvrPVR2D_FLIPWSEGL.so (for VSync synchronised writes to Framebuffer - slower, but avoids tearing)
• libpvrPVR2D_BLITWSEGL.so (for direct writes to back-buffer, which later gets written to *FrameBuffer with sync)

Instead the DRM based Full Screen window system are provided:

• libpvrDRMWSEGL_FRONT.so (for direct writes to DRM FrameBuffer - FRONT mode of operation - directly writes to FrameBuffer without waiting for vsync - fastest mode of operation)
• libpvrDRMWSEGL.so (for VSync synchronised writes to DRM Framebuffer - slower, but avoids tearing)

The window system is specified by the PVR configuration parameter WindowSystem at the PVR configuration file /etc/powervr.ini. By default, that parameter is set to libpvrDRMWSEGL_FRONT.so for nullDRM Front mode. To configure the PVR SGX to operate in nullDRM FLIP mode, edit the PVR configuration file to set the parameter WindowSystem to libpvrDRMWSEGL.so. The change will take effect when any graphic application is launched next time.

Obsolete Test Programs

The following test programs are no longer applicable and removed from the SDK file system

• /usr/bin/sgx_blit_test
• /usr/bin/sgx_flip_test
• /usr/bin/sgx_render_flip_test
• /usr/bin/sgx_render_test

3.9.9.2. from Processor SDK 2.0.0 to 2.0.x for AM4¶

The SGX driver has been enhanced to support DRM/WAYLAND based Multi-Window Display in processor SDK 2.0.1. The System startup and most of the Graphics applications are backward-compatible except with the following changes.

Window System Libraries

The DRM based Full Screen window systems are no longer supported:

• libpvrDRMWSEGL_FRONT.so (for direct writes to DRM FrameBuffer - FRONT mode of operation - directly writes to FrameBuffer without waiting for vsync - fastest mode of operation)
• libpvrDRMWSEGL.so (for VSync synchronised writes to DRM Framebuffer - slower, but avoids tearing)

Instead the DRM/WAYLAND based multi-window system are provided:

• libpvrws_KMS.so
• libpvrws_WAYLAND.so

The window system will be dynamically loaded by DDK based on the application use case, so that the PVR configuration parameter WindowSystem at the PVR configuration file /etc/powervr.ini is no longer used.

3.9.9.3. from Processor SDK 2.0.1 to 2.0.x for AM3/4/5¶

The SGX driver has been enhanced to support DRM-based Full Screen(NullDRM) and Multi-Window(Wayland) Display in processor SDK 2.0.2. The System startup and most of the Graphics applications are backward-compatible except with the following changes.

Window System Libraries

The DRM based Full Screen window system is supported:

• libpvrDRMWSEGL.so (for VSync synchronised writes to DRM Framebuffer - slower, but avoids tearing)

The DRM/WAYLAND based multi-window systems are also provided:

• libpvrGBMWSEGL.so
• libpvrws_WAYLAND.so

The window system will be dynamically loaded by DDK based on the application use case, so that the PVR configuration parameter WindowSystem at the PVR configuration file /etc/powervr.ini is no longer required.

3.9.9.4. from Processor SDK 3.1 to 3.x for AM3/4/5¶

The QT QPA eglfs_kms, which supports multiple screens, has been enabled and used as the default eglfs platform plugin in processor SDK 3.2. To fallback to the standard single-screen eglfs plugin, issue the following instruction at the command line or add the same at the QT environment configuration file qt_env.sh at /etc/profile.d

• export QT_QPA_EGLFS_INTEGRATION=none

3.9.11.1. Introduction¶

The SOC Performance monitoring tools are a set of tools that are included in the default filesystem that allow the user to visualize various SOC parameters real-time on the screen. Currently, there are two tools and a suite of scripts and utilities to use them.

1. soc-performance-monitor
2. soc-ddr-bw-visualize

Both these applications are Wayland applications and need to be invoked after running Weston.

These tools bring in the capability to visualize the following:

1. DDR BW Utilization #. Overall DDR BW Usage #. Split of the traffic between the two EMIF’s #. A real time “top” like functionality that depicts the list of “Top 6” initiators generating the traffic.
2. Voltage of the various rails
3. Frequency of the various cores
4. Temperature (read from on die temperature sensors)
5. CPU Load information of the various processor cores including the GPU and DSP.
6. Boot time results (requires rebuild of u-boot and kernel), refer instructions below.
7. Power plot (Will be available soon. Note that this requires board modification on the EVM)

3.9.11.2. Getting started¶

• Prepare the card with PLSDK 3.0.0 or later.
• Boot up
• Start weston

target #  /etc/init.d/weston start

• Copy the required scripts into a temporary folder (this is to allow you to experiment with the settings later)

target # mkdir temp
target # cd temp
target # cp /etc/glsdkstatcoll/* .
target # cp /etc/visualization_scripts/* .

• You should see the following file in the directory after the above operation.

target # ls -al
drwxr-xr-x    2 root     root          4096 Mar 22 18:01 .
drwxr-xr-x    3 root     root          4096 Mar 22 18:01 ..
-rw-r--r--    1 root     root           114 Mar 22 18:01 config.ini
-rw-r--r--    1 root     root           265 Mar 22 18:01 dummy_boot_time_results.sh
-rw-r--r--    1 root     root           419 Mar 22 18:01 dummy_cpu_load.sh
-rw-r--r--    1 root     root           899 Mar 22 18:01 getFrequency.sh
-rw-r--r--    1 root     root          2293 Mar 22 18:01 getTemp.sh
-rw-r--r--    1 root     root           371 Mar 22 18:01 getVoltage.sh
-rw-r--r--    1 root     root           254 Mar 22 18:01 initiators.cfg
-rw-r--r--    1 root     root           143 Mar 22 18:01 list-boot-times.sh
-rw-r--r--    1 root     root           367 Mar 22 18:01 send_boot_times_to_monitor.sh
-rw-r--r--    1 root     root           496 Mar 22 18:01 soc_performance_monitor.cfg
-rw-r--r--    1 root     root           133 Mar 22 18:01 start_visualization_test.sh

• Running the soc-performance-monitor, this tool has two pre-requisites.

1. The name of the fifo configured in the file soc_performance_monitor.cfg needs to be created
2. The file soc_performance_monitor.cfg should be present in the current directory. This should be done in the above steps.

• Creating the fifo (mentioned in the soc_performance_monitor.cfg)

target # mkfifo /tmp/socfifo

• Run the tool for various performance metrics

target # soc-performance-monitor &

• Run the tool for DDR BW Visualization

target # mkfifo /tmp/statcollfifo
target # soc-ddr-bw-visualizer &

The following sections will talk about the how to populate the data into tools and further controls that are possible.

3.9.11.3. Quick guide to available plugins¶

Plugins are the entities (scripts/native binaries) that can be used to send commands to the SOC Performance Monitoring tools.

The main intent of this is to separate the visualization engine from the data collection part and allow full configuration of the application.

When the application (soc-performance-monitor) is invoked, it starts up with the default data which is set to zero. To populate the real values, the user can use the scripts provided in the prebuilt filesystem.

target # sh getTemp.sh

target # sh getVoltage.sh

target # sh getFrequency.sh

target # mpuload FIFO

Example usage:

target # mpuload /tmp/socfifo 1000 &

target # pvrscope <option> <time_seconds>

options:
          -f    write into the FIFO (/tmp/socfifo)
          -c    output to console

time:
          1-n   specified in seconds
          0     run forever

target # dsptop –r <update_freq> –f fifo –o /tmp/socfifo –d <update_freq> -n <# of updates>

Example usage:

target # dsptop –r 1 –f fifo –o /tmp/socfifo –d 1 –n 100  &

3.9.11.4. Order of execution¶

The performance visualization tools have to be executed in the following order.

• Launch weston
• Create required FIFOs
• Configure the .cfg file to suit the required settings
• Run the soc-performance-monitor and/or soc-ddr-bw-visualizer
• Run the plugins to populate data

3.9.11.5. Config file format¶

The config file has the following format. There are 3 different kinds of sections that can be defined, please refer to the particular section for more details.

The generic format is:

[SECTION_NAME]
VALUE_1
VALUE_2
..
..
VALUE_N
SPECIAL VALUE
<blank line>

Types of sections

1. GLOBAL
2. TABLE
3. BAR GRAPH

[GLOBAL]
KEY_1=VALUE_1
KEY_2=VALUE_2
..
..
KEY_n=VALUE_n
<blank>

[TABLE_NAME]
 VALUE_1
 VALUE_2
 ..
 ..
 VALUE_N
TITLE="TABLE TITLE",UNIT="unit to be displayed"
<blank line>

[GRAPH_NAME]
 VALUE_1
 VALUE_2
 ..
 ..
 VALUE_N
 TITLE OF THE GRAPH
 <blank line>

3.9.11.6. Commands¶

The FIFO can be used to communicate with the soc-performance-monitor application and pass data from the command line or from other applications. There are a few commands that have been implemented to aid in modifying the running application via the FIFO.

The commands in general have the following format:

"INSTRUCTION: DATA_1 ... DATA_N"

and they can be sent to the soc-performance-monitor by simply doing an echo:

echo "INSTRUCTION: DATA_1 ... DATA_N" > FIFO

The currently supported list of supported commands are:

1. TABLE
2. CPULOAD

NOTE: To execute a sequence of commands in a sequence, it is advised that a delay of REFRESH_TIME_USECS be inserted between two commands.

"TABLE: ROW_NAME value unit"

echo "TABLE: FREQ_MPU 1500 MHz" > /tmp/socfifo

"CPULOAD: CORE_NAME value" > FIFO

 CORE_NAME has to be one of the names specified in the soc_performance_monitor.cfg.
 value is in the range 0 to 100

echo "CPULOAD: GPU 87" > /tmp/socfifo

3.9.11.7. Executing in debug mode¶

To launch the application in debug mode for very verbose data on the internal working of the tool, launch the tool with the following option:

# soc-performance-monitor 1

3.9.11.8. Build instructions¶

The full source of the tool is available and the required recipes have been updated as part of the recipes and upstreamed to meta-arago.

Essentially, if the user builds the Yocto filesystem as documented in the SDG, the tool will get recompiled as part of it.

3.9.11.9. Configuration of the soc-ddr-bw-visualizer¶

There are two levels of configuration that the tool allows:

• The total time that the tool runs is configured using config.ini.
• To allow finer granularity of control to choose the initiators of interest, the user will have to modify the initiators.cfg.

The tool will have to relaunched for the new settings to take effect.