feature(lvgl_port): Initial support for SIMD rendering in LVGL (BSP-525)

[peter-marcisovsky]

ESP-BSP Pull Request checklist

Note: For new BSPs create a PR with this link.

• [ ] Version of modified component bumped
• [ ] CI passing

Change description

This MR adds an initial support for SIMD rendering in LVGL using LVGL's internal Blend API

Related

• https://github.com/espressif/esp-bsp/issues/154

This MR Implements:

• Assembly source files integrated into the lvgl_port component
• Integration into the LVGL blend API via LVGL's kconfig
  • LV_DRAW_SW_ASM_CUSTOM must be enabled
  • LV_DRAW_SW_ASM_CUSTOM_INCLUDE must be provided with a header file with function header for the assembly implemented functions, in our case esp_lvgl_port_lv_blend.h
  • This way, the esp_lvgl_port_lv_blend.h is under our control during the development phase, and will be included into the official LVGL repo once finalized, just like the existing SIMD header files from ARM.
• Assembly implementation of following primitive rendering functions:
  • Simple fill for ARGB8888 color format, supported targets are esp32s3 and esp32
  • Simple fill for RGB565 color format, supported target is esp32
• Test app with functionality and benchmark tests

[CLAassistant]

All committers have signed the CLA.

[peter-marcisovsky]

Reworked test apps:

• Functionality test:

  • uses hard copy of necessary lvgl source files, thus creating a local ANSI C version of the LVGL Blend API for functionality test comparison with the Assembly version of the API
  • Does not use neither the LVGL port, nor the LVGL managed component

• Benchmark test:

  • 2 separate tests apps with different sdkconfig settings (Assembly render Enabled/Disabled) must be build for benchmark comparison
  • Uses LVGL port, as it gives a performance comparison of an overall Assembly render integration into the LVGL

[peter-marcisovsky]

Reworked test apps (again):

Due to a recent LVGL refactoring in the LVGL 9.2 release, where it is not possible to access a private LVGL members by default, also couple of other (breaking in my case) changes, it was decided to get rid of the lvgl component for test apps completely, not to risk another possible refactoring of the lvgl port and test apps.

• Build:

  • Only for LVGL 9.1 (below)

• Test apps:

  • Both (functionality and benchmark) merged into a single project, with a single CMake
  • Both are using hard copy of VLGL's blend API directly, thus we do not depend on the higher VLGL API, which is, either-way, not important for us in our tests and not very readable when creating test cases
  • No need to rebuild a project to switch between the ASM and ANSI rendering

• LVGL version:

  • For now, LVGL 9.1 version is used
  • There is a possibility of opening an new issue to the LVGL, to fix some include errors on their side, which we are facing in this MR with the LVGL 9.2
  • After that we will be able to use changes in this MR with LVGL 9.2

[tore-espressif]

Very nice work @peter-marcisovsky !

The only remaining thing is compatibility with LVGL 9.2, we can discuss next week

[peter-marcisovsky]

@tore-espressif
Resolved all conversations, LVGL version for this feature set in CMake to 9.1.0 <= LVG_version < 9.2.0 Ready to merge

[espzav]

LGTM

@espzav @igrr This is ready for merging. Please let us know if you want to have another look before we merge

I fast reviewed it again, LGTM

[igrr]

Latest version LGTM!

Have you done any composite benchmarks (e.g. frames per second on some LVGL demo)? If yes, it would be interesting to see how much we gain from these assembly routines. (Not a blocker for pressing the merge button.)