TurboPixelフレームバッファー圧縮¶

概要¶

TurboPixelは、対応するSF32デバイス上で描画済みの最終画像を圧縮する、固定比率の非可逆圧縮フォーマットです。表示経路の一部であり、extDMAがビットマップを圧縮し、ディスプレイコントローラーがピクセルをパネルに転送する際にTurboPixelを展開します。

TurboPixelはアセット保存用のフォーマットではなく、eZipを置き換えるものでもありません。eZipはソースアセットを、ストレージから読み出す前の段階で可逆圧縮します。一方TurboPixelは描画後の最終ビットマップを圧縮し、フレームバッファーの割り当て容量と表示時の読み出し帯域幅を削減します。

完全なグラフィックスフローと、eZip、ePicasso、ディスプレイコントローラーに対するTurboPixelの位置づけについては、グラフィックス概要を参照してください。このページは、TurboPixelの圧縮挙動、統合上のトレードオフ、利用可否に焦点を当てています。

SF32LB55x、SF32LB56x、SF32LB58xを使った設計で、フレームバッファー容量やディスプレイによる読み出しデータ量がボトルネックになる場合に、本ページを参照してください。製品開発者やファームウェアエンジニアが、予測しやすいPSRAM削減効果と非可逆圧縮による画質劣化を比較検討するのに役立ちます。eZipによるアセット圧縮の代替にはなりません。

固定圧縮率と非可逆圧縮¶

TurboPixelには次の二つの特徴があります。

**設定ごとに固定される圧縮率。**入力の画素形式と圧縮レベルで公称の圧縮率が決まり、画像の細かさでは変わりません。ただし、必要なメモリー量には行のアラインメントと分割方法も影響します。他の設定の圧縮率を流用せず、対象チップとSDKのサイズ計算に従ってください。
**非可逆圧縮。**展開後に元の全画素値が再現されるとは限りません。一定の画質低下と引き換えに、PSRAMの使用量と転送量を見積もりやすくする形式です。

リソースが限られる組み込み表示システムでは非可逆圧縮が有効な場合がありますが、許容できる画質は製品要件で決まります。一般的なテスト画像だけで判断せず、対象パネルの解像度、色深度、想定視距離、リフレッシュ動作を考慮して実際の画面を評価してください。

フレームバッファー圧縮の比較（記入用）¶

このセクションには、代表的なディスプレイ解像度とSDK構成で測定したTurboPixelの結果を記録してください。eZipのファイルサイズ比較とは異なり、ここではフレームバッファーのメモリー使用量とPSRAMのデータ転送量を比較します。TurboPixelが処理するのはソースアセットファイルではなく、レンダリング後のビットマップです。

不透明な画面と、アルファブレンドを使う画面の両方を測定してください。通常、前景と背景の合成はTurboPixel圧縮前の描画段階で行います。半透明のアイコン、文字、影、レイヤーを使っていても、最終フレームバッファーは不透明なRGB565画像になる場合があります。元のリソースにアルファがあっても、圧縮フレームバッファーがアルファチャンネルを持つとは限りません。入力と最終出力を区別して記録してください。

代表的なTurboPixelフレームバッファーの測定用テンプレート

シナリオ	ソース/レイヤーのアルファ	最終フレームバッファーのフォーマットとアルファ状態	非圧縮時の確保容量/転送量	TurboPixelの確保容量/転送量	非圧縮に対する相対値	テスト設定/視覚的な結果
不透明UI	なし	未確定、不透明	要測定	要測定	要測定	解像度、リフレッシュポリシー、TurboPixel比率/構成：要確認
出力前に合成されたアルファブレンドUI	ソースレイヤー内のピクセル単位および/またはグローバルアルファ	未確定（合成後は通常不透明）	要測定	要測定	要測定	ブレンド内容を記録し、エッジ、影、グラデーション、文字のアーティファクトを確認
アルファ保持出力パス（対応する場合）	最終バッファーまでアルファを保持	未確定	要測定	要測定	要測定	テスト前に対象チップ、SDK、フォーマット、表示経路を確認

対応する各TurboPixel経路で、非圧縮に対する相対値をTurboPixel framebuffer bytes ÷ uncompressed framebuffer bytes × 100%として計算してください。確保容量は選択した固定圧縮率に基づきますが、実際の圧縮率、対応形式、アラインメント、リフレッシュポリシーはチップ資料とSDKで確認し、PSRAM転送量は実機で測定します。画質の合否は別に記録してください。同じ圧縮設定でも、不透明な画面、文字の多い画面、グラデーション、アルファブレンドで、目立つ画質劣化は異なります。

