Wiki-DB - User contributions [en]

XLON

2021-11-10T07:36:52Z

Fgerstandl: /* XLON Configuration */

__NOTOC__
{| style="width: 100%; color: #000000; border-spacing: 2px; border: 1px solid darkgray;" valign="top" |
| style="width: 25%; text-align: center;" |
| style="width: 50%; text-align: center;" |
| style="width: 25%; text-align: center;" |
|-
|
| style="text-align: center;" | [[Image:XLON Logo in Schwarz von SD Kopie.jpg|400px|XLON]]
| style="text-align: center;" | [[Image:LOGO_DH_electronics.jpg|180px|DH electronics]]
|}

{| style="width: 100%; color: #000000;" valign="top" |
| style="width: 50%;" |
| style="width: 50%;" |
|-
|valign="top"|

== XLON products ==
{|
|
|
|-
|[[Image:XLON U10.png|100px|XLON U10|link=]]
|
*'''[[XLON U10]]'''
|}
|valign="top"|
|
|}

== Hardware Development ==

== Software Development ==
=== XLON Configuration ===
The XLON Uxx LonWorks interfaces come with two different flavours of configuration:
# Vendor mode - does not appear as a serial port in the system.
# CDC/ACM mode - appears as a (virtual) serial port in the system.
This configuration can be replaced by using the xlon-util tool.

 
 

=== XLON Tools ===
With the following links you can download the xlon-util for different architectures:
* [[media:AAAu48iSX_j4TVGTrvtwGuqja|xlon-util packages]]
: The xlon-util packages containes the xlon-util to configure the xlon-u10. It also contains the xlon-api libs to integrate the xlon-util functionality into a custom application.
* [[media:AAA8eq-wtunWfVFSOihXnh57a|dependency packages]]
: The dependency packages contains libraries which are not in the debian repositories.
* [[media:AADI1WNNbNVhxeswBt43cWKMa|development packages]]
: The development packages contains the api header files to compile a custom application with the xlon-api libs.
 
 

=== Windows Drivers ===
Drivers for various 32- and 64-Bit versions of Windows operating system:
{| class="wikitable"
|+Vendor mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86.zip|XLON-2G-Win7-x86.zip]]
|[[media:XLON-2G-Win7-x64.zip|XLON-2G-Win7-x64.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86.zip|XLON-2G-Win8-x86.zip]]
|[[media:XLON-2G-Win8-x64.zip|XLON-2G-Win8-x64.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86.zip|XLON-2G-Win8.1-x86.zip]]
|[[media:XLON-2G-Win8.1-x64.zip|XLON-2G-Win8.1-x64.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86.zip|XLON-2G-Win10-x86.zip]]
|[[media:XLON-2G-Win10-x64.zip|XLON-2G-Win10-x64.zip]]
|}

{| class="wikitable"
|+CDC/ACM mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86-cdc-acm.zip|XLON-2G-Win7-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win7-x64-cdc-acm.zip|XLON-2G-Win7-x64-cdc-acm.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86-cdc-acm.zip|XLON-2G-Win8-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8-x64-cdc-acm.zip|XLON-2G-Win8-x64-cdc-acm.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86-cdc-acm.zip|XLON-2G-Win8.1-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8.1-x64-cdc-acm.zip|XLON-2G-Win8.1-x64-cdc-acm.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86-cdc-acm.zip|XLON-2G-Win10-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win10-x64-cdc-acm.zip|XLON-2G-Win10-x64-cdc-acm.zip]]
|}

'''Important''': If you experience an error about missing 'Microsoft Visual C 2010 redistributable' when starting xlon_util.exe,
please download it from the [https://www.microsoft.com/de-de/download/details.aspx?id=5555 Microsoft site].

== [[FAQ_General |FAQ]] ==

== Series Manufacturing ==

XLON

2021-11-10T07:31:01Z

Fgerstandl: /* Software Development */

__NOTOC__
{| style="width: 100%; color: #000000; border-spacing: 2px; border: 1px solid darkgray;" valign="top" |
| style="width: 25%; text-align: center;" |
| style="width: 50%; text-align: center;" |
| style="width: 25%; text-align: center;" |
|-
|
| style="text-align: center;" | [[Image:XLON Logo in Schwarz von SD Kopie.jpg|400px|XLON]]
| style="text-align: center;" | [[Image:LOGO_DH_electronics.jpg|180px|DH electronics]]
|}

{| style="width: 100%; color: #000000;" valign="top" |
| style="width: 50%;" |
| style="width: 50%;" |
|-
|valign="top"|

== XLON products ==
{|
|
|
|-
|[[Image:XLON U10.png|100px|XLON U10|link=]]
|
*'''[[XLON U10]]'''
|}
|valign="top"|
|
|}

== Hardware Development ==

== Software Development ==
=== XLON Configuration ===
The XLON Uxx LonWorks interfaces come with two different flavours of configuration:
# Vendor mode - does not appear as a serial port in the system.
# CDC/ACM mode - appears as a (virtual) serial port in the system.
 
ACM/CDC and Vendor configs for all xlon products can be downloaded here:
[[media:AAD_rGoV8YpnxMh9SWqAsT4Xa|xlon-util config]]
 
 
This configuration can be replaced by using the xlon-util tool. For example to update the config on the first device execute the following command:
 
<code>
xlon-util -d0 -c<pathToConfig>
</code> 

 
 

=== XLON Tools ===
With the following links you can download the xlon-util for different architectures:
* [[media:AAAu48iSX_j4TVGTrvtwGuqja|xlon-util packages]]
: The xlon-util packages containes the xlon-util to configure the xlon-u10. It also contains the xlon-api libs to integrate the xlon-util functionality into a custom application.
* [[media:AAA8eq-wtunWfVFSOihXnh57a|dependency packages]]
: The dependency packages contains libraries which are not in the debian repositories.
* [[media:AADI1WNNbNVhxeswBt43cWKMa|development packages]]
: The development packages contains the api header files to compile a custom application with the xlon-api libs.
 
 

=== Windows Drivers ===
Drivers for various 32- and 64-Bit versions of Windows operating system:
{| class="wikitable"
|+Vendor mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86.zip|XLON-2G-Win7-x86.zip]]
|[[media:XLON-2G-Win7-x64.zip|XLON-2G-Win7-x64.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86.zip|XLON-2G-Win8-x86.zip]]
|[[media:XLON-2G-Win8-x64.zip|XLON-2G-Win8-x64.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86.zip|XLON-2G-Win8.1-x86.zip]]
|[[media:XLON-2G-Win8.1-x64.zip|XLON-2G-Win8.1-x64.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86.zip|XLON-2G-Win10-x86.zip]]
|[[media:XLON-2G-Win10-x64.zip|XLON-2G-Win10-x64.zip]]
|}

{| class="wikitable"
|+CDC/ACM mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86-cdc-acm.zip|XLON-2G-Win7-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win7-x64-cdc-acm.zip|XLON-2G-Win7-x64-cdc-acm.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86-cdc-acm.zip|XLON-2G-Win8-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8-x64-cdc-acm.zip|XLON-2G-Win8-x64-cdc-acm.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86-cdc-acm.zip|XLON-2G-Win8.1-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8.1-x64-cdc-acm.zip|XLON-2G-Win8.1-x64-cdc-acm.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86-cdc-acm.zip|XLON-2G-Win10-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win10-x64-cdc-acm.zip|XLON-2G-Win10-x64-cdc-acm.zip]]
|}

