ePicasso 2D / 2.5D 图形引擎¶

简介¶

ePicasso 是思澈科技（SiFli）面向 SF32 微控制器系列的 2D/2.5D 图形加速引擎。它将受支持的重复像素处理交由硬件执行，从而减轻应用 CPU 的负担，让嵌入式 UI 能在 MCU 级功耗预算内实现流畅效果、灵敏交互和高效显示刷新。

在 SF32 图形流程中，ePicasso 位于资源可供渲染器使用之后、最终位图送入显示控制器之前，负责加速图像复制、混合、缩放、旋转和图层合成等像素处理。资源解压由 eZip 完成，解压后的图像数据也可以直接交给 ePicasso 处理；准备好的像素则由显示控制器传输到面板。完整的资源到面板路径请参阅图形概览。

应用通常不会直接逐条编排 ePicasso 操作。更常见的方式是由 LVGL 或厂商图形库为常见 UI 操作生成绘制命令，再由 SF32 图形驱动将受支持的操作交给 ePicasso 执行，不支持的操作则回退到 CPU 渲染。

当 UI 性能分析发现复制、填充、Alpha 混合、缩放、旋转或合成已成为响应速度或功耗方面的瓶颈时，可以参考本页。本文将帮助固件工程师判断哪些操作可以交由硬件加速，以及哪些操作需要保留正确的 CPU 回退路径。

为什么硬件图形加速很重要¶

嵌入式 UI 的性能瓶颈往往不在 CPU 指令吞吐，而在内存搬运。即使一个简单的半透明图标，也可能需要对每个受影响像素读取源图像、读取帧缓冲区、执行混合运算，再写回帧缓冲区。

ePicasso 通过加速整套 UI 中反复出现的像素操作，来改善这一问题：

• 复制图像块和帧缓冲区区域。
• 填充矩形和 UI 背景。
• 对图标、文字蒙版、阴影和覆盖层执行 Alpha 混合。
• 为响应式布局和动画缩放位图。
• 旋转或变换图像区域。
• 把多个图层合成为最终显示缓冲区。
• 在器件和驱动支持时执行常见像素格式之间的转换。

实际收益不只在于提高帧率：硬件加速还能降低 CPU 占用、改善触控响应速度，并让系统更容易在两次显示更新之间进入较低功耗状态。

减轻 CPU 负担并不一定能降低系统总能耗。加速器时钟、内存流量、同步和驱动开销可能抵消 CPU 的节能收益。应在目标硬件上比较完成一次屏幕更新的能耗，并将显示运行期间和更新间隔内的能耗一并计入；不要仅凭 CPU 占用率判断能效。

核心渲染概念¶

图形表面（Surface）与帧缓冲区（Framebuffer）¶

图形表面（Surface） 是一块矩形像素内存区域，可以代表整屏帧缓冲区、局部绘制缓冲区、图像资源、画布或中间图层。ePicasso 操作通常会从一个或多个源图形表面读取像素，并将结果写入目标图形表面。

应将图形表面放在与其访问模式匹配的内存中：

• 频繁更新的绘制缓冲区通常更适合放在足够大的内部 SRAM 中。
• 大尺寸图像、字体和 UI 资源可能存放在 Flash 或 PSRAM 中。
• 较高分辨率显示所需的整屏帧缓冲区可能需要 PSRAM。
• DMA 可见缓冲区必须遵循 SDK 的内存布局和缓存一致性规则。

像素混合¶

混合用于把源像素与目标像素结合起来，是现代 UI 中半透明卡片、柔和阴影、抗锯齿字形、覆盖层和淡入淡出动画的基础。

常见混合场景包括：

• 整层淡入淡出使用的常量 Alpha 混合。
• 用于 PNG 类图像和抗锯齿图标的逐像素 Alpha 混合。
• 用于文字、图形或单色资源的基于蒙版的混合。

当 ePicasso 在硬件中完成这些混合运算时，CPU 就不必再对受影响区域的每个像素重复执行相同的算术操作。

缩放与旋转¶

缩放和旋转广泛出现在动画界面和响应式布局中。硬件缩放可用于缩放（zoom）效果、预览缩略图、调整图标尺寸，或让资源适配不同的屏幕密度。旋转适用于屏幕方向切换、旋转仪表和表盘元素，以及某些过渡效果。

这些操作对带宽很敏感。实际收益取决于源格式和目标格式、缓冲区的内存布局，以及图形驱动能否调用硬件支持的对应操作。