TurboPixelを使う理由¶

フレームバッファーの保存容量を減らす¶

高解像度の全画面バッファーや複数の描画バッファーは、多くのPSRAMを使用します。TurboPixelは圧縮後の最終画像の保存容量を減らし、UIリソース、オーディオ、アプリケーションデータ、他の描画領域にメモリーを回せます。

ただし、圧縮画像だけでなく同時に使用する全バッファーのピーク容量を見積もってください。非圧縮の描画バッファー、圧縮済みの表示バッファー、圧縮処理の作業領域、ダブルバッファーの複製が共存する場合があります。システム全体でPSRAMが減るかどうかは、それぞれの容量と保持期間で決まります。

表示読み出し量を減らす¶

ディスプレイコントローラーが圧縮フレームバッファーから読み出すデータ量は少なくなります。表示用の読み出しを減らせるため、CPU、ePicasso、DMA、オーディオ、無線通信とのメモリー帯域の競合を抑えられます。

ただし、これは総転送量の削減率ではありません。描画時の画素書き込みに加えて、圧縮処理も入力の読み出しと出力の書き込みを行います。それぞれの転送量と、表示読み出しとの重なりを測定してください。頻繁に再描画する画面では圧縮の負荷が読み出し削減効果を相殺する可能性があり、同じフレームを繰り返し表示する場合とは条件が異なります。帯域だけでなくシステムの消費エネルギーも測定してください。

メモリーと帯域幅の予算を予測しやすくする¶

画素形式と圧縮レベルが同じなら、内容が変わっても公称の圧縮率は変わりません。SDKの圧縮後の行サイズとアラインメントに従ってバッファーを確保し、帯域には描画・圧縮・表示の全読み書きを含めてください。パネルへの転送量は別に計算します。TurboPixelはパネル出力前に展開されるため、その転送量まで自動的に減るわけではありません。

品質と統合のトレードオフ¶

TurboPixelは表示システム全体で検証してください。

テキスト、細い線、グラデーション、アイコン、写真、アニメーション、ハイコントラストのUI要素で、目に見えるアーティファクトをテストしてください。
選択したデバイスとSDKがサポートするカラーフォーマット、バッファーアラインメント、extDMAパス、ディスプレイコントローラー構成を確認してください。
ディスプレイ、Bluetooth、オーディオ、AIの組み合わせワークロード下で、フレーム時間、PSRAM帯域幅、UIレイテンシ、電力を測定してください。
画質やドライバーの問題を切り分けられるように、立ち上げ中は非圧縮パスを利用可能な状態にしておいてください。
特定のUIでアーティファクトが見えない場合でも、TurboPixelを可逆であるかのように提示しないでください。

SDK統合時の確認事項¶

参照先のextDMAガイドには公称の圧縮レベルが10段階ありますが、参照先SDKのサイズ計算はレベル1、2、3を実装しています。資料にある全レベルを現在のビルドで使用できるとは限りません。選択したレベルと行サイズの計算を確認してください。未対応の値を渡すと、補助関数によっては別の設定に切り替わることがあります。

extDMAガイドはRGB565、RGB888、ARGB8888入力を挙げています。ただし、入力形式への対応だけで圧縮表示経路がアルファを保持するとは判断できません。専用のレイヤー0展開レジスターを使わないLCDCの分岐は、圧縮レイヤーにRGB565/RGB888のみを受け付けます。対象チップの分岐を確認してください。参照先のLCDCドライバーでは、HAL_LCDC_LayerSetCmprでレイヤー0の圧縮を有効にします。

現行のOpenSiFli LCDCヘッダーは、HAL_EXTDMA_MODULE_ENABLEDが有効な場合にのみ圧縮レイヤーのサポートマクロを定義し、チップ系列の条件でSF32LB52xとSF32LB57xを除外します。ヘッダーで定義される圧縮レイヤーの最大幅は、SF32LB55x/SF32LB56xが512画素、SF32LB58xが1024画素です。これは圧縮レイヤーの統合上の制限で、パネル解像度全般の上限ではありません。ソースコメントにはLCPU側では有効化されていないとの記載もあります。