'''Important''': If you experience an error about missing 'Microsoft Visual C 2010 redistributable' when starting xlon_util.exe,
please download it from the [https://www.microsoft.com/de-de/download/details.aspx?id=5555 Microsoft site].

== [[FAQ_General |FAQ]] ==

== Series Manufacturing ==

XLON

2021-11-10T07:28:17Z

Fgerstandl: /* Software Development */

__NOTOC__
{| style="width: 100%; color: #000000; border-spacing: 2px; border: 1px solid darkgray;" valign="top" |
| style="width: 25%; text-align: center;" |
| style="width: 50%; text-align: center;" |
| style="width: 25%; text-align: center;" |
|-
|
| style="text-align: center;" | [[Image:XLON Logo in Schwarz von SD Kopie.jpg|400px|XLON]]
| style="text-align: center;" | [[Image:LOGO_DH_electronics.jpg|180px|DH electronics]]
|}

{| style="width: 100%; color: #000000;" valign="top" |
| style="width: 50%;" |
| style="width: 50%;" |
|-
|valign="top"|

== XLON products ==
{|
|
|
|-
|[[Image:XLON U10.png|100px|XLON U10|link=]]
|
*'''[[XLON U10]]'''
|}
|valign="top"|
|
|}

== Hardware Development ==

== Software Development ==
The XLON Uxx LonWorks interfaces come with two different flavours of configuration:
# Vendor mode - does not appear as a serial port in the system.
# CDC/ACM mode - appears as a (virtual) serial port in the system.
 
ACM/CDC and Vendor configs for all xlon products can be downloaded here:
[[media:AAD_rGoV8YpnxMh9SWqAsT4Xa|xlon-util config]]
 
 
This configuration can be replaced by using the xlon-util tool. For example to update the config on the first device execute the following command:
 
<code>
xlon-util -d0 -c<pathToConfig>
</code> 

 
 

=== XLON Tools ===
With the following links you can download the xlon-util for different architectures:
* [[media:AAAu48iSX_j4TVGTrvtwGuqja|xlon-util packages]]
: The xlon-util packages containes the xlon-util to configure the xlon-u10. It also contains the xlon-api libs to integrate the xlon-util functionality into a custom application.
* [[media:AAA8eq-wtunWfVFSOihXnh57a|dependency packages]]
: The dependency packages contains libraries which are not in the debian repositories.
* [[media:AADI1WNNbNVhxeswBt43cWKMa|development packages]]
: The development packages contains the api header files to compile a custom application with the xlon-api libs.
 
 

=== Windows Drivers ===
Drivers for various 32- and 64-Bit versions of Windows operating system:
{| class="wikitable"
|+Vendor mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86.zip|XLON-2G-Win7-x86.zip]]
|[[media:XLON-2G-Win7-x64.zip|XLON-2G-Win7-x64.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86.zip|XLON-2G-Win8-x86.zip]]
|[[media:XLON-2G-Win8-x64.zip|XLON-2G-Win8-x64.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86.zip|XLON-2G-Win8.1-x86.zip]]
|[[media:XLON-2G-Win8.1-x64.zip|XLON-2G-Win8.1-x64.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86.zip|XLON-2G-Win10-x86.zip]]
|[[media:XLON-2G-Win10-x64.zip|XLON-2G-Win10-x64.zip]]
|}

{| class="wikitable"
|+CDC/ACM mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86-cdc-acm.zip|XLON-2G-Win7-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win7-x64-cdc-acm.zip|XLON-2G-Win7-x64-cdc-acm.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86-cdc-acm.zip|XLON-2G-Win8-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8-x64-cdc-acm.zip|XLON-2G-Win8-x64-cdc-acm.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86-cdc-acm.zip|XLON-2G-Win8.1-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8.1-x64-cdc-acm.zip|XLON-2G-Win8.1-x64-cdc-acm.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86-cdc-acm.zip|XLON-2G-Win10-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win10-x64-cdc-acm.zip|XLON-2G-Win10-x64-cdc-acm.zip]]
|}