图层合成¶

很多界面由多个视觉图层组成，例如背景、图像资源、文本、状态指示、弹窗和动画覆盖层。图层合成就是把这些元素组合成最终可见的画面。

ePicasso 的设计重点之一是加速这种 2D 合成过程。UI 框架可以只更新需要重绘的区域，再利用加速器合成发生变化的像素，而不必在软件中重绘整屏。

2D 与 2.5D 图形¶

2D 图形 通常指在平面矩形图像上执行的复制、填充、混合、缩放、旋转和合成等操作。

2.5D 图形 则指仍然输出到 2D 帧缓冲区，但增加了某种变换或透视感的效果。在嵌入式 UI 设计中，这可能表现为经过变换的图像区域、更丰富的转场效果，或不依赖完整 3D 渲染管线却能营造景深感的视觉效果。

对于 SF32 文档，ePicasso 应主要理解为一种 2D/2.5D UI 加速器，而不是桌面级、可编程的 3D GPU。它的定位是让嵌入式界面更流畅、更节能，尤其适用于可穿戴设备、智能控制终端、手持设备和紧凑型仪表盘上的显示场景。

ePicasso 配置对比¶

比较芯片时，应看各系列的具体实现，而不能只看引擎名称。显示分辨率、图层数量、支持的格式、eZip 功能、外部存储带宽和驱动支持，还取决于所选 SF32 器件、封装、SDK 和板级设计。思澈科技（SiFli）的 SF32LB52x 产品简介将其引擎称为 ePicasso 2.0。SF32LB56x 数据手册记载了 4 个前景图层、1 个专用蒙版图层和 1 个单色背景图层；其中将 TurboPixel 作为 LCD 控制器中的独立帧缓冲压缩功能介绍。SF32LB58x 数据手册则列出了 ePicasso 2.0 和独立的 Vivante GCNanoUltraV 矢量图形引擎。

这张表不是性能排名。针对具体产品，应核实所选芯片支持的像素格式、图层数量和分辨率限制、eZip 功能、可用帧缓冲内存、显示接口带宽，以及 SDK 驱动的支持范围。

SDK 的 EPIC 功能表显示，所列系列均支持水平镜像，但只有 SF32LB52x 和 SF32LB57x 支持垂直镜像。因此，不能把未注明方向的“镜像”理解为两个方向都支持。该表还注明，EZIP、JPEG 和 YUV 输入不支持旋转和矩阵变换。

EZIP 直接向 EPIC 输出解压数据时，不必先将完整图像存入中间帧缓冲区；但仍需要解码器工作内存和最终绘制缓冲区。JPEG 解码不是 EZIP 的功能。SDK 将 JPEG 列为 SF32LB57x 上 EPIC 支持的输入格式，同时还提供独立的 JPEGD HAL 例程，展示如何通过 HAL_JPEGD 解码 JPEG 图像。这是两条分别记载的路径；具体应用应核实实际采用的处理链路。

这个针对静态 JPEG 图像的例程并不能证明 JPEGD 能解析 MJPEG 视频流。SDK 在独立的 FFmpeg 视频中间件说明中介绍了 MJPEG，并指出其 MJPEG 配置下的硬件解码仅在 SF32LB58x 平台上可用。

选择加速路径前，还应核对格式限制和各芯片系列的差异。请查阅上游 EPIC 功能表和 JPEGD 接口。

ePicasso 在 SF32 系列中的定位¶

不同的 SF32 器件集成不同配置的 ePicasso。最终功能集应以所选芯片的数据手册和参考手册为准。

这种演进让开发者可以在整个 SF32 系列中沿用相近的图形软件模型，同时根据显示分辨率、内存容量、图形复杂度、GPIO 数量和功耗预算选择合适器件。

与 LVGL 和 UI 框架的集成¶

LVGL 是 SF32 器件上常见的嵌入式图形界面方案。应用通过控件、样式、图像、字体和动画构建界面。LVGL 判断哪些区域需要重绘，再由软件渲染器或硬件绘制后端生成像素。显示驱动的 flush 路径将这些已渲染的像素传输到面板，并通知传输完成。渲染完成和显示传输完成是两个不同的事件，不能混为一谈。

当 SF32 上的 LVGL 移植层将受支持的绘制操作交给硬件执行时，ePicasso 可以提升 LVGL 性能。最常见、最有价值的加速点通常包括：

