Migrate the two VG-Lite drivers

[kisvegabor]

Now we have 2 VG-Lite drivers which is no ideal. I asked @uLipe to test the performance and get familiar with the internals/pro/cons of each implementations so that we can start working on a single unified solution.

To check what's going on I've created and SDK example for NXP i.MX1170 (with FreeRTOS as there is no VGLite in the Bare metal version) and updated it to LVGL v9. It compiles and works mostly with software rendering:

• there are some cache related artifacts
• it's very slow. -O3 and linking the app to RAM could make it fast

When I enable Xiaomi's VGLite I get this error (LV_USE_DRAW_VG_LITE):

../lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_utils.h:96:40: error: unknown type name 'vg_lite_stroke_t'
   96 | void lv_vg_lite_stroke_dump_info(const vg_lite_stroke_t * stroke);
      |                                        ^~~~~~~~~~~~~~~~
make[1]: *** [lvgl/lvgl/src/draw/vg_lite/subdir.mk:75: lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_stroke.o] Error 1
../lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_path.c: In function 'lv_vg_lite_path_reset':
../lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_path.c:143:28: error: 'VG_LITE_DRAW_ZERO' undeclared (first use in this function)
  143 |     path->base.path_type = VG_LITE_DRAW_ZERO;

When I enable NXP's VGLite I get this error (LV_USE_DRAW_VGLITE):

../lvgl/lvgl/src/draw/nxp/vglite/lv_vglite_utils.h:28:10: fatal error: vg_lite_options.h: No such file or directory
   28 | #include "vg_lite_options.h"

I pushed my current project here:

cc @FASTSHIFT @onecoolx @nicusorcitu @anaGrad @cosmindanielradu19

Could you take a look at this issue to point us into right direction?

Context: We need to create a demo for CES and I'd like to use some cool perspective matrix transformation effects.

[FASTSHIFT]

This is because the VG-Lite driver version is not new enough. It is recommended to update the VG-Lite driver to this version (or a later version) to maintain the consistency of the code and the most full functionality and performance.

../lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_utils.h:96:40: error: unknown type name 'vg_lite_stroke_t'
   96 | void lv_vg_lite_stroke_dump_info(const vg_lite_stroke_t * stroke);
      |                                        ^~~~~~~~~~~~~~~~
make[1]: *** [lvgl/lvgl/src/draw/vg_lite/subdir.mk:75: lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_stroke.o] Error 1
../lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_path.c: In function 'lv_vg_lite_path_reset':
../lvgl/lvgl/src/draw/vg_lite/lv_vg_lite_path.c:143:28: error: 'VG_LITE_DRAW_ZERO' undeclared (first use in this function)
  143 |     path->base.path_type = VG_LITE_DRAW_ZERO;

[nicusorcitu]

@cristian-stoica

[nicusorcitu]

hi @kisvegabor I see you are testing lvgl 9 on rt1170. The board is not yet supported. I mean it is supported on our end but code have not been pushed on github.
When do you need this to be done? Hopefully in the meanwhile we push the driver to NXP/github for 24.12 release. I will let you know when is done.

[nicusorcitu]

If you need it just now, @cosmindanielradu19 can provide you an archive with everything is done for 1170.

[kisvegabor]

Thank you for the quick reply. It'd be great if you could send an archive.

[kisvegabor]

I've just noticed that link application to RAM is not working now. It crashes immediately. Maybe is it also fixed?

[kisvegabor]

When do you need this to be done?

In 2 weeks. 🙁 Using an other demo could be an option too, but we need to address the performance issue (ideally by having both the GPU and linking to RAM working)

[uLipe]

I have one question, the VGLite would be platform independent, so assuming that the both implementations follows the specification from the API, would I be able to run a demo for both VGLite implementations with minimal configuration changes using the same board right?

I'm running after the same IMXRT1170 + X-RK055HDMIPI (this one I already have) and it would be good to know if this scenario at least, theoretically is true.

[cristian-stoica]

I've just noticed that link application to RAM is not working now. It crashes immediately. Maybe is it also fixed?

I've had mixed results running from RAM on 1170. Typically, I run from FLASH for testing and OCRAM for performance. If the application is small enough to fit OCRAM I make the OCRAM1 section as large as possible at the expense of OCRAM2.
Besides the "link application from RAM" checkbox, you need to put the RAM section (OCRAM1) the first in the list in MCU_SETTINGS. If it doesn't work like this there are likely some initialization issues the SDK (doesn't) take care of. An archive from Cosmin will probably fix that :)

[cosmindanielradu19]

Thank you for the quick reply. It'd be great if you could send an archive.

I'll come back with the archive of the project tomorrow.

[kisvegabor]

I'm planning to use the ebike demo as a fallback plan, but the background image is quite large there (1.8MB), which won't fit to OCRAM. Can we link the app to OCRAM but the background image to external RAM? I assume that external RAM it's faster than the external flash.

[nicusorcitu]

Hi @kisvegabor
What I would suggest is:

1. Put the code binary in internal RAM (OCRAM) - mandatory.
2. Let the FBs in external RAM (SDRAM) - mandatory for RT1170. On RT700 the FB can fit as well in internal RAM (SRAM).
3. Try to put all the assets (source images) into OCRAM as well - recommended. If there is no place in OCRAM, put them in SDRAM (less performance than previous).
4. Don't use FLASH at all :).