SF32LB55xの統合には注意が必要です。現行のOpenSiFli LCDCヘッダーはHAL_EXTDMA_MODULE_ENABLEDが有効な場合に圧縮レイヤーのマクロを定義しますが、コメントではLCPU側で有効化されていないとされています。一方、公開SDKのLCDC機能表では55xの圧縮レイヤー展開が非対応とされ、SF32LB55xのデータシートにはTurboPixelとLCDコントローラーによる展開が記載されています。コンパイル時のマクロだけでは、表示経路全体が検証済みとは判断できません。55xは条件付きとして扱い、SDKの版、コア、ビルド設定、実機で経路全体を検証してください。

描画側、extDMA、ディスプレイコントローラーの間でバッファーの使用権を明確にしてください。描画完了後に圧縮し、圧縮完了後に表示に使用し、表示側の使用が終わってから再利用します。キャッシュ対象の共有メモリーでは、ハードウェアが読む前にCPUの書き込みをメモリーへ反映します。出力先のキャッシュラインは、未反映のデータが後から書き戻されてハードウェアの結果を壊さないよう事前に処理し、完了後にCPUが読む前に無効化します。キャッシュライン境界と隣接データにも注意してください。圧縮完了とパネル転送完了は別のタイミングです。

extDMAの入力アドレス、出力アドレス、転送長は4バイト単位で整列する必要があります。SDKの行ストライド、分割、バッファーサイズの計算に従ってください。元フレームのバイト数を公称圧縮率で割るだけでは不十分です。

SF32ファミリーにおける利用可否¶

資料に記載されているSF32各ファミリーのTurboPixel対応状況は次のとおりです。

TurboPixelの対応状況（文書に記載された情報）

SF32ファミリー	TurboPixelの状態	実装上の要点
SF32LB52x	利用不可	非圧縮フレームバッファー、または他のサポートされているメモリー/帯域幅戦略を使用してください。
SF32LB55x	現行ソースでは条件付き；経路全体の動作は未確認	現行LCDCヘッダーはextDMA有効時に圧縮レイヤー機能を定義しますが、LCPU側は未有効とのコメントがあり、公開SDK機能表では55xが非対応です。対象コア、SDK設定、実機で確認してください。
SF32LB56x	文書に記載	extDMAが最終フレームバッファーを固定比率で非可逆圧縮し、ディスプレイコントローラーが展開します。
SF32LB57x	利用不可	非圧縮フレームバッファー、または他のサポートされているメモリー/帯域幅戦略を使用してください。
SF32LB58x	文書に記載	extDMAが最終フレームバッファーを固定比率で非可逆圧縮し、ディスプレイコントローラーが展開します。
その他のSF32ファミリー	デバイスごとに確認	eZip、ePicasso、あるいはPSRAMの存在からTurboPixelのサポートを推測しないでください。対象チップのデータシート、リファレンスマニュアル、SDKリリース、ディスプレイドライバーを確認してください。

この表は、文書化されているファミリーレベルの利用可否を記録するものであり、すべてのパッケージ、パネルインターフェース、ピクセルフォーマット、SDKバージョン、ボード構成についての保証ではありません。メモリーまたは帯域幅に関する判断を確定する前に、対象構成を確認してください。

要点のまとめ¶

TurboPixelは、固定比率かつ非可逆な最終フレームバッファー圧縮フォーマットです。
extDMAがレンダリングされたビットマップからTurboPixelを生成し、ディスプレイコントローラーがパネルへの出力経路上でそれを展開します。
主な目的は、フレームバッファーの保存容量と表示読み出し量の削減です。全バッファー構成と転送経路を含めて効果を確認してください。
TurboPixelはSF32LB55x、SF32LB56x、SF32LB58xについて資料に記載があります。55xでは現行ヘッダーがextDMA有効時に圧縮レイヤーのマクロを定義しますが、LCPU側は未有効とのコメントがあり、公開SDK機能表は非対応としています。55xは条件付きとして扱い、表示経路全体を検証してください。現行ソースではSF32LB52xとSF32LB57xは対象外です。他の対象デバイスも個別に確認してください。
TurboPixelはeZipを補完します。eZipは可逆なアセット圧縮であり、TurboPixelは最終ビットマップのための非可逆圧縮です。

一次資料¶

最終更新: 2026-10-19