esp_lvgl_adapter ESP_LV_ADAPTER_TEAR_AVOID_MODE_TRIPLE_PARTIAL allocate draw buffer should use psram flag in config (AEGHB-1340)

[mattmatt206]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Currently when using ESP_LV_ADAPTER_TEAR_AVOID_MODE_TRIPLE_PARTIAL the draw buffer that is allocated is made in internal memory. I believe it should follow what the user has set their preference to, see below

esp-iot-solution/components/display/tools/esp_lvgl_adapter/include/esp_lv_adapter_display.h

Line 75 in 21670a6

bool use_psram; /*!< Use PSRAM for buffers if available */

this is where the draw buffer is created

esp-iot-solution/components/display/tools/esp_lvgl_adapter/src/display/display_manager.c

Line 802 in 21670a6

void *buf = display_manager_alloc_draw_buffer(cfg->draw_buf_pixels * color_size, false);

i believe it should be as follows
void *buf = display_manager_alloc_draw_buffer(cfg->draw_buf_pixels * color_size, profile->use_psram);

Regards,
Matt

[Horion0415]

The main idea of this tear-avoidance mode is to render in SRAM and then quickly fill the LCD frame buffer. Therefore, when this tear-avoidance mode is enabled, the user’s PSRAM allocation preference is intentionally ignored — this is the expected behavior.

At the current stage, only rendering in SRAM can significantly improve the frame rate.
If the user is running low on SRAM, it is recommended to reduce the number of allocated lines.

[Horion0415]

If you want tear-avoidance but prefer not to use SRAM, you may consider other tear-avoidance modes, such as ESP_LV_ADAPTER_TEAR_AVOID_MODE_TRIPLE_FULL.
However, ESP_LV_ADAPTER_TEAR_AVOID_MODE_TRIPLE_PARTIAL is currently the most efficient solution.

[mattmatt206]

@Horion0415 Thank you for your response.
I'm developing a project which has an RGB56 display that is 480*854 running on the ESP32S3. Its required to work in both landscape and portrait mode, thus software rotation is required.
Currently the best performance i can get is if the orientation is portrait (0 degrees, no software rotation required) I use ESP_LV_ADAPTER_TEAR_AVOID_MODE_DOUBLE_DIRECT and when landscape (rotated 90 degrees) I use ESP_LV_ADAPTER_TEAR_AVOID_MODE_TRIPLE_PARTIAL. Unfortunately there is a lot running on the project and don't have enough free space for a partial buffer to reside in internal memory under normal operation. Though i did try it with less stuff running where i was able to use internal memory for the partial buffer and only saw a very minimal FPS increase (1 FPS different running the benchmark see screen shots below)

Direct (Double Direct): 2FB

Partial (Triple Partial): 3FB + 1DB (internal memory 85x480px)

Partial (Triple Partial): 3FB + 1DB (external memory 85x480px)

[Horion0415]

The tear-avoidance principle of ESP_LV_ADAPTER_TEAR_AVOID_MODE_TRIPLE_PARTIAL is based on rendering LVGL output in SRAM to avoid PSRAM bandwidth contention and cache misses. This approach is effective on ESP32-P4 and ESP32-S3 for most display resolutions.

However, I noticed that the RGB display you are using is 480 × 854, which is quite large for the ESP32-S3. At this resolution, the performance bottleneck shifts from cache and memory bandwidth to the CPU itself. I have also tested tear-avoidance strategies on ESP32-S3 with an 800 × 480 display, and the results were very similar to your case.

At this resolution, there is unfortunately no ideal solution—the ESP32-S3 is already at its performance limit.

Besides tear-avoidance mode selection, I recommend checking the following configurations to maximize LVGL performance:

PSRAM configuration (frequency, XIP, etc.)

Cache configuration

CPU settings

Optimizing these may help squeeze out a bit more performance.

[mattmatt206]

@Horion0415 thanks for the info. Yes i do also believe this screen may be stretching the ESP32-S3 to its limit. I believe i have set everything as best as i can, these are the most notable sdkconfig settings:

CONFIG_IDF_EXPERIMENTAL_FEATURES=y
CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_240=y

ONFIG_SPIRAM=y
CONFIG_SPIRAM_MODE_OCT=y
CONFIG_SPIRAM_SPEED_120M=y
CONFIG_SPIRAM_XIP_FROM_PSRAM=y
CONFIG_SPIRAM_FETCH_INSTRUCTIONS=y
CONFIG_SPIRAM_RODATA=y
CONFIG_SPIRAM_USE_CAPS_ALLOC=y

CONFIG_ESPTOOLPY_FLASHMODE_QIO=y
CONFIG_ESPTOOLPY_FLASHFREQ_120M=y
CONFIG_ESPTOOLPY_FLASHSIZE_16MB=y
CONFIG_SPI_FLASH_UNDER_HIGH_FREQ=y
CONFIG_SPI_FLASH_HPM_ENA=y
CONFIG_SPI_FLASH_HPM_DC_DISABLE=y

CONFIG_ESP32S3_DATA_CACHE_64KB=y
CONFIG_ESP32S3_DATA_CACHE_LINE_64B=y

CONFIG_LCD_RGB_ISR_IRAM_SAFE=y

config settings
bounce_buffer size: 7320

[Horion0415]

It looks like your configuration is already pushed to the limit. This resolution is quite large, and you're now hitting both the PSRAM bandwidth and CPU limits. There may not be much improvement possible when rotation is enabled. You might consider using an ESP32-P4 or a display with a lower resolution.

[Horion0415]

It is generally recommended that displays driven by the ESP32-S3 do not exceed a resolution of 480 × 480, otherwise there will be a significant drop in frame rate.

[mattmatt206]

@Horion0415 Thank you for the info.
Based off of what you've said the ESP_LV_ADAPTER_TEAR_AVOID_MODE_TRIPLE_PARTIAL is working as intended, so I'll just modify it on my end to allow for the allocation to be in PSRAM