'''Important''': If you experience an error about missing 'Microsoft Visual C 2010 redistributable' when starting xlon_util.exe,
please download it from the [https://www.microsoft.com/de-de/download/details.aspx?id=5555 Microsoft site].

== [[FAQ_General |FAQ]] ==

== Series Manufacturing ==

DHCOM STM32MP1 Linux

2021-09-15T07:26:46Z

Fgerstandl: /* How is the Webbrowser Perfomance on the STM32MP1? */

== Linux virtual machine for development ==
:* Please have a look at: '''[[Virtual Machine for Application Development]]'''

== Linux Kernel ==



=== How to build a Kernel ===
{| class="wikitable" align="center" | style="width: 98%; background: #f3f3f3;" valign="top" |
|
Get sources from Github
{| class="wikitable" style="width: 100%; color: #000000; background: #ffffff;" |
|
1. Start the Console on Linux 
2. <tt>''git clone https://github.com/dh-electronics/linux-stm32mp1.git --branch dev/5.4.69_dhsom''</tt> 
3. <tt>''cd linux-stm32mp1''</tt>
|}
Configure and build the Device Tree + Kernel
{| class="wikitable" style="width: 100%; color: #000000; background: #ffffff;" |
|
4. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make stm32mp1_dhsom_defconfig''</tt> 
5. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make menuconfig''</tt> (optional: If you want to add/remove Kernel features) 
6. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make dtbs''</tt> 
7. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make zImage</tt>
|}
Create the FIT-image with our script ([[media:Dh-create-fitimage_1.0_all.deb|Download link]])
{| class="wikitable" style="width: 100%; color: #000000; background: #ffffff;" |
|-
| '''Interactive mode for selecting device trees'''
| '''Device trees are set as parameter'''
|-
|
8. <tt>''create_fitimage''</tt> 
Enter the numbers (space seperated) of the device trees to include (e.g. if you want to include the device tree for the PDK2 include the number of <tt>''./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dtb''</tt> (usually 3). 
Enter the numbers (space seperated) of the device trees overlays to include (e.g. for the PDK2 enter the files which contain <tt>''PDK2''</tt> (usually 8 9 10 11 12 13 14).
|
(Example is for the PDK2) 
8. <tt>''create_fitimage --dtb ./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dtb --dtbo ./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-460-200-x11.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-497-200-x12.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-531-100-x21.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-531-100-x22.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-560-200-x12.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-638-100-x12-rpi7inch.dtbo''</tt>
|}
|}

== Kernel Userspace Interfaces to Access Hardware ==

=== RS-485 on picoITX ===
:'''RS-485 device'''
:{| class="wikitable" style="width: 400px"
||DHCOM UART 2||<tt>/dev/ttySTM2</tt>
|}

:'''Compilation on target'''
:{| class="wikitable"
|<tt>''gcc tty_rs485_test_v1.1.c -o tty_rs485_test''</tt>
|-
|<tt>''gcc tty_rs485_flags_v1.0.c -o tty_rs485_flags''</tt>
|}

:'''Show UART flags'''
:{| class="wikitable"
|<tt>''./tty_rs485_flags /dev/ttySTM2''</tt>
|}

:'''Set tty device to raw mode'''
:{| class="wikitable"
|<tt>''stty -F /dev/ttySTM2 115200 raw -echo -echoe''</tt>
|}

:'''Send data with demo program'''
:{| class="wikitable"
|<tt>''echo -n -e "\n\rHallo RS485 Welt!" ¦ ./tty_rs485_test /dev/ttySTM2''</tt>
|}

:'''Receive data with demo program'''
:{| class="wikitable"
|<tt>''./tty_rs485_test /dev/ttySTM2''</tt>
|}

:'''Download example source code'''
:* [[media:tty_rs485_test_v1.1.zip | tty_rs485_test_v1.1.c & tty_rs485_flags_v1.0.c]]

=== CAN interface ===
:'''Setup CAN interface with baudrate 500kbit/sec.'''
:{| class="wikitable"
|<tt>''ip link set can0 up type can bitrate 500000''</tt>
|}

:'''Start to listen on CAN port'''
:{| class="wikitable"
|<tt>''candump can0''</tt>
|}

:'''Send test message'''
:{| class="wikitable"
|<tt>''cansend can0 100#11.2233.44556677.88''</tt>
|}

:'''Deinitialize CAN port'''
:{| class="wikitable"
|<tt>''ip link set can0 down''</tt>
|}

=== UART Interfaces ===
:{| class="wikitable" style="width: 400px"
||DHCOM UART 1 ||<tt>/dev/ttySTM0</tt>
|-
||DHCOM UART 2 ||<tt>/dev/ttySTM2</tt>
|-
||DHCOM UART 3 ||<tt>/dev/ttySTM1</tt>
|}

=== I2C Interfaces ===
:{| class="wikitable" style="width: 400px"
||DHCOM I2C 1||<tt>/dev/i2c-1</tt>
|-
||DHCOM I2C 2 ||<tt>/dev/i2c-0</tt>
|-
||On Module Devices ||<tt>/dev/i2c-2</tt>
|}

== FAQ ==
==== '''USB 1.1 problems: Custom board without USB 2.0 hub inbetween the MP1 USB host port?''' ====
And in that case, have a look at arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi and how the OHCI (!) is enabled there. And of course, make sure the kernel config options are enabled accordingly (like for the PicoITX machine)

{| class="wikitable" | style="width: 100%; color: #000000; background: #FFFFFF;" valign="top" |
|
<tt>meta-dhsom-stm32-bsp$ git grep OHCI</tt>
|}

{| class="wikitable" | style="width: 100%; color: #000000; background: #FFFFFF;" valign="top" |
|
<tt>recipes-kernel/linux/linux-stable/5.10/dh-stm32mp1-common/dh-stm32mp1-dhsom-common.cfg:CONFIG_USB_OHCI_HCD=y</tt> 
<tt>recipes-kernel/linux/linux-stable/5.10/dh-stm32mp1-common/dh-stm32mp1-dhsom-common.cfg:CONFIG_USB_OHCI_HCD_PLATFORM=y</tt>
|}

arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi snippet:
&usbh_ehci {
phys = <&usbphyc_port0>;
status = "okay";
};

&usbh_ohci { // <---------------- HERE
phys = <&usbphyc_port0>;
status = "okay";
};

&usbotg_hs {
dr_mode = "otg";
pinctrl-0 = <&usbotg_hs_pins_a>;
pinctrl-names = "default";
phy-names = "usb2-phy";
phys = <&usbphyc_port1 0>;
vbus-supply = <&vbus_otg>;
status = "okay";
};

&usbphyc {
status = "okay";
};

&usbphyc_port0 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

&usbphyc_port1 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

==== '''System stability or USB Host problems?''' ====
If a display with higher resolution and pixel clock > 48 MHz is used, then this can case USB host and/or system stability problems.

Workaround:
The OSPEEDR must be set to OSPEEDR = 1 for LCD_CLK and OSPEEDR = 0 for all other LTDC signals.
&pinctrl {
ltdc_pins_ customhmi: ltdc-dh-1 {
pins1 {
pinmux = <STM32_PINMUX('I', 14, AF14)>; /* LCD_CLK */
bias-disable;
drive-push-pull;
'''slew-rate = <1>;'''
};
pins2 {
pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */
<STM32_PINMUX('I', 13, AF14)>, /* LCD_VSYNC */
...
<STM32_PINMUX('K', 6, AF14)>; /* LCD_B7 */
bias-disable;
drive-push-pull;
'''slew-rate = <0>;'''
};
};

ltdc_sleep_pins_ customhmi: ltdc-sleep-dh-1 {
pins {
pinmux = <STM32_PINMUX('I', 14, ANALOG)>, /* LCD_CLK */
...
<STM32_PINMUX('K', 6, ANALOG)>; /* LCD_B7 */
};
};
};
==== '''USB OTG: Custom board where the USB-OTG port is only used as host?''' ====

On the DHCOM standard, the second USB port of the STM32MP1 is usually an USB-OTG port. If you have a custom board where you want to use the USB-OTG port in host mode only, you should consider the following:

The USB-OTG controller on the STM32MP1, DWC2, does support host mode but is rather inefficient (in comparison to a dedicated USB host controller). The following block diagram shows, that it is possible on the STM32MP1 to alter the pinmuxing, so that the USB-OTG port is used with the USB Host controller of the STM32MP1 (instead of using the DWC2 OTG controller):

Host port#1: EHCI/OHCI controller _________ HS PHY port #1 (SoC balls D+/D- #1)

Host port#2: EHCI/OHCI controller __
\
|_____ HS PHY port #2 (SoC balls D+/D- #2)
DWC2 OTG controller_________________/|
|
UTIM switch__________________|

This change can be made in the device tree with disabling the DWC2 controller and adding the second usb_phyc port to the nodes of usbh_ehci and (if applicable) usbh_ohci. These nodes are usually in the .dtsi file of the board (e.g. for the PicoITX: arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi). Here a is snippet how this could look like:

&usbh_ehci {
phys = <&usbphyc_port0>''', <&usbphyc_port1 1>'''; // <-------- HERE
status = "okay";
};

&usbh_ohci {
phys = <&usbphyc_port0>''', <&usbphyc_port1 1>'''; // <-------- HERE
status = "okay";
};

&usbotg_hs {
'''status = "disabled";''' // <-------- HERE
};

&usbphyc {
status = "okay";
};

&usbphyc_port0 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

&usbphyc_port1 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

==== '''How to try QtWebengine''' ====
The QtWebengine is part of the DH default images.
Please stop the Weston desktop, before the start of the Browser.
Older images: "systemctl stop weston@root.service"
Newer images: "systemctl stop weston.service"
How to start the Browser:
QT_QPA_PLATFORM=eglfs QT_QPA_EGLFS_ALWAYS_SET_MODE=1 QT_QPA_EGLFS_KMS_CONFIG=/etc/default/qt5-eglfs-kms.json qtwebengine-minimal http://YOUR-TEST-PAGE/ --no-sandbox

==== '''How is the Browser Perfomance on the STM32MP1?''' ====
[https://wiki.dh-electronics.com/index.php/STM32MP1_Browser_Performance STM32MP1 Browser Performance]

DHCOM STM32MP1 Linux

2021-09-15T07:23:16Z

Fgerstandl: /* FAQ */

== Linux virtual machine for development ==
:* Please have a look at: '''[[Virtual Machine for Application Development]]'''

== Linux Kernel ==



=== How to build a Kernel ===
{| class="wikitable" align="center" | style="width: 98%; background: #f3f3f3;" valign="top" |
|
Get sources from Github
{| class="wikitable" style="width: 100%; color: #000000; background: #ffffff;" |
|
1. Start the Console on Linux 
2. <tt>''git clone https://github.com/dh-electronics/linux-stm32mp1.git --branch dev/5.4.69_dhsom''</tt> 
3. <tt>''cd linux-stm32mp1''</tt>
|}
Configure and build the Device Tree + Kernel
{| class="wikitable" style="width: 100%; color: #000000; background: #ffffff;" |
|
4. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make stm32mp1_dhsom_defconfig''</tt> 
5. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make menuconfig''</tt> (optional: If you want to add/remove Kernel features) 
6. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make dtbs''</tt> 
7. <tt>''ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make zImage</tt>
|}
Create the FIT-image with our script ([[media:Dh-create-fitimage_1.0_all.deb|Download link]])
{| class="wikitable" style="width: 100%; color: #000000; background: #ffffff;" |
|-
| '''Interactive mode for selecting device trees'''
| '''Device trees are set as parameter'''
|-
|
8. <tt>''create_fitimage''</tt> 
Enter the numbers (space seperated) of the device trees to include (e.g. if you want to include the device tree for the PDK2 include the number of <tt>''./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dtb''</tt> (usually 3). 
Enter the numbers (space seperated) of the device trees overlays to include (e.g. for the PDK2 enter the files which contain <tt>''PDK2''</tt> (usually 8 9 10 11 12 13 14).
|
(Example is for the PDK2) 
8. <tt>''create_fitimage --dtb ./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dtb --dtbo ./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-460-200-x11.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-497-200-x12.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-531-100-x21.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-531-100-x22.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-560-200-x12.dtbo,./arch/arm/boot/dts/stm32mp157c-dhcom-pdk2-overlay-638-100-x12-rpi7inch.dtbo''</tt>
|}
|}

== Kernel Userspace Interfaces to Access Hardware ==

=== RS-485 on picoITX ===
:'''RS-485 device'''
:{| class="wikitable" style="width: 400px"
||DHCOM UART 2||<tt>/dev/ttySTM2</tt>
|}

:'''Compilation on target'''
:{| class="wikitable"
|<tt>''gcc tty_rs485_test_v1.1.c -o tty_rs485_test''</tt>
|-
|<tt>''gcc tty_rs485_flags_v1.0.c -o tty_rs485_flags''</tt>
|}

:'''Show UART flags'''
:{| class="wikitable"
|<tt>''./tty_rs485_flags /dev/ttySTM2''</tt>
|}

:'''Set tty device to raw mode'''
:{| class="wikitable"
|<tt>''stty -F /dev/ttySTM2 115200 raw -echo -echoe''</tt>
|}

:'''Send data with demo program'''
:{| class="wikitable"
|<tt>''echo -n -e "\n\rHallo RS485 Welt!" ¦ ./tty_rs485_test /dev/ttySTM2''</tt>
|}

:'''Receive data with demo program'''
:{| class="wikitable"
|<tt>''./tty_rs485_test /dev/ttySTM2''</tt>
|}

:'''Download example source code'''
:* [[media:tty_rs485_test_v1.1.zip | tty_rs485_test_v1.1.c & tty_rs485_flags_v1.0.c]]

=== CAN interface ===
:'''Setup CAN interface with baudrate 500kbit/sec.'''
:{| class="wikitable"
|<tt>''ip link set can0 up type can bitrate 500000''</tt>
|}

:'''Start to listen on CAN port'''
:{| class="wikitable"
|<tt>''candump can0''</tt>
|}

:'''Send test message'''
:{| class="wikitable"
|<tt>''cansend can0 100#11.2233.44556677.88''</tt>
|}

:'''Deinitialize CAN port'''
:{| class="wikitable"
|<tt>''ip link set can0 down''</tt>
|}

=== UART Interfaces ===
:{| class="wikitable" style="width: 400px"
||DHCOM UART 1 ||<tt>/dev/ttySTM0</tt>
|-
||DHCOM UART 2 ||<tt>/dev/ttySTM2</tt>
|-
||DHCOM UART 3 ||<tt>/dev/ttySTM1</tt>
|}

=== I2C Interfaces ===
:{| class="wikitable" style="width: 400px"
||DHCOM I2C 1||<tt>/dev/i2c-1</tt>
|-
||DHCOM I2C 2 ||<tt>/dev/i2c-0</tt>
|-
||On Module Devices ||<tt>/dev/i2c-2</tt>
|}

== FAQ ==
==== '''USB 1.1 problems: Custom board without USB 2.0 hub inbetween the MP1 USB host port?''' ====
And in that case, have a look at arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi and how the OHCI (!) is enabled there. And of course, make sure the kernel config options are enabled accordingly (like for the PicoITX machine)

{| class="wikitable" | style="width: 100%; color: #000000; background: #FFFFFF;" valign="top" |
|
<tt>meta-dhsom-stm32-bsp$ git grep OHCI</tt>
|}

{| class="wikitable" | style="width: 100%; color: #000000; background: #FFFFFF;" valign="top" |
|
<tt>recipes-kernel/linux/linux-stable/5.10/dh-stm32mp1-common/dh-stm32mp1-dhsom-common.cfg:CONFIG_USB_OHCI_HCD=y</tt> 
<tt>recipes-kernel/linux/linux-stable/5.10/dh-stm32mp1-common/dh-stm32mp1-dhsom-common.cfg:CONFIG_USB_OHCI_HCD_PLATFORM=y</tt>
|}

arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi snippet:
&usbh_ehci {
phys = <&usbphyc_port0>;
status = "okay";
};

&usbh_ohci { // <---------------- HERE
phys = <&usbphyc_port0>;
status = "okay";
};

&usbotg_hs {
dr_mode = "otg";
pinctrl-0 = <&usbotg_hs_pins_a>;
pinctrl-names = "default";
phy-names = "usb2-phy";
phys = <&usbphyc_port1 0>;
vbus-supply = <&vbus_otg>;
status = "okay";
};

&usbphyc {
status = "okay";
};

&usbphyc_port0 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

&usbphyc_port1 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

==== '''System stability or USB Host problems?''' ====
If a display with higher resolution and pixel clock > 48 MHz is used, then this can case USB host and/or system stability problems.

Workaround:
The OSPEEDR must be set to OSPEEDR = 1 for LCD_CLK and OSPEEDR = 0 for all other LTDC signals.
&pinctrl {
ltdc_pins_ customhmi: ltdc-dh-1 {
pins1 {
pinmux = <STM32_PINMUX('I', 14, AF14)>; /* LCD_CLK */
bias-disable;
drive-push-pull;
'''slew-rate = <1>;'''
};
pins2 {
pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */
<STM32_PINMUX('I', 13, AF14)>, /* LCD_VSYNC */
...
<STM32_PINMUX('K', 6, AF14)>; /* LCD_B7 */
bias-disable;
drive-push-pull;
'''slew-rate = <0>;'''
};
};

ltdc_sleep_pins_ customhmi: ltdc-sleep-dh-1 {
pins {
pinmux = <STM32_PINMUX('I', 14, ANALOG)>, /* LCD_CLK */
...
<STM32_PINMUX('K', 6, ANALOG)>; /* LCD_B7 */
};
};
};
==== '''USB OTG: Custom board where the USB-OTG port is only used as host?''' ====

On the DHCOM standard, the second USB port of the STM32MP1 is usually an USB-OTG port. If you have a custom board where you want to use the USB-OTG port in host mode only, you should consider the following:

The USB-OTG controller on the STM32MP1, DWC2, does support host mode but is rather inefficient (in comparison to a dedicated USB host controller). The following block diagram shows, that it is possible on the STM32MP1 to alter the pinmuxing, so that the USB-OTG port is used with the USB Host controller of the STM32MP1 (instead of using the DWC2 OTG controller):

Host port#1: EHCI/OHCI controller _________ HS PHY port #1 (SoC balls D+/D- #1)

Host port#2: EHCI/OHCI controller __
\
|_____ HS PHY port #2 (SoC balls D+/D- #2)
DWC2 OTG controller_________________/|
|
UTIM switch__________________|

This change can be made in the device tree with disabling the DWC2 controller and adding the second usb_phyc port to the nodes of usbh_ehci and (if applicable) usbh_ohci. These nodes are usually in the .dtsi file of the board (e.g. for the PicoITX: arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi). Here a is snippet how this could look like:

&usbh_ehci {
phys = <&usbphyc_port0>''', <&usbphyc_port1 1>'''; // <-------- HERE
status = "okay";
};

&usbh_ohci {
phys = <&usbphyc_port0>''', <&usbphyc_port1 1>'''; // <-------- HERE
status = "okay";
};

&usbotg_hs {
'''status = "disabled";''' // <-------- HERE
};

&usbphyc {
status = "okay";
};

&usbphyc_port0 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

&usbphyc_port1 {
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
};

==== '''How to try QtWebengine''' ====
The QtWebengine is part of the DH default images.
Please stop the Weston desktop, before the start of the Browser.
Older images: "systemctl stop weston@root.service"
Newer images: "systemctl stop weston.service"
How to start the Browser:
QT_QPA_PLATFORM=eglfs QT_QPA_EGLFS_ALWAYS_SET_MODE=1 QT_QPA_EGLFS_KMS_CONFIG=/etc/default/qt5-eglfs-kms.json qtwebengine-minimal http://YOUR-TEST-PAGE/ --no-sandbox

==== '''How is the Webbrowser Perfomance on the STM32MP1?''' ====
[https://wiki.dh-electronics.com/index.php/STM32MP1_Browser_Performance STM32MP1 Browser Performance]

Avenger96

2021-09-15T07:21:24Z

Fgerstandl: /* DH Mainline based Linux */

'''The Avenger96 board is the official DHCOR STM32MP1 reference design!'''

{|
|
|
|-
|__TOC__
|[[Image:Avenger96Board.png|600px|COM Avenger96Board]]
|}

== Introduction ==
The AVENGER Board is a 96Boards compliant consumer edition board based on the STM32MP15 series of SoCs. The STM32MP15 series
is a highly integrated multi-market applications processor designed to enable secure and portable applications within the Internet of Things.
AVENGER board features Dual-core Arm® Cortex®-A7 processors operating at up to 650 MHz, Single core Arm® Cortex® M4 operating up to
209 MHz. In addition, an extensive set of interfaces and connectivity peripherals are included to interface to cameras, touch-screen displays,
MMC/SD cards and media processor engine. It also fully supports wireless communication, including WLAN and BLE.

== Technical Details ==
{| class="wikitable" align="center" | style="width: 100%; color: #000000; background: #f3f3f3;" valign="top" |
|-
| style="width: 50%; background: #076b8d; border: 0pt;" |
| style="width: 50%; background: #076b8d; border: 0pt;" |
|-
|valign="top" style="border: 0pt;" |
* '''STM32MP157AAC
**2x ARM® Cortex-A7 up to 650 MHz
**1x ARM® Cortex-M4 up to 209 MHz
'''
*'''GPU''' 1x 3D GPU Vivante® @ 533 MHz - OpenGL® ES 2.0
*'''PMIC''' STPMIC1A
*'''DDR3 DRAM''' 1024 Mbyte @ 533 MHz
*'''eMMC Flash''' 8 Gbyte, v4.51 interface
*'''NOR Flash''' 2 Mbyte, Quad SPI interface
*'''EEPROM''' 128 byte
*'''microSD Socket''' UHS-I speed grade, v3.01
*'''USB Host''' 2x type A, 2.0 high-speed
*'''USB OTG''' 1x type micro-AB, 2.0 high-speed
*'''HDMI''' WXGA (1366x768) @ 60 fps, HDMI 1.4
*'''WiFi / Bluetooth'''
**WiFi 5 GHz & 2.4GHz IEEE 802.11a / b / g / n / ac
**Bluetooth® v4.2 (BR/EDR/BLE)
**PCB antenna
*'''Ethernet''' 10 / 100 / 1000 Mbit/s, IEEE 802.3-compliant
|valign="top" style="border: 0pt;" |
*'''Push-Buttons''' Power and reset
*'''Battery Socket''' CR1216, CR1220 and CR1225
*'''LEDs'''
**4x green user controlled LEDs
**1x blue Bluetooth enabled
**1x yellow WiFi enabled
**1x red power supply okay
*'''Boot Mode''' 3 bit boot mode switch
*'''Debug Interface''' JTAG interface via tag-connect
*'''Supply (SYS_DCIN)''' 8 - 18 VDC
*'''Temperature Range''' 0 - 40 °C
*'''Dimensions ''' 100 x 85 mm
*'''Serial Peripherals'''
**2 x UART
**2 x I2C
**1 x I2S
**1 x SPI
**1 x GPIOs
|}

== Documentation ==
* [[media:DOC_Getting-Started-588-200_R03_2020-05-29.pdf|Avenger96 588-200 Getting-Started R03]]
* [[media:USM_DHCOR-STM32MP1_R05_2019-12-12.pdf|'''NEW''' DHCOR STM32MP1 User Manual R05 '''IMPORTANT: Please have a look at NEW chapter 24. Hardware design checklist''']]
:'''NOTE:''' Please also have a look at the STM32 MPU wiki: [[Avenger96#Links | Links]]

== Design Files ==
* [[media:SCH_588-200-HS00008-public_R07_2019-08-01.pdf|Avenger96 Schematic]]
* [[media:BOM_588-200-HS00008-public_R07_2019-08-01.xlsx|Avenger96 Bill of Material]]
* [[media:588-200_TOP_ASSEMBLY__R04_2019-04-12.pdf|Avenger96 Assembly Top]]
* [[media:588-200_BOTTOM_ASSEMBLY__R04_2019-04-12.pdf|Avenger96 Assembly Bottom]]
* [[media:BRD_588-200-with-DHCOR_2020-06-22.STEP|Avenger96 3D STEP file]]
* [[media:DHCOR-STM32MP1-Design-Symbols_2019-10-16.zip|DHCOR STM32MP1 Allegro/Orcad schematic and layout symbols (release date: 16.10.2019) '''Now with Allegro *.brd file and 3D information''']]
* [[media:DHCOR_STM32MP1_3D_STEP_586-100_R02.zip|DHCOR STM32MP1 3D STEP file]]
* [[media:DHCOR-PinMux-TFBGA361-Avenger96-HW200_2019-05-03.zip|Avenger96 CubeMX configuration (release date: 03.05.2019)]]

== Software ==
=== DH Mainline based Linux ===
:'''Notes:'''
:- The Mainline based Linux offers Etnaviv GPU driver support!!!
:- Based on '''kernel 5.10.x''' and Yocto version dunfell
* [https://github.com/dh-electronics/dhcom_stm32mp1-bsp-platform Yocto meta layer --> Github]
* [[media:2021-02-09-dh-image-demo-dh-stm32mp1-dhcor-common-avenger96.wic.xz|'''NEW''' DH Mainline based Starter Image 2021-02-09 (based on 5.10 kernel)]]
* [[DHCOR_STM32MP1_Linux| Linux and bootloader documentation]]
:'''NEW How to start with custom DHCOR design?'''
:The patch below is an example patch which applies on top of u-boot v2021.01 and implements a custom board derived from 3V3 option of DHCOR STM32MP1 SoM. That's pretty much all you have to change to implement the board. But, please tweak the DTs esp. where there are the FIXME comments.
:[[media:0001-ARM-dts-stm32-Add-DHCOR-based-FOO-board-u-boot-v2021.01.patch|'''NEW''' 0001-ARM-dts-stm32-Add-DHCOR-based-FOO-board-u-boot-v2021.01.patch]]
* [https://wiki.dh-electronics.com/index.php/STM32MP1_Browser_Performance STM32MP1 Browser Performance]

=== OpenSTLinux ===
 '''!!! This project is not longer maintenanced !!! --> Please use the "DH Mainline based Linux" version from DH electronics'''
:'''Notes:'''
:- Based on OpenSTLinux v2.1
:- GPU support based on original vivante GPU driver.
:- Based on kernel 5.4.x and Yocto version dunfell
* [https://github.com/dh-electronics/manifest-av96 Yocto meta layer --> Github]
:DH electronics Github contains the meta-av96 layer for ST SDK. Please see readme.txt which describes the build process.

* [[media:Avenger96_v6.9_2020-03-28.img.zip|OpenSTLinux-2.1 based on Yocto Dunfell LTS and Linux 5.4.56 - v6.9 Starter Image]] (Supported by Arrow Electronics)
:[[Starter Image Changelog]]
: This Image includes four different bootmodes to support some additional mezzanine boars. [https://wiki.dh-electronics.com/index.php/Starter_Image_Bootmode Click here to learn, how to change them.]

:'''X-LINUX-AI OpenSTLinux Expansion Package:''' Description: Expansion Package that targets artificial intelligence for STM32MP1 Series devices.
* [https://wiki.st.com/stm32mpu/wiki/X-LINUX-AI_OpenSTLinux_Expansion_Package '''NEW''' X-LINUX-AI OpenSTLinux Expansion Package]
* [https://wiki.st.com/stm32mpu/wiki/How_to_install_X-LINUX-AI_v2.0.0_on_Avenger96_board '''NEW''' How to install X-LINUX-AI v2.0.0 on Avenger96 board]

=== Debian ===
* [http://releases.linaro.org/96boards/avenger96/ Debian Buster Starter Image]

== Useful instructions ==

==== SPI Flash and eMMC Image Programming ====
*[[Avenger96 Image Programming | Avenger96 Image Programming]]

== Mezzanine Boards by DH electronics ==

==== DSI Display Adaptor Board ====
[[File:DSI Display Adaptor Board.jpg|thumb|DSI Display Adaptor Board]]
You can easily add an DSI display to your Avenger96 with the help of the DSI Display Adaptor Board.
The display can be activated easily on our Mainline Image with a device tree overlay as described [[DHCOR_STM32MP1_Linux| here]].
To get one of the boards, simply reach out to us and we'll prepare one for you.

== Links ==
* [https://wiki.st.com/stm32mpu/wiki/Main_Page STM32 MPU wiki]
* [https://wiki.st.com/stm32mpu/wiki/Category:Device_tree_configuration STM32 MPU wiki - Device tree configuration]
* [https://wiki.st.com/stm32mpu/index.php/STM32MP15_resources STM32MP15 resources]
* [https://www.96boards.org/ 96Boards]

XLON

2021-09-06T13:44:28Z

Fgerstandl: /* XLON Tools */

__NOTOC__
{| style="width: 100%; color: #000000; border-spacing: 2px; border: 1px solid darkgray;" valign="top" |
| style="width: 25%; text-align: center;" |
| style="width: 50%; text-align: center;" |
| style="width: 25%; text-align: center;" |
|-
|
| style="text-align: center;" | [[Image:XLON Logo in Schwarz von SD Kopie.jpg|400px|XLON]]
| style="text-align: center;" | [[Image:LOGO_DH_electronics.jpg|180px|DH electronics]]
|}

{| style="width: 100%; color: #000000;" valign="top" |
| style="width: 50%;" |
| style="width: 50%;" |
|-
|valign="top"|

== XLON products ==
{|
|
|
|-
|[[Image:XLON U10.png|100px|XLON U10|link=]]
|
*'''[[XLON U10]]'''
|}
|valign="top"|
|
|}

== Hardware Development ==

== Software Development ==
The XLON Uxx LonWorks interfaces come with two different flavours of configuration:
# Vendor mode - does not appear as a serial port in the system.
# CDC/ACM mode - appears as a (virtual) serial port in the system.
This configuration can be replaced using xlon-util tool.

=== XLON Tools ===
With the following links you can download the xlon-util for different architectures:
* [[media:AAAu48iSX_j4TVGTrvtwGuqja|xlon-util packages]]
: The xlon-util packages containes the xlon-util to configure the xlon-u10. It also contains the xlon-api libs to integrate the xlon-util functionality into a custom application.
* [[media:AAA8eq-wtunWfVFSOihXnh57a|dependency packages]]
: The dependency packages contains libraries which are not in the debian repositories.
* [[media:AADI1WNNbNVhxeswBt43cWKMa|development packages]]
: The development packages contains the api header files to compile a custom application with the xlon-api libs.

=== Windows Drivers ===
Drivers for various 32- and 64-Bit versions of Windows operating system:
{| class="wikitable"
|+Vendor mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86.zip|XLON-2G-Win7-x86.zip]]
|[[media:XLON-2G-Win7-x64.zip|XLON-2G-Win7-x64.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86.zip|XLON-2G-Win8-x86.zip]]
|[[media:XLON-2G-Win8-x64.zip|XLON-2G-Win8-x64.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86.zip|XLON-2G-Win8.1-x86.zip]]
|[[media:XLON-2G-Win8.1-x64.zip|XLON-2G-Win8.1-x64.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86.zip|XLON-2G-Win10-x86.zip]]
|[[media:XLON-2G-Win10-x64.zip|XLON-2G-Win10-x64.zip]]
|}

{| class="wikitable"
|+CDC/ACM mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86-cdc-acm.zip|XLON-2G-Win7-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win7-x64-cdc-acm.zip|XLON-2G-Win7-x64-cdc-acm.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86-cdc-acm.zip|XLON-2G-Win8-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8-x64-cdc-acm.zip|XLON-2G-Win8-x64-cdc-acm.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86-cdc-acm.zip|XLON-2G-Win8.1-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8.1-x64-cdc-acm.zip|XLON-2G-Win8.1-x64-cdc-acm.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86-cdc-acm.zip|XLON-2G-Win10-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win10-x64-cdc-acm.zip|XLON-2G-Win10-x64-cdc-acm.zip]]
|}

'''Important''': If you experience an error about missing 'Microsoft Visual C 2010 redistributable' when starting xlon_util.exe,
please download it from the [https://www.microsoft.com/de-de/download/details.aspx?id=5555 Microsoft site].

== [[FAQ_General |FAQ]] ==

== Series Manufacturing ==

STM32MP1 Browser Performance

2021-08-23T07:56:43Z

Fgerstandl: /* "Infragistics Ignite UI" Demo Application */

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.

[[File:ChromeProfilingIgnite.png|frameless]]

With the Chrome Profiler one can make following conclusions:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480

[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube runs very smooth with at least 40fps.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Heavy WebGL applications are not suited for this platform. 
Nevertheless appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube does not even show up on the screen.

=== Conclusion ===
Software Rendering (with no GPU) is no option on the STM32MP1 for graphical webinterfaces were responsiveness is required.

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

STM32MP1 Browser Performance

2021-08-23T07:55:19Z

Fgerstandl: /* Webgl example (aquarium) */

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480

[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube runs very smooth with at least 40fps.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Heavy WebGL applications are not suited for this platform. 
Nevertheless appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube does not even show up on the screen.

=== Conclusion ===
Software Rendering (with no GPU) is no option on the STM32MP1 for graphical webinterfaces were responsiveness is required.

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

XLON

2021-07-05T15:09:47Z

Fgerstandl: /* XLON Tools */

__NOTOC__
{| style="width: 100%; color: #000000; border-spacing: 2px; border: 1px solid darkgray;" valign="top" |
| style="width: 25%; text-align: center;" |
| style="width: 50%; text-align: center;" |
| style="width: 25%; text-align: center;" |
|-
|
| style="text-align: center;" | [[Image:XLON Logo in Schwarz von SD Kopie.jpg|400px|XLON]]
| style="text-align: center;" | [[Image:LOGO_DH_electronics.jpg|180px|DH electronics]]
|}

{| style="width: 100%; color: #000000;" valign="top" |
| style="width: 50%;" |
| style="width: 50%;" |
|-
|valign="top"|

== XLON products ==
{|
|
|
|-
|[[Image:XLON U10.png|100px|XLON U10|link=]]
|
*'''[[XLON U10]]'''
|}
|valign="top"|
|
|}

== Hardware Development ==

== Software Development ==
The XLON Uxx LonWorks interfaces come with two different flavours of configuration:
# Vendor mode - does not appear as a serial port in the system.
# CDC/ACM mode - appears as a (virtual) serial port in the system.
This configuration can be replaced using xlon-util tool.

=== XLON Tools ===
With the following links you can download the xlon-util for different architectures:
* [[media:AAAu48iSX_j4TVGTrvtwGuqja|xlon-util packages]]
: The xlon-util packages containes the xlon-util to configure the xlon-u10. It also contains the xlon-api libs to integrate the xlon-util functionality into a custom application.
* [[media:AADI1WNNbNVhxeswBt43cWKMa|dependency packages]]
: The dependency packages contains libraries which are not in the debian repositories.
* [[media:AADI1WNNbNVhxeswBt43cWKMa|development packages]]
: The development packages contains the api header files to compile a custom application with the xlon-api libs.

=== Windows Drivers ===
Drivers for various 32- and 64-Bit versions of Windows operating system:
{| class="wikitable"
|+Vendor mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86.zip|XLON-2G-Win7-x86.zip]]
|[[media:XLON-2G-Win7-x64.zip|XLON-2G-Win7-x64.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86.zip|XLON-2G-Win8-x86.zip]]
|[[media:XLON-2G-Win8-x64.zip|XLON-2G-Win8-x64.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86.zip|XLON-2G-Win8.1-x86.zip]]
|[[media:XLON-2G-Win8.1-x64.zip|XLON-2G-Win8.1-x64.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86.zip|XLON-2G-Win10-x86.zip]]
|[[media:XLON-2G-Win10-x64.zip|XLON-2G-Win10-x64.zip]]
|}

{| class="wikitable"
|+CDC/ACM mode Drivers
|-
!
!CPU x86
!CPU x64:
|-
!Windows 7
|[[media:XLON-2G-Win7-x86-cdc-acm.zip|XLON-2G-Win7-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win7-x64-cdc-acm.zip|XLON-2G-Win7-x64-cdc-acm.zip]]
|-
!Windows 8
|[[media:XLON-2G-Win8-x86-cdc-acm.zip|XLON-2G-Win8-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8-x64-cdc-acm.zip|XLON-2G-Win8-x64-cdc-acm.zip]]
|-
!Windows 8.1
|[[media:XLON-2G-Win8.1-x86-cdc-acm.zip|XLON-2G-Win8.1-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win8.1-x64-cdc-acm.zip|XLON-2G-Win8.1-x64-cdc-acm.zip]]
|-
!Windows 10
|[[media:XLON-2G-Win10-x86-cdc-acm.zip|XLON-2G-Win10-x86-cdc-acm.zip]]
|[[media:XLON-2G-Win10-x64-cdc-acm.zip|XLON-2G-Win10-x64-cdc-acm.zip]]
|}

'''Important''': If you experience an error about missing 'Microsoft Visual C 2010 redistributable' when starting xlon_util.exe,
please download it from the [https://www.microsoft.com/de-de/download/details.aspx?id=5555 Microsoft site].

== [[FAQ_General |FAQ]] ==

== Series Manufacturing ==

File:Xlon-u10 1.9+deb10 armhf.zip

2021-07-05T14:35:12Z

Fgerstandl:

File:Xlon-u10 1.9+deb9 amd64.zip

2021-07-05T14:34:34Z

Fgerstandl:

File:Xlon-u10-dev 1.9 win.zip

2021-07-05T14:34:17Z

Fgerstandl:

File:Xlon-u10-dev 1.9.zip

2021-07-05T14:34:07Z

Fgerstandl:

File:Xlon-u10-1.9-x64.zip

2021-07-05T14:33:53Z

Fgerstandl:

STM32MP1 Browser Performance

2021-06-02T07:44:00Z

Fgerstandl:

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube runs very smooth with at least 40fps.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Heavy WebGL applications are not suited for this platform. 
Nevertheless appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube does not even show up on the screen.

=== Conclusion ===
Software Rendering (with no GPU) is no option on the STM32MP1 for graphical webinterfaces were responsiveness is required.

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

STM32MP1 Browser Performance

2021-06-02T07:28:23Z

Fgerstandl: /* Performance Tests with software renderning (without GPU) */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube runs very smooth with at least 40fps.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Heavy WebGL applications are not suited for this platform. 
Nevertheless appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube does not even show up on the screen.

=== Conclusion ===
Software Rendering (with no GPU) is no option on the STM32MP1 for graphical webinterfaces were responsiveness is required.

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

STM32MP1 Browser Performance

2021-06-02T07:25:40Z

Fgerstandl: /* Performance Tests with software renderning (without GPU) */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube runs very smooth with at least 40fps.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Heavy WebGL applications are not suited for this platform. 
Nevertheless appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube does not even show up on the screen.

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

STM32MP1 Browser Performance

2021-06-02T07:24:19Z

Fgerstandl: /* Performance Tests with hardware acceleration (etnaviv) */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== 3D-animation and video as texture ===
[[File:3danimation.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

The cube runs very smooth with at least 40fps.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Heavy WebGL applications are not suited for this platform. 
Nevertheless appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

File:3danimation.png

2021-06-02T07:17:46Z

Fgerstandl:

STM32MP1 Browser Performance

2021-06-02T07:10:05Z

Fgerstandl: /* Conclusion */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Heavy WebGL applications are not suited for this platform. 
Nevertheless appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

STM32MP1 Browser Performance

2021-06-02T07:03:47Z

Fgerstandl:

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

STM32MP1 Browser Performance

2021-06-02T07:02:55Z

Fgerstandl: /* Conclusion */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC. Appealing web pages with responsive requirements on the STM32MP1 are possible.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:58:58Z

Fgerstandl: /* Performance Tests with hardware acceleration (etnaviv) */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

=== Conclusion ===
Webapplications must be optimized for particular embedded system resp. SOC

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:57:29Z

Fgerstandl:

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:56:28Z

Fgerstandl: /* Line-Chart Demo Application */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
[[File:ChartLineWithGPU.png|frameless]]

https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

* with GPU support
* 20 - 30 fps
* works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:56:00Z

Fgerstandl: /* Performance Tests with software renderning (without GPU) */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
[[File:ChartLineWithoutGPU.png|frameless]]

https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

* without GPU (Software Rendering)
* < 1 fps
* too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:49:08Z

Fgerstandl: /* Line-Chart Demo Application */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
:[[File:ChartLineWithoutGPU.png|frameless]]

:https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

:- without GPU (Software Rendering)
:- < 1 fps
:- too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:48:57Z

Fgerstandl: /* */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== Performance Tests with software renderning (without GPU) ==
=== Line-Chart Demo Application ===
:[[File:ChartLineWithoutGPU.png|frameless]]

:https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

:- without GPU (Software Rendering)
:- < 1 fps
:- too slow to be usable

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:48:08Z

Fgerstandl:

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== ==
=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

* '''no GPU'''
:[[File:ChartLineWithoutGPU.png|frameless]]

:https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

:- without GPU (Software Rendering)
:- < 1 fps
:- too slow to be usable

*'''with GPU'''
:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:47:23Z

Fgerstandl: /* Performance Tests */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests with hardware acceleration (etnaviv) ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:45:31Z

Fgerstandl: /* Webgl example (aquarium) */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

* '''no GPU'''
:[[File:ChartLineWithoutGPU.png|frameless]]

:https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

:- without GPU (Software Rendering)
:- < 1 fps
:- too slow to be usable

*'''with GPU'''
:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
http://webglsamples.org/aquarium/aquarium.html?numFish=1&canvasWidth=800&canvasHeight=480
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in '''3fps'''.

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:42:56Z

Fgerstandl: /* Webgl example (aquarium) */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

* '''no GPU'''
:[[File:ChartLineWithoutGPU.png|frameless]]

:https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

:- without GPU (Software Rendering)
:- < 1 fps
:- too slow to be usable

*'''with GPU'''
:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===
[[File:Webgl aquarium.png|frameless]]

Running a webgl example page (fishtank) on the STM32MP1 (etnaviv) with Chromium under a resolution of 800x600 results in
{|
3fps
|}

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

File:Webgl aquarium.png

2021-06-02T06:37:49Z

Fgerstandl:

STM32MP1 Browser Performance

2021-06-02T06:36:39Z

Fgerstandl: /* Glmark2 Benchmark */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

* '''no GPU'''
:[[File:ChartLineWithoutGPU.png|frameless]]

:https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

:- without GPU (Software Rendering)
:- < 1 fps
:- too slow to be usable

*'''with GPU'''
:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

With the following results:
{|
|
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:36:06Z

Fgerstandl: /* Glmark2 Benchmark */

== Tasks of the GPU ==
* For „simple“ webpages without 3D-features, the GPU is only used for „blitting“during a process step called „Raster(ization) and Compositing“
* „blitting“ = fast copy and move of memory objects
* By this, a strong relief of the CPU can be achieved
* this should be well possible with the STM32MP1

== Performance Tests ==
=== "Infragistics Ignite UI" Demo Application ===
[[File:Infragistics.png|frameless]] 
The "Infragistics Ignite UI" is a commercial WebUI framework based on Angular. 
To test the browser perfomance a WebUI based on that framework was used.

[[File:BardiagramIgnite.png|frameless]] 
To open the screen in the above screenshot it takes approx. 3 seconds from menu click until content is fully visible

To get some insights the chromium profiling was used.
[[File:ChromeProfilingIgnite.png|frameless]]
The Chrome Profiler shows following things:
* the CPU does most of the work
* there is no obvious point where CPU cycles would be spent excessively (perf doesn't indicate anything).
* approx. 70% of the time is spent interpreting Javascript. This is also to be expected, since this angular is full of complex Javascript.
* But that also means the slowness is caused by the CPU / website
* not much the GPU can do about this.

=== QOpenGLWidget Example ===

=== Line-Chart Demo Application ===
The Line-Chart demo application should show the differnces in performance between hardware acceleration and software rendering on the STM32MP1.

* '''no GPU'''
:[[File:ChartLineWithoutGPU.png|frameless]]

:https://www.dropbox.com/s/kprvgowf8kzod6a/ohne_GPU.MP4?dl=0

:- without GPU (Software Rendering)
:- < 1 fps
:- too slow to be usable

*'''with GPU'''
:[[File:ChartLineWithGPU.png|frameless]]

:https://www.dropbox.com/s/323nv90lhp9wh02/mit_GPU.MP4?dl=0

:- with GPU support
:- 20 - 30 fps
:- works very well

=== DH demo from tradeshow ===
[[File:TradeshowDemo.png|frameless]]

https://www.dropbox.com/s/rzeu2qk95oxy4lw/sensorless_demo_filtered_idastroem_DH%20electronics.mp4?dl=0

=== Webgl example (aquarium) ===

== drawElements Quality Program (deqp) ==
The drawElements Quality Program (deqp) is a benchmarking system for measuring the quality of GPUs and their drivers. 

It can be started from the commandline with the following script (no display needed):
<syntaxhighlight lang="sh" line>
#!/bin/sh

export GPU_TESTS='dEQP-GLES2.performance*'

export ETNA_MESA_DEBUG=nir
export EGL_PLATFORM=surfaceless
export XDG_RUNTIME_DIR=/var/run/user/`id -u`/

# Observe that GPU is rendering:
# dstat -i -I `grep gpu /proc/interrupts | cut -d : -f 1`

cd /usr/share/deqp/gles2/

unset LIBGL_ALWAYS_SOFTWARE
unset GBM_ALWAYS_SOFTWARE

./deqp-gles2 \
--deqp-surface-width=256 \
--deqp-surface-height=256 \
--deqp-surface-type=pbuffer \
--deqp-gl-config-name=rgba8888d24s8ms0 \
--deqp-visibility=hidden \
--deqp-log-images=enable \
--deqp-crashhandler=enable \
--deqp-log-filename=hardware.qpa \
-n ${GPU_TESTS} 2>&1 | tee hardware.log

../tools/testlog-to-xml hardware.qpa hardware.xml

export LIBGL_ALWAYS_SOFTWARE=true

# Observe results using a browser, run the following # $ ln -s ../tools/testlog.* .
# $ python3 -m http.server \
# --bind 0.0.0.0 \
# --directory /usr/share/deqp/gles2/ 8080
# Navigate to http://IP-of-the-board:8080
</syntaxhighlight>

The deqp run on the STM32MP1 (etnaviv driver) gives the following results:
Test run totals:
Passed: 1729/1783 97.0%
Failed: 54/1783 33.0%
Not supported: 0/1783 0.0%
Warnings: 0/1783 0.0%

The full logs can be found here: 
[[media:STM32MP1_deqp_logs.zip|STM32MP1_deqp_logs.zip]]

== Glmark2 Benchmark ==
A Glmark2 Benchmark was run on the STM32MP1 with an 800x600 resolution with the following command:
{|
|
glmark2-es2-drm --off-screen -s 800x600 --annotate
|}

{|
|
root@dh-stm32mp1-dhcom-pdk2:~# glmark2-es2-drm --off-screen -s 800x600 --annotate
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER: Vivante GC400 rev 4652
GL_VERSION: OpenGL ES 2.0 Mesa 20.2.2 (git-df2977f871)
=======================================================
[build] use-vbo=false: FPS: 182 FrameTime: 5.495 ms
[build] use-vbo=true: FPS: 221 FrameTime: 4.525 ms
[texture] texture-filter=nearest: FPS: 176 FrameTime: 5.682 ms
[texture] texture-filter=linear: FPS: 174 FrameTime: 5.747 ms
[texture] texture-filter=mipmap: FPS: 177 FrameTime: 5.650 ms
[shading] shading=gouraud: FPS: 149 FrameTime: 6.711 ms
[shading] shading=blinn-phong-inf: FPS: 89 FrameTime: 11.236 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 141 FrameTime: 7.092 ms
[bump] bump-render=height: FPS: 90 FrameTime: 11.111 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 4 FrameTime: 250.000 ms
[pulsar] light=false:quads=5:texture=false: FPS: 106 FrameTime: 9.434 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 11 FrameTime: 90.909 ms
[desktop] effect=shadow:windows=4: FPS: 54 FrameTime: 18.519 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 31 FrameTime: 32.258 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 39 FrameTime: 25.641 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 21 FrameTime: 47.619 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 42 FrameTime: 23.810 ms
[refract] <default>: FPS: 9 FrameTime: 111.111 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 103 FrameTime: 9.709 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 97 FrameTime: 10.309 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 27 FrameTime: 37.037 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
=======================================================
glmark2 Score: 75
=======================================================
|}

== Some Toughts about Javascript performance ==
====Is it correct, that since js is interpreted and is not thread safe, js of a single webpage does not make use of multithreading/multiprocessing? ====
JS is interpreted, yes. However, both the chromium v8 engine and firefox tracemonkey are JIT compilers and turn that JS into code native to the architecture on which they are running. This leads to a huge performance boost compared to simple interpreting. The JS JIT compilation can be parallelized. 

JS is synchronous and has no concept of threads. However, there are these Promise() things and events (like timer callbacks). The JS engines generally have separate thread(s) to deal with such events, so the JS code can set up some "async" operation by calling a function (e.g. load something from somewhere) that triggers a JS function on completion. What happens is that the JS itself runs on CPU0, while a thread doing that loading runs on CPU1, and suddenly your javascript uses two CPU cores. 

So if you add those two points above together, you get that contemporary JS engines and the way contemporary JS is written end up using multiple CPUs. It is just not done in the traditional manner and it does look like a lot of crutches indeed.

== Profiling with Chrome DevTools ==
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. It is possible to analyse the runtime performance of a website directly on the target or remote with an PC connected over ethernet.
With an remote connection you can measure the performance without interfering the measurment itself.
The Chrome DevTools can also be used with an qtWebengine.

=== How to use Chrome DevTools with an remote connection ===
To be able to remote debug chromium on the target you need to start the chromium or qWebengine with the following parameters: 
<code>-remote-debugging-port=9222 --user-data-dir=remote-profile</code>

To access it from a different computer you need to forward the port with ssh: 
<code>ssh -L 0.0.0.0:9223:localhost:9222 localhost -N</code> 
This must be done before the webbrowser gets started.

With an Chrome Browser on an computer connected with the target over ethernet you can now open the devtools with the IP of the target and the port "9223". 
This clip shows you how to open den chrome devtools within chrome: [[media:Devtools-open.mp4.mp4|devtools-open.mp4]]

=== DevTools analysis ===
The following tools can be used for performance anlaysis:
* CPU Usage: 
:[[File:ChromeDevToolsCPU.png|frameless]]
:[[media:Devtools-performance-monitor-cpu.mp4|devtools-performance-monitor-cpu.mp4]]
:With this stat you can easily see when the CPU is under full load. 

* GPU Usage:
:[[File:ChromeDevToolsGPU.png|frameless]]
:The graph shows when the GPU is under use. But it does not show the GPU load in percent. 
:It is a useful tool to see if the GPU is fully ocupied. 
:If the GPU is disabled (software rendering) this graph is absent.

* Frame Rendering Stats:
:[[File:ChromeDevToolsFrameRendering.png|frameless]]
:Newer chrome versions don't show live FPS anymore. But you can us "dropped" or "delayed" frames as indicator for good or bad performance. The higher the percentage value (frames rendered in time) the better. 
:A good explanation can be found here:
:https://groups.google.com/a/chromium.org/g/blink-dev/c/iHULoSyUxOQ

* Performance Profile:
:[[File:ChromedevtoolsPerformanceProfiling.png|frameless]]
:[[media:Devtools-start-performance-profiling.mp4|devtools-start-performance-profiling.mp4]]
:The performance profile gives you an overview over all important stats at once. You can record it while browsing through an website on the target. 
:You can save such profiles and import it with any other chrome browser to analyse the profile offline.

== Brief summary ==
* Webapplications must be optimized for particular embedded system resp. SOC
* Comprehensive analysis and profiling tools are available
* Thus, appealing web pages on embedded systems should be possible
* … where also the “responsiveness" is given

STM32MP1 Browser Performance

2021-06-02T06:27:53Z

Fgerstandl: /* drawElements Quality Program (deqp) */

STM32MP1 Browser Performance

2021-06-02T06:27:29Z

Fgerstandl: /* Glmark2 Benchmark */

STM32MP1 Browser Performance

2021-06-02T06:22:07Z

Fgerstandl:

STM32MP1 Browser Performance

2021-06-02T06:21:29Z

Fgerstandl: /* Functional GPU testing (deqp) */

STM32MP1 Browser Performance

2021-06-02T06:20:14Z

Fgerstandl: /* Functional GPU testing (deqp) */

STM32MP1 Browser Performance

2021-06-02T06:16:36Z

Fgerstandl: /* Functional GPU testing (deqp) */

STM32MP1 Browser Performance

2021-06-02T06:12:16Z

Fgerstandl: /* Functional GPU testing */

STM32MP1 Browser Performance

2021-06-01T14:59:51Z

Fgerstandl: /* Functional GPU testing */

STM32MP1 Browser Performance

2021-06-01T14:47:03Z

Fgerstandl: /* Functional GPU testing */

STM32MP1 Browser Performance

2021-06-01T14:37:03Z

Fgerstandl: /* Line-Chart Demo Application */

STM32MP1 Browser Performance

2021-06-01T14:36:41Z

Fgerstandl: /* Line-Chart Demo Application */

STM32MP1 Browser Performance

2021-06-01T14:36:09Z

Fgerstandl: /* Line-Chart Demo Application */

STM32MP1 Browser Performance

2021-06-01T14:35:40Z

Fgerstandl: /* Line-Chart Demo Application */

STM32MP1 Browser Performance

2021-06-01T14:34:17Z

Fgerstandl: /* Line-Chart Demo Application */