概要

Infineon のTRAVEO T2Gボードは、かなりユニークなレイヤーおよびグラフィックスドライバのアーキテクチャを採用しています。このガイドでは、これらのボードにおけるグラフィックス性能とVRAMメモリ使用量の最適化方法について説明します。

背景知識として、まず「ハードウェアレイヤーを使用したパフォーマンスの向上」ページで解説されている、ハードウェアレイヤーの基本概念について理解しておくことをお勧めします。

Infineon TRAVEO T2Gのハードウェアレイヤー

TRAVEO T2Gには、以下のハードウェアレイヤータイプがあります：

画像レイヤー

このレイヤータイプでは、アドレス指定可能な内部または外部フラッシュメモリからピクセルデータを直接読み出すことができ、静的な背景や前景の画像データに適しています。これは、ImageLayer というQMLタイプに対応しています。

IBOレイヤー

IBOレイヤーは、VRAM内のダブルバッファ化されたフレームバッファで構成されます。TRAVEO T2Gのグラフィックスエンジンは、フロントバッファが最終的な表示画像に合成されている間、バックバッファに直接描画を行います。

IBOレイヤーのタイプを設定するには、NoRenderingHint というレンダリングヒントが使用されます：

ItemLayer {
    renderingHints: ItemLayer.NoRenderingHint
}

ダブルバッファリングのため、1ピクセルあたり2バイトの800x480 IBOレイヤーのメモリ使用量は次のようになります：

幅 × 高さ × バッファ数 × ピクセルあたりのビット数 = 800 × 480 × 2 × 2 バイト = 1.54 MB

LBOからメモリへのレイヤー

IBOレイヤーと同様に、LBOからメモリへのレイヤーもVRAM内のダブルバッファリングされたフレームバッファで構成されています。 違いは、TRAVEO T2Gのブリットエンジンが描画コマンドをバッファに蓄積し、それらを1行ずつバックバッファに再描画する点にあります。これにより、いくつかの最適化が可能になり、オーバードローを削減できますが、単純なUIでは不要となる可能性のある一定のオーバーヘッドが発生します。

LBOレイヤーのタイプを設定するには、OptimizeForSpeed というレンダリングヒントを使用します。

ItemLayer {
    renderingHints: ItemLayer.OptimizeForSpeed
}

LBOからメモリへのレイヤーのメモリ使用量は、IBOレイヤーと同じです。

OTFレイヤー

OTF（オン・ザ・フライ）レイヤーは、LBO to display とも呼ばれ、動的にレンダリングされたコンテンツを表現するためにピクセルデータのダブルバッファ化されたフレームバッファを必要としないという点で独特です。その代わりに、各フレームごとにコマンドバッファが保持され、そのフレームがアクティブな限り、画面のリフレッシュレートに合わせて再生されます。 コマンドバッファのエントリは、どのブレンド演算を、どのソース画像データに対して実行するかを指定します。

各画面リフレッシュ時のコマンドバッファのレンダリングは、循環型ラインバッファを介して行われます。ラインバッファの高さは、32、64、128、またはその他の2の冪でなければなりません。TRAVEO T2Gのブリットエンジンはラインバッファの先頭に書き込みを行う一方、表示データは末尾から読み出されます。

コマンドバッファのエントリはソース画像データへの参照を保持しているため、Qt Quick Ultralite Core ライブラリは、その画像データを参照するフレームがアクティブな間は、画像データが解放されないようにする必要があります。

レンダリングヒント「OptimizeForSize 」は、OTFレイヤーのタイプを設定するために使用されます。これはデフォルトのレンダリングヒントであるため、明示的に設定する必要はありません。

ピクセルあたり 24 ビット（ピクセルあたり 3 バイト）の色深度を持つ 800x480 の OTF レイヤーのメモリ使用量は、ラインバッファの高さを 64 ピクセル、コマンドバッファを 64 KB と仮定すると、次のようになります。

幅 × ラインバッファの高さ × バッファ数 × ピクセルあたりのビット数 + コマンドバッファのサイズ = 800 × 64 × 3 バイト + 64 KB = 219 KB

プラットフォームの制限

最大レイヤー数およびその他のTRAVEO T2Gのレイヤー関連の制限については、Infineon の「TRAVEO T2Gプラットフォームの制限事項」を参照してください。

ラインバッファの概要

この図は、ラインバッファの通常の動作モードを示しています。赤い線は、レイヤー合成エンジンによって現在読み込まれているラインであり、他のレイヤーと合成されてディスプレイに送信されます。 青い線は、現在 TRAVEO T2G ブリットエンジンによって準備されているラインです。緑色の線は、すでに準備が完了しており、レイヤー合成エンジンによって読み込まれる準備が整ったコンテンツを含むラインです。白い線にはまだコンテンツがなく、ブリットエンジンによる準備を待っている状態です。

これは、ラインバッファの「循環型」という特性を示しています。レイヤー合成エンジンはすでに数スキャンライン分先へ進んでいるため、循環バッファの上部は空き状態となっており、ブリットエンジンがさらにコンテンツを準備できるようになっています。

この場合、ブリットエンジンは、レイヤー合成エンジンが現在読み込んでいる行を除き、ラインバッファ全体を埋める時間を確保できています。これは、ブリットエンジンがコンテンツを生成する速度が、レイヤー合成エンジンがそれを処理できる速度を上回っていることを意味するため、望ましい動作モードと言えます。

一方、ブリットエンジンがラインバッファへのコンテンツのレンダリングに時間がかかっている場合、次のような状況に陥る可能性があります。レイヤー合成エンジンが処理できる準備の整った行が存在しないため、ブリットエンジンがレンダリングを完了する前に次の行を読み込む必要が生じると、ラインバッファのアンダーランが発生します。

ラインバッファのアンダーラン

OTFレイヤーでラインバッファのアンダーランが発生すると、ディスプレイは正しい視覚出力を表示する代わりに、黒または赤色で点滅します。これは、OTFレイヤー内のコンテンツが多すぎる場合や、メモリ帯域幅が不十分な場合に発生する可能性があります。画像が遅い外部フラッシュメモリに保存されている場合、メモリ帯域幅がボトルネックになる可能性があります。

ラインバッファアンダーランの問題に対する解決策として、以下の方法があります。

• Tvii::Configuration::setConfigForOTFLayer APIを使用して、ラインバッファの高さを増やします。
• ImageFiles.MCU.resourceCachePolicyまたはImageFiles.MCU.resourceStorageSection を使用して、画像リソースを内蔵フラッシュメモリやVRAMなどの高速なメモリに移動する。
• 一部のUI要素をIBOレイヤーに移動します。IBOレイヤーの内容は、ジャストインタイムで描画されるのではなく、キャッシュされます。

VRAM使用量の最適化

以下に、Infineon のTRAVEO T2Gボード上でQt for MCUs アプリケーションのVRAM使用量を最適化する方法について示します。

レイヤーの色深度

ItemLayer::depth プロパティは、レイヤーの色深度を制御するために使用されます。SpriteLayer を使用する場合、SpriteLayer::depth は、その中に含まれるアイテムレイヤーおよび画像レイヤーの色深度と一致している必要があります。

ItemLayer を最下層のレイヤーとして使用する場合、Bpp24 の色深度を使用することをお勧めします。これにより、デフォルトのBpp32 と比較してVRAMを25％節約できます。 このため、場合によっては、ImageLayer を最下層のレイヤーとして使用せず、代わりに、24 bppの色深度を持つItemLayer 内に、画像コンテンツを通常のImageアイテムとして配置する方が望ましい場合があります。

Bpp16 また、含まれるUI要素に高い色精度が必要ない場合は、Bpp16Alpha を使用することで、VRAMの使用量をさらに削減できます。

VRAM での画像リソースのキャッシュを無効にする

デフォルトでは、画像リソースのリソースキャッシュポリシーは「OnStartup 」に設定されています。VRAMの使用量を削減するには、デフォルトで「NoCaching 」に設定し、パフォーマンス向上のために必要と判断された場合にのみ「OnStartup 」を使用することを検討してください。回転または拡大縮小された画像は、VRAMに明示的に配置することでメリットが得られる場合があります。

MCU.Config {
    resourceCachePolicy: "NoCaching"
}

VRAM でのグリフアルファマップのキャッシュを無効にする

静的フォントエンジンを使用する場合、または Monotype Spark フォントエンジンを使用する際の「StaticText 」では、デフォルトでリソースの初期化中にグリフのアルファマップが VRAM にコピーされます。これを無効にするには、glyphsCachePolicy を NoCaching に設定します：

MCU.Config {
    glyphsCachePolicy: "NoCaching"
}

Monotype Sparkのヒープとキャッシュ

Monotype Spark フォントエンジンを使用する場合、フォントヒープとキャッシュは VRAM 内に割り当てられます。

MCU.Config.fontHeapSizeはデフォルトで -1 に設定されていますが、メモリの断片化を防ぐためには固定値を設定することが推奨されます。適切な値は、アプリケーション、使用するフォント、およびフォントサイズに応じて、24 KB から 64 KB の範囲が考えられます。

MCU.Config.fontCacheSizeはデフォルトで 200 KB に設定されています。TRAVEO T2G ボードでは、テキストキャッシュがデフォルトで有効になっており、フォントキャッシュよりもパフォーマンスの向上が期待できるため、この値は必要以上に大きくなっています。MCU.Config.fontCacheSize は、32 KB などのより小さい値に設定することができます。

MCU.Config {
    fontEngine: "Spark"
    fontCacheSize: 32000
    fontHeapSize: 40000
}

テキストキャッシュ

テキストキャッシュは、1 フレームごとにテキストをグリフ単位で再描画する必要をなくすため、テキスト項目ごとに保持される 1 ピクセルあたり 8 ビットのキャッシュです。TRAVEO T2G では、グラフィックスドライバにおける描画コールのオーバーヘッドが高いため、これにより大幅なパフォーマンス向上が得られます。

TRAVEO T2Gボードでは、テキストキャッシュはVRAMに保持されます。デフォルトで有効になっており、そのサイズは192 KBに設定されています。一部のアプリケーションでは、パフォーマンスを低下させることなく、この値を多少縮小できる場合があります。

アプリケーションは、Qul::Application オブジェクトを作成する際に、テキストキャッシュのサイズをカスタマイズできます：

Qul::ApplicationConfiguration appConfig;
appConfig.setTextCacheEnabled(true);
appConfig.setTextCacheSize(128 * 1024);
Qul::Application app(appConfig);

詳細については、「テキストキャッシュ」を参照してください。

ベクターグラフィックス用のバッファ

ハードウェアアクセラレーションによるベクターグラフィックスのブレンドには、さまざまなバッファが必要です。これらは、Shape 、ArcItem 、およびQul::PlatformInterface::DrawingEngine::blendPath APIによって間接的に使用されます。

グローバルアルファバッファ

グローバルアルファバッファは、TRAVEO T2G 描画エンジンがベクターパスデータを描画する際に使用する中間マスクバッファです。

そのサイズは、platform_config.h.in 内でQUL_PLATFORM_TVII_DRAW_CONTEXT_ALPHA_BUFFER_WIDTH およびQUL_PLATFORM_TVII_DRAW_CONTEXT_ALPHA_BUFFER_HEIGHT を設定することで構成されます。デフォルトでは 320x320 ピクセルです。

アルファバッファはデフォルトで 1 ピクセルあたり 4 ビットであり、メモリ使用量とアンチエイリアシングの品質の間に適切なバランスを提供します。必要に応じて、platform_display.cpp 内のOpenDrawCtx への呼び出しを変更することで、これを変更できます。

デフォルト設定では、アルファバッファによって 51 KB の VRAM が消費されます。

グローバルパスバッファ

グローバルパスバッファは、TRAVEO T2G 描画エンジンによって、ベクトルパスデータがマスクバッファに描画される前にキャッシュするために使用されます。

そのサイズは、platform_config.h.in でQUL_PLATFORM_TVII_DRAW_CONTEXT_PATH_BUFFER_SIZE を設定することで構成されます。デフォルトでは 32 KB です。

パスごとのマスクバッファは、CyGfxDrawingEngine

CyGfxDrawingEngine は、TRAVEO T2G ボード向けのQul::PlatformInterface::DrawingEngine API のプラットフォーム実装です。パスが描画される際、描画エンジンはパスごとにマスクバッファをキャッシュする必要があります。

ただし、ターゲットレイヤーがIBO レイヤーであり、ShapePath::fillGradient プロパティが設定されていない場合は例外です。その場合、パスは中間マスクバッファを使用せずにターゲットフレームバッファに直接描画できます（ただし、前述のグローバルアルファおよびパスバッファは依然として必要です）。

描画エンジンが必要なマスクバッファの割り当てに失敗した場合、QulError_DrawingEngine_SurfaceAllocationFailed エラーが発生します。アプリケーションがベクターグラフィックスを使用する場合は、これらのマスクバッファ用に十分な空きVRAMが確保されていることを確認する必要があります。