• 图像块复制（blit）。
• 颜色填充。
• Alpha 混合。
• 图像缩放。
• 对受支持图像区域进行旋转或变换。
• 在绘制缓冲区或帧缓冲区中执行合成。

成熟的 LVGL 集成仍应保留 CPU 回退路径。并不是每一种 LVGL 特性、像素格式、样式效果或图像布局都有对应的硬件操作。应优先加速高频、大数据量操作，少见或难以用硬件实现的情况仍由软件处理。

内存与带宽注意事项¶

图形加速并不能免去对内存的精心设计。在很多嵌入式显示系统中，真正受限的资源是内存总线：ePicasso、CPU、显示控制器、DMA 引擎、Flash、PSRAM、音频和无线子系统都可能争用访问。

良好的图形性能通常取决于以下设计选择：

• 选择符合产品需求的显示分辨率和色深。
• 把常用 UI 资源放在访问延迟（latency）可接受的存储位置。
• 在不需要整屏刷新的情况下使用局部渲染或脏区更新。
• 避免在热路径中进行不必要的格式转换。
• 按照 SDK 建议对齐绘制缓冲区和帧缓冲区。
• 当 CPU、ePicasso 和显示控制器共享缓冲区时，明确处理 DMA 和缓存一致性规则。

CPU 与 ePicasso 共享可缓存缓冲区时，应遵循 SDK 的缓存维护和所有权规则。硬件读取 CPU 写入的源数据前，应 clean 相关缓存行；硬件写入目标缓冲区前，应按 SDK 规则处理 CPU 中可能存在的脏缓存行，避免这些缓存行随后回写并覆盖硬件结果。等待硬件操作完成后，在 CPU 读取结果前 invalidate 过期缓存行。注意缓存行对齐和相邻数据，硬件持有缓冲区期间不要修改其中的数据。共享缓冲区的处理流程请参阅图形概览。

图形概览中的职责划分，是分析 UI 性能问题的关键。屏幕更新变慢可能由渲染时间、内存带宽、面板传输速率、显示接口配置或同步策略造成。ePicasso 在渲染成为瓶颈时最有效；若瓶颈在面板传输，局部刷新、更低色深、不同的缓冲策略或更快的显示接口通常更重要。

典型应用场景¶

当产品界面视觉元素很多，但系统仍需控制在微控制器级功耗预算内时，ePicasso 的价值最明显。

典型应用场景包括：

• 智能手表表盘和应用界面。
• 健身追踪器和可穿戴健康监测设备的显示界面。
• 蓝牙音频产品的用户界面。
• 电动自行车（eBike）、电动滑板车（eScooter）和紧凑型车辆仪表盘。
• 智能家居控制器和小型触摸面板。
• 便携式医疗或工业仪器。
• 标签打印机、智能工牌和电子货架标签。
• 带图标、透明效果和动画的 LVGL 型 HMI。

实用设计建议¶

应从显示和用户体验需求出发，再倒推图形架构。

关键问题包括：

• 显示分辨率和色深是多少？
• 面板通过 SPI、QSPI、8080、RGB/DPI、MIPI DSI、EPD 还是 JDI 更新？
• 产品需要整屏动画，还是大多数情况下只做局部更新？
• UI 资源放在内部 SRAM、Flash 还是 PSRAM 中？
• 绘制缓冲区或帧缓冲区可用的内存有多少？
• 哪些操作可以通过 ePicasso 由图形驱动加速？
• CPU、ePicasso 与显示控制器之间共享的缓冲区是否满足缓存一致性要求？

对很多产品来说，最佳结果往往来自多种手段结合：硬件加速绘图、局部刷新、压缩或优化图形资源、合理的缓冲区布局，以及避免不必要整屏重绘的 UI 设计。

要点¶

• ePicasso 是思澈科技（SiFli）面向 SF32 微控制器的 2D/2.5D 图形加速器。
• 它能替 CPU 执行填充、复制、混合、缩放、旋转和图层合成等常见像素操作。
• 它与显示控制器协同工作：ePicasso 负责准备像素数据，显示控制器负责把数据发送到面板。
• 对界面视觉元素较多的产品，它的价值更明显：内存搬运、混合和重复像素处理原本会占用大量 CPU 时间。
• 当 SF32 图形驱动把受支持的绘制操作映射到硬件时，LVGL 和其他 UI 框架都能从 ePicasso 中受益。
• 实际性能仍然取决于显示分辨率、内存布局、像素格式、缓冲策略、缓存处理和面板接口带宽。

最后更新: 2026-10-21