• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 140 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VEN-Q1: Inquiry Regarding Complex Graphics Rendering, LVGL Integration, and Display Architecture

HC Nong
Prodigy 100 points

Part Number: TDA4VEN-Q1

Dear TI expert,  

        Hope this email finds you well.

        We are currently working on a project that requires adding complex graphics rendering—such as drawing intricate shapes and complex icons—on top of an existing image/video stream.

    Our Proposed Architecture:
        To achieve this, we considered an LVGL-based solution. The concept is to have LVGL render the UI data onto a dedicated graphics layer, while the original video stream occupies another layer. During the display phase, we intend to leverage the DSS (Display Subsystem) hardware to perform a hardware overlay/blending of these layers to output the final image.

    The Architectural Dilemma:
        However, we are facing an architectural bottleneck. Currently, the display node runs on the MCU2_0 (Main R5F) core, and LVGL lacks native adaptation for the FVID2 APIs and DSS drivers used there.

        To resolve this, we have brainstormed two potential data flow paths, but both have their trade-offs:

  • Path A (A-Core Direct Display): We develop a custom display node running on the A-core. LVGL would utilize the standard Linux DRM framework to push the display directly, entirely bypassing the existing FVID2-based display node on the Main R5F.
  • Path B (A-Core Rendering + R5F Overlay): LVGL renders the UI buffer on the A-core and then passes this rendered buffer down to the Main R5F (likely via IPC/shared memory). The display node on the Main R5F would then take both the original video buffer and the UI buffer, invoking the DSS driver (via FVID2) to perform the final hardware overlay.

        Given this context, we would greatly appreciate your insights and advice on the following two questions:

  1. Regarding R5F DSS Driver Capabilities: Does the current DSS driver implementation on the Main R5F (via FVID2 APIs) fully support multi-layer hardware overlay/blending? Specifically, can it simultaneously manage and blend a dedicated video plane and a separate UI graphics plane (ideally with alpha blending support)?

  2. Regarding LVGL Adaptation: Is there a more elegant or efficient implementation strategy to adapt LVGL for our current architecture without completely bypassing the R5F display node?
  3. Regarding Alternative Solutions: If we were to pivot away from LVGL, are there other rendering frameworks or software solutions you would recommend for handling this kind of complex graphic overlay?

    Thank you for your time and expertise. We look forward to hearing your insights.

Best regards,

  • +1
    TI__Mastermind 24850 points

    Hi Nong,

    HC Nong said:
    • Path B (A-Core Rendering + R5F Overlay): LVGL renders the UI buffer on the A-core and then passes this rendered buffer down to the Main R5F (likely via IPC/shared memory). The display node on the Main R5F would then take both the original video buffer and the UI buffer, invoking the DSS driver (via FVID2) to perform the final hardware overlay.

    You can go with approach, we have openvx node for display which is running in r5f and you can submit the frames/buffers from a53 core. If you do not know already can you check the vision_app demos. 

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/vision_apps/docs/user_guide/group_apps_basic_demos_app_single_cam.html

    Where 2 streams are displayed ( camera feed, and performance stats on top of camera feed ) using 2 video pipelines of DSS.

    You can refer to the application here $(psdkra)/vision_apps/apps/basic_demos/app_multi_cam/main.c

    If your LVGL could able to generate the frame in the openvx format in the shared memory then you can just create display node (1st video pipeline)and submit the frame directly.

    Similarly 2nd display node ( 2nd video pipeline) can be used to stream the original video. If your LVGL can generate rgba frames then the hardware overlay manager will take care of blending.

    You have to take care of 2 streams generating frame buffers in tiovx shared memory region. 

    HC Nong said:

    • Regarding R5F DSS Driver Capabilities: Does the current DSS driver implementation on the Main R5F (via FVID2 APIs) fully support multi-layer hardware overlay/blending? Specifically, can it simultaneously manage and blend a dedicated video plane and a separate UI graphics plane (ideally with alpha blending support)?

    Yes, You can blend video from 2 pipeline (only 2 layer), DSS instance has only 2 pipelines.

    HC Nong said:
    • Regarding LVGL Adaptation: Is there a more elegant or efficient implementation strategy to adapt LVGL for our current architecture without completely bypassing the R5F display node?

    You can refer to the existing vision_apps demos

    HC Nong said:
    1. Regarding Alternative Solutions: If we were to pivot away from LVGL, are there other rendering frameworks or software solutions you would recommend for handling this kind of complex graphic overlay?

    Its a quite generic answer, you can use gpu to render the final frame ( blending 2 streams) and pass it to the display node. But i would suggest to look for the above approach where you can use the DSS hardware.

    Regards,
    Gokul