ePicasso 2D / 2.5Dグラフィックスエンジン¶
はじめに¶
ePicassoは、SF32マイクロコントローラーファミリー向けのSiFli製2D/2.5Dグラフィックスアクセラレーターです。対応する反復的なピクセル処理をアプリケーション側CPUからオフロードし、MCUクラスの電力予算内で滑らかな描画、すばやい操作応答、効率的な画面更新を実現します。
SF32のグラフィックス処理では、ePicassoはレンダラーがリソースを利用できる状態になった後、最終ビットマップをディスプレイコントローラーへ渡す前に動作します。画像のコピー、ブレンディング、拡大縮小、回転、レイヤー合成などを高速化します。リソースの解凍はeZipが行い、解凍した画像データをePicassoへ渡すこともできます。準備されたピクセルをパネルへ転送するのはディスプレイコントローラーです。リソースからパネルまでの流れはグラフィックス概要を参照してください。
アプリケーションが個々のePicasso処理を直接呼び出すことは通常ありません。LVGLなどのグラフィックスフレームワークやベンダーのグラフィックスライブラリが、UI描画に必要なコマンドを生成します。SF32のグラフィックスドライバーは対応する処理をePicassoに振り分け、未対応の処理はCPUによる描画に切り替えます。
UIのプロファイリングで、コピー、塗りつぶし、アルファブレンド、拡大縮小、回転、合成が応答性や消費電力のボトルネックと分かった場合に参照してください。どの処理をハードウェアで高速化できるか、どの処理にCPUでの代替経路を残すべきかを判断するのに役立ちます。
ハードウェアグラフィックスアクセラレーションが重要な理由¶
組み込みUIの性能は、CPUの命令処理能力よりも、メモリー内のデータ転送に制約されることがよくあります。単純な半透明のアイコンであっても、対象の各ピクセルについて、入力画像とフレームバッファーの読み取り、ブレンディング、フレームバッファーへの書き込みが必要になる場合があります。
ePicassoは、ユーザーインターフェース全体に現れる繰り返しのピクセル演算を高速化することでこの状況を改善します。
- 画像ブロックとフレームバッファー領域のコピー。
- 矩形とUI背景の塗りつぶし。
- アイコン、テキストマスク、影、オーバーレイのアルファブレンディング。
- 画面サイズに応じたレイアウトやアニメーションに使うビットマップの拡大縮小。
- 画像領域の回転または変換。
- 最終的なディスプレイバッファーへの複数レイヤーの合成。
- デバイスとドライバーがサポートする場合の、一般的なピクセルフォーマット間の変換。
その利点はフレームレートだけにとどまりません。ハードウェアアクセラレーションはCPU使用率を下げ、タッチへの応答性を高め、ディスプレイ更新の合間にシステムが低消費電力状態へ移行しやすくすることもできます。
CPUの処理負荷が減っても、システム全体の消費エネルギーが必ず減るとは限りません。アクセラレーターのクロック、メモリーアクセス、同期、ドライバーのオーバーヘッドでCPU側の省エネルギー効果が相殺されることがあります。CPU使用率だけで判断せず、実機で画面更新1回あたりのエネルギーを比較し、表示とアイドル期間も含めて評価してください。
レンダリングの中核概念¶
サーフェスとフレームバッファー¶
サーフェスは、ピクセルメモリーの矩形領域です。全画面フレームバッファー、部分描画バッファー、画像アセット、キャンバス、あるいは中間レイヤーを表す場合があります。ePicassoの演算は一般的に、1つ以上のソースサーフェスからピクセルを読み取り、宛先サーフェスにピクセルを書き込みます。
サーフェスは、そのアクセスパターンに合ったメモリーに配置してください。
- 頻繁に更新される描画バッファーは、十分な容量がある場合は高速な内部SRAMから恩恵を受けることが多い。
- 大きな画像、フォント、UIアセットはFlashまたはPSRAMに置かれる場合がある。
- より高解像度のディスプレイ向けの全画面フレームバッファーは、PSRAMが必要になる場合がある。
- DMAから見えるバッファーは、SDKのメモリーとキャッシュコヒーレンシのルールに従わなければならない。
ブレンディング¶
ブレンディングは、ソースピクセルと宛先ピクセルを組み合わせます。これは、半透明のカード、柔らかい影、アンチエイリアスされたグリフ、オーバーレイ、フェードアニメーションといった現代的なUI要素に不可欠です。
一般的なブレンディングのケースには次のものがあります。
- レイヤー全体をフェードさせる定数アルファブレンディング。
- PNG風の画像やアンチエイリアスされたアイコンのためのピクセル単位のアルファブレンディング。
- テキスト、形状、モノクロアセットのためのマスクベースのブレンディング。
ブレンディングをePicassoがハードウェアで処理すれば、CPUが対象領域の各ピクセルに同じ演算を繰り返す必要がなくなります。
スケーリングと回転¶
拡大縮小や回転は、アニメーションを含む画面や、画面サイズに応じて調整するレイアウトでよく使われます。ハードウェアによる拡大縮小は、ズーム効果、プレビュー用サムネイル、アイコンのサイズ調整、異なる画面密度へのリソース適合などに利用できます。回転は、画面の向きの変更、計器や時計盤の要素、特定の画面遷移に役立ちます。
これらの処理ではメモリー帯域幅が重要です。効果は、入力元と出力先の形式、メモリー配置、そしてグラフィックスドライバーがその処理を対応するハードウェア機能に割り当てられるかどうかによって変わります。
レイヤー合成¶
多くの画面は、背景、画像リソース、テキスト、状態表示、ポップアップ、アニメーションのオーバーレイなど、複数のレイヤーで構成されます。レイヤー合成では、これらを組み合わせて最終的な表示を生成します。
ePicassoは、このような2D合成を高速化するよう設計されています。ソフトウェアで画面全体を再描画する代わりに、UIフレームワークは再描画が必要な領域だけを更新し、アクセラレーターで変更されたピクセルを効率的に合成できます。
2Dグラフィックスと2.5Dグラフィックス¶
2Dグラフィックスは通常、平面上の矩形画像に対するコピー、塗りつぶし、ブレンド、拡大縮小、回転、合成などの処理を指します。
2.5Dグラフィックスは、2Dフレームバッファーに描画しながら、変形や遠近感のような効果を加える表現を指します。組み込みUIでは、画像領域の変形や凝った画面遷移など、フル3Dの描画パイプラインを使わずに視覚的な奥行きを表現する機能がこれに含まれる場合があります。
SF32の資料では、ePicassoはデスクトップ向けのプログラマブル3D GPUではなく、主に2D/2.5D UIアクセラレーターとして位置付けられています。ウェアラブル、スマートコントローラー、携帯機器、コンパクトなダッシュボードなどの組み込み画面を、より滑らかに、より少ない電力で動かすことを目的としています。
ePicasso実装の比較¶
デバイスを比較するときは、エンジン名だけでなく各デバイスファミリーの実装を確認してください。解像度、レイヤー数、対応形式、eZipの機能、外部メモリー帯域幅、ドライバーの対応範囲は、選択するSF32デバイス、パッケージ、SDK、基板設計によっても異なります。SiFliのSF32LB52x製品概要ではエンジン名をePicasso 2.0と記載しています。SF32LB56xデータシートには、前景4レイヤー、専用マスクレイヤー1つ、単色背景レイヤー1つが記載されています。TurboPixelはLCDコントローラーの独立したフレームバッファー圧縮機能として別に説明されています。SF32LB58xデータシートには、ePicasso 2.0と独立したVivante GCNanoUltraVベクターグラフィックスエンジンが記載されています。
| 資料に記載されたエンジン名 | 代表的なSF32ファミリー | グラフィックス機能 | 資料で確認できる主な特長 | 主な用途 |
|---|---|---|---|---|
| ePicasso | SF32LB55x | 2.5D UIアクセラレーション | ハードウェアによる回転、拡大縮小、水平ミラーリング、アルファブレンディング。垂直ミラーリングには非対応。eZipによるロスレスアセット処理 | エントリーレベルの設計よりも豊かなUIを必要とするBLEウェアラブルとコンパクトなHMI |
| ePicasso 2.0 | SF32LB52x | 2D/2.5D UIアクセラレーション | コストを抑えたグラフィックス構成でのeZip 2.0アセット解凍 | エントリーレベルのウェアラブル、Bluetooth製品、電子ペーパー、コンパクトなHMI |
| ePicasso 2.0 | SF32LB56x | 2D/2.5D UIアクセラレーション | アルファブレンド対応の前景4レイヤー、専用マスクレイヤー1つ、単色背景レイヤー1つに対応。ハードウェアによる回転/拡大縮小/水平ミラーリング(垂直ミラーリングには非対応)と形式変換、eZip 2.0に対応。フレームバッファー圧縮はePicassoとは別のTurboPixel機能が担います | 高解像度ディスプレイや高度なLVGL UIに適しています。具体的なデバイスとSDKで各操作の対応状況を確認してください。 |
| ePicasso 2.0 | SF32LB58x | 2D/2.5D UIアクセラレーション | ePicasso 2.0に加えて、独立したVivante GCNanoUltraVベクターグラフィックスエンジンを搭載します。各エンジンの機能は個別に確認してください。 | 高解像度でグラフィックスを多用する製品に適しています。対象SDKで各エンジンが対応する機能を確認してください。 |
| ePicasso (EPIC) | SF32LB57x | 2D/2.5D UIアクセラレーション | 回転、拡大縮小、行列変換、水平/垂直ミラーリング、アルファブレンディング、マルチレイヤー合成。EZIPは解凍したeZip/eZip-AリソースをEPICへ送ります。SF32LB57xではEPICがJPEG入力に対応し、SDKには独立したJPEGD HALデコーダーもあり、これは別の経路です | グラフィックスが豊富で、カメラ対応、マルチメディア指向の接続製品 |
この表はベンチマークによる性能順位を示すものではありません。製品設計では、対象チップが対応するピクセル形式、レイヤー数と解像度の上限、eZipの機能、利用可能なフレームバッファーメモリー、ディスプレイインターフェースの帯域幅、SDKドライバーの対応範囲を確認してください。
SDKのEPIC機能表では、記載された各シリーズが水平ミラーリングに対応し、垂直ミラーリングはSF32LB52xとSF32LB57xのみ対応しています。方向が明記されていない「ミラーリング」を、両方向への対応と解釈しないでください。同じ表では、EZIP、JPEG、YUV入力は回転および行列変換の対象外です。
EZIPからEPICへ直接出力する経路では、解凍した画像全体を中間フレームバッファーに保存する必要はありません。ただし、デコーダーの作業メモリーと最終描画バッファーは必要です。JPEGのデコードはEZIPの機能ではありません。SDKではJPEGをSF32LB57xのEPIC入力形式として記載する一方、SiFliのJPEGD HAL例ではHAL_JPEGDによるJPEG画像のデコードを個別に示しています。これらは資料上、別々に記載された処理経路です。アプリケーションが実際にどの経路を使うか確認してください。
このJPEG静止画像のデコード例は、JPEGDがMJPEGストリームをデコードすることを示すものではありません。SDKではMJPEGを独立したFFmpeg動画ミドルウェアの機能として説明し、そのMJPEG設定についてはハードウェアデコードがSF32LB58xのみで利用可能としています。
アクセラレーション経路を選ぶ前に、形式ごとの制限とファミリー間の違いも確認してください。上流のEPIC機能表とJPEGDインターフェースを参照してください。
SF32ファミリー全体にわたるePicasso¶
SF32の各デバイスには、それぞれ異なる構成のePicassoが搭載されています。最終的な機能は、選択したチップのデータシートとリファレンスマニュアルで確認してください。
| デバイスファミリー | グラフィックスアクセラレーター | 一般的な位置づけ |
|---|---|---|
| SF32LB52x | ePicasso 2.0 2D/2.5Dアクセラレーター | コスト最適化されたウェアラブル、Bluetooth、コンパクトなHMI製品。 |
| SF32LB55x | ePicasso 2.5Dアクセラレーター | ディスプレイを必要とするBLEウェアラブルおよびセンサーが豊富なデバイス。 |
| SF32LB56x | ePicasso 2.0 2D/2.5Dアクセラレーター | より高解像度のディスプレイ製品と、より高機能なLVGLベースのインターフェース。 |
| SF32LB57x | ePicasso (EPIC) 2D/2.5Dアクセラレーター | グラフィックスが豊富で、カメラ対応、マルチメディア指向の接続製品。 |
| SF32LB58x | ePicasso 2.0と独立したVivante GCNanoUltraVベクターグラフィックスエンジン | フラッグシップグラフィックス、高解像度UI、高度な視覚アプリケーション。 |
この製品展開により、開発者は共通性の高いグラフィックスソフトウェアモデルをSF32シリーズ内で活用しつつ、必要な解像度、メモリー容量、グラフィックス処理の複雑さ、GPIO数、消費電力に合ったデバイスを選べます。
LVGLおよびUIフレームワークとの統合¶
LVGLは、SF32で組み込みGUIを開発する際によく使われます。アプリケーションはウィジェット、スタイル、画像、フォント、アニメーションで画面を構成します。LVGLが再描画領域を決め、ソフトウェアレンダラーまたはハードウェア描画バックエンドがピクセルを生成します。ディスプレイドライバーの描画データ転送経路は、描画済みのピクセルをパネルへ転送し、完了を通知します。描画完了と表示データの転送完了は区別してください。
SF32向けのLVGLポートが対応する描画演算をハードウェアにルーティングする場合、ePicassoはLVGLの性能を改善できます。特に効果が期待できる処理は次のとおりです。
- 画像ブリット。
- カラー塗りつぶし。
- アルファブレンディング。
- 画像スケーリング。
- サポートされる画像領域の回転または変換。
- 描画バッファーまたはフレームバッファーへの合成。
堅牢なLVGL統合では、CPUによる代替処理も維持します。すべてのLVGL機能、ピクセル形式、スタイル効果、画像レイアウトをハードウェアで処理できるとは限りません。頻繁に使い、大量のデータを扱う処理を高速化し、まれなケースや複雑な処理はソフトウェアに任せてください。
メモリーと帯域幅に関する考慮事項¶
グラフィックスアクセラレーションは、慎重なメモリー設計の必要性を取り除くものではありません。多くの組み込みディスプレイシステムでは、メモリーバスが制約となるリソースです。ePicasso、CPU、ディスプレイコントローラー、DMAエンジン、Flash、PSRAM、オーディオ、ワイヤレスサブシステムはすべてアクセスを奪い合う可能性があります。
良好なグラフィックス性能は、いくつかの設計上の選択に依存します。
- 製品要件に合ったディスプレイ解像度と色深度を使用する。
- 頻繁に使用されるUIアセットを、許容できるアクセスレイテンシを提供するメモリー位置に保つ。
- 全画面リフレッシュが不要な場合は部分レンダリングまたはダーティリージョン更新を使用する。
- ホットパスでの不要なフォーマット変換を避ける。
- SDKの推奨に従って描画バッファーとフレームバッファーをアラインメントする。
- CPU、ePicasso、ディスプレイコントローラーの間でバッファーが共有される場合、DMAとキャッシュコヒーレンシのルールを明確に保つ。
CPUとePicassoでキャッシュ可能なバッファーを共有する場合は、SDKのキャッシュ管理と所有権の規則に従ってください。CPUが書いた入力データは、ハードウェアが読む前にクリーン(キャッシュの書き戻し)します。ハードウェアが出力バッファーに書き込む前に、SDKの規則に従ってバッファーを準備し、CPUのダーティなキャッシュラインが後から結果を上書きしないようにします。ハードウェアの処理完了後、CPUが結果を読む前に古いキャッシュラインを無効化(invalidate)します。キャッシュラインのアラインメントと隣接データに注意し、ハードウェアが所有するバッファーは変更しないでください。詳細はグラフィックス概要を参照してください。
グラフィックス概要に示す役割分担は、UI性能の問題を調べるうえで重要です。画面更新が遅い原因は、レンダリング時間、メモリー帯域幅、パネルへの転送速度、表示インターフェースの設定、同期方法などが考えられます。レンダリングがボトルネックならePicassoが有効ですが、パネルへの転送が遅い場合は、部分更新、色深度の低減、バッファー方式の変更、より高速なインターフェースの方が効果的なことがあります。
一般的なユースケース¶
ePicassoは、インターフェースに多くの視覚要素を含みながら、システムがマイクロコントローラーレベルの電力予算内に収まる必要がある製品において最も有用です。
代表的なユースケースには次のものがあります。
- スマートウォッチの時計盤とアプリ画面。
- フィットネストラッカーや、健康情報を表示するウェアラブル機器。
- Bluetoothオーディオのユーザーインターフェース。
- eバイク、eスクーター、コンパクトな車両ダッシュボード。
- スマートホームコントロールと小型タッチパネル。
- ポータブルな医療または産業用計器。
- ラベルプリンター、スマートバッジ、電子棚札。
- アイコン、透過性、アニメーションを持つLVGLベースのHMI。
実践的な設計ガイダンス¶
ディスプレイとユーザーエクスペリエンスの要件から始め、そこからグラフィックスアーキテクチャへと逆算してください。
重要な質問には次のものがあります。
- ディスプレイの解像度と色深度は何か。
- パネルはSPI、QSPI、8080、RGB/DPI、MIPI DSI、EPD、JDIのどれで更新されるか。
- 製品は全画面アニメーションを必要とするか、それとも主に部分更新か。
- UIアセットは内部SRAM、Flash、PSRAMのどこに保存されるか。
- 描画バッファーまたはフレームバッファーにどれだけのメモリーが利用可能か。
- グラフィックスドライバーはePicassoを通じてどの演算を高速化できるか。
- CPU、ePicasso、ディスプレイコントローラーのバッファーはキャッシュコヒーレントか。
多くの製品にとって、最良の結果は、ハードウェアアクセラレートされた描画、部分リフレッシュ、圧縮または最適化されたアセット、慎重なバッファー配置、不要な全画面再描画を避けるUI設計といった複数の手法を組み合わせることから得られます。
要点のまとめ¶
- ePicassoは、SF32マイクロコントローラー向けのSiFliの2D/2.5Dグラフィックスアクセラレーターです。
- 塗りつぶし、コピー、ブレンディング、拡大縮小、回転、レイヤー合成など、一般的なピクセル処理をCPUからオフロードします。
- ディスプレイコントローラーと連携して動作します。ePicassoがピクセルデータを準備し、ディスプレイコントローラーがそれをパネルに送信します。
- メモリー転送、ブレンディング、反復的なピクセル処理に多くのCPU時間を要する、UI処理の多い製品で特に効果を発揮します。
- SF32のグラフィックスドライバーが対応する描画処理をハードウェアに割り当てる場合、LVGLなどのUIフレームワークでもePicassoの効果を得られます。
- 実際の性能は、ディスプレイ解像度、メモリー配置、ピクセル形式、バッファー戦略、キャッシュ管理、パネルインターフェースの帯域幅に左右されます。
最終更新: