概要

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

背景として、まずハードウェアレイヤーを使用したパフォーマンス向上のページで説明されている基本的なハードウェアレイヤーの概念に慣れておくと良いでしょう。

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

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

画像レイヤ

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

IBOレイヤー

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

レンダリングヒントNoRenderingHint 、IBOレイヤタイプを設定します：

ItemLayer {
    renderingHints: ItemLayer.NoRenderingHint
}

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

幅 x 高さ x バッファ x BPP = 800 x 480 x 2 x 2 バイト = 1.54 MB

メモリーレイヤーへのLBO

IBOレイヤと同様に、LBO-to-memoryレイヤもVRAM内のダブルバッファのフレームバッファで構成される。違いは、TRAVEO T2Gブリットエンジンが描画コマンドをバッファリングし、描画コマンドを行単位でバックバッファに再生する点です。これにより、いくつかの最適化が可能になり、単純なUIには不要なオーバーヘッドがありますが、過剰描画を減らすことができます。

レンダリングヒントOptimizeForSpeed 、LBOレイヤータイプを設定します：

ItemLayer {
    renderingHints: ItemLayer.OptimizeForSpeed
}

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

OTFレイヤー

OTF（on-the-fly）レイヤーは、LBO to displayとしても知られ、動的にレンダリングされるコンテンツを表現するためにピクセルデータのダブルバッファリングされたフレームバッファを必要としない点が特徴です。その代わりに、コマンド・バッファがフレームごとに保持され、フレームがアクティブである限り、画面のリフレッシュ・レートで再生される。コマンドバッファのエントリは、どのソース画像データでどのブレンド操作を実行するかを指定します。

各画面リフレッシュ時のコマンドバッファのレンダリングは、円形のラインバッファを介して行われる。ラインバッファの高さは、32、64、128、または他の2のべき乗でなければなりません。TRAVEO T2Gブリットエンジンはラインバッファの前面に書き込み、表示データは背面から読み込まれます。

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

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

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

WIDTH x LINE_BUFFER_HEIGHT x BUFFERS x BPP + COMMAND_BUFFER_SIZE = 800 x 64 x 3 bytes + 64 KB = 219 KB

プラットフォームの制限

最大レイヤ数及びその他のTRAVEO T2Gレイヤ関連の制限については、Infineon TRAVEO T2Gプラットフォームの制限を参照。

ラインバッファの概要

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

これは、ラインバッファの「循環的」な性質を示している。レイヤー合成エンジンはすでにスキャンライン数分進んでおり、ブリットエンジンがさらにコンテンツを準備するために、円形バッファの上部が空いている。

この場合、ブリット・エンジンは、レイヤー合成エンジンが現在読み込んでいる行を除いて、ライン・バッファ全体を満たす時間がある。これは、blitエンジンが、レイヤー合成エンジンがコンテンツを消費するよりも速くコンテンツを生成していることを意味するので、望ましい動作モードです。

一方、Blitエンジンがラインバッファにコンテンツをレンダリングするのが遅い場合、次のようなシナリオになる可能性があります。レイヤー合成エンジンが消費する準備ができた行がないため、blit エンジンがレンダリングを終了する前に次の行を読み込む必要がある場合、行バッファのアンダーランが発生します。

行バッファ不足

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

以下は、ラインバッファのアンダーラン問題に対するいくつかの可能な解決策です：

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

VRAM使用量の最適化

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

レイヤの色深度

ItemLayer::depth プロパティを使用して、レイヤの色深度を制御します。SpriteLayer を使用する場合、SpriteLayer::depth は内部に含まれるアイテムレイヤーとイメージレイヤーの色深度と一致しなければなりません。

一番下のレイヤーとしてItemLayer を使用する場合は、Bpp24 の色深度を使用することをお勧めします。デフォルトのBpp32 と比較して、25 % の VRAM を節約できます。このため、ImageLayer を最下層のレイヤーとして使わず、ItemLayer の色深度 24 bpp のレイヤーに、通常のイメージ・アイテムとしてイメージ・コンテンツを配置する方が望ましい場合もあります。

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に設定されています。テキストキャッシュはデフォルトで有効になっており、フォントキャッシュよりもパフォーマンスが向上するためです。MCU.Config.fontCacheSizeは32KBなど、より小さい値に設定することができます。

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

テキスト・キャッシュ

テキストキャッシュは、テキストアイテムごとに保持される8ビット/ピクセルのキャッシュで、フレームごとにテキストのグリフを再描画する必要がないようにします。TRAVEO T2Gでは、グラフィックスドライバの描画呼び出しオーバーヘッドが大きいため、パフォーマンスが大幅に向上します。

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

アプリケーションは、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ピクセルです。

アルファ・バッファはデフォルトでピクセルあたり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 があることを確認する必要があります。