外部RAMからのグラフィックスの実行

このセクションでは、以下に示す一般的なセットアップのグラフィックス性能の計算方法について説明します。例として取り上げるのは、32ビットの外部SDRAMに16bppのフレームバッファが格納されている、1024x600ピクセルの24ビットRGB-TFT高解像度ディスプレイです。グラフィカル･アセットは外部のOSPI NOR Flashに格納されています。

この例で使用するセットアップ図

目的

開発者がグラフィカル･ユーザ･インタフェース･アプリケーションのシステム性能を深く理解し評価するために、全体概要をステップを追って説明します。
選択されたディスプレイとその要件を、定義された指定のシステムで維持できるかどうか確認します。
定義されたサブシステム内で開発する可能性があるGUIの複雑さを理解します。

ステップ1: ディスプレイの仕様

STM32H7S78 Discovery Kitで使用するディスプレイはMB1860です。このDiscovery KitのBOM（部品表）へのリンクはこちらです。このDiscovery Kitのディスプレイの解像度は800px x 480pxで、この例で使用する解像度より低いものです。この例のディスプレイ仕様は以下のとおりです。

ディスプレイの高さ: 600px
ディスプレイの幅: 1024px
ディスプレイのリフレッシュレート: 60Hz
ディスプレイのブランキング･エリア*: 約10%（Typ.）

*ディスプレイのブランキングは非アクティブなピクセル数の合計を示します。 LTDCの画像表示時のポーチが主な要因です。

ステップ2: ディスプレイの要件とピクセル･クロックの計算

このステップでは、選択したマイクロコントローラとメモリによって、必要な仕様でディスプレイが動作するかどうか把握するために、ディスプレイの要件を計算する必要があります。

上記に指定されたディスプレイ･サイズから、次のようにピクセルの合計数がわかります。

ピクセルの高さ x ピクセルの幅 = 600px x 1024px = 614,400px

ディスプレイのリフレッシュレートは60Hz（1000ms / 60 = 16ms）なので、LTDCはフレームバッファをフェッチして、およそ16msごとにディスプレイに送信する必要があります。ディスプレイ更新を、60Hz（平均、ブランキングなし）で維持するために必要なシステム（RAM）帯域幅は、以下の式で求められます。

ディスプレイのピクセル x 更新周波数 x フレームバッファの色深度（RGB565）

614,400px x 60Hz x 16bpp = 589,824,000bits/sec = 589.82Mbit/sec

60Hzのディスプレイ更新に必要なピクセル･クロックは、下記の計算で求めることができます。

(総ピクセル数 x リフレッシュレート x (ブランキング% / 100 + 1)) / 1,000,000

(614,400px x 60Hz x (10 / 100 + 1)) / 1,000,000 = 40.55 MHzピクセル･クロック

Caution

LTDCでサポートされる最大ピクセル･クロックを上回らないようにすることが重要です。さまざまな設定でサポートされる最大ピクセル･クロックの概要については、[LTDCアプリケーション･ノート、AN4861]（https://www.st.com/resource/en/application_note/an4861-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf）を確認してください。 STM32H7R/Sの最大ピクセル･クロックの概要は表13に示されています。

STM32H7R/Sでサポートされる最大ピクセル･クロックの概要は、下記に挿入されているLTDCアプリケーション･ノートの表13で確認できます。

STM32H7R3/7S3とSTM32H7R7/7S7でサポートされる最大ピクセル･クロック

ステップ3: フレームバッファとメモリ戦略

この例では、100MHzで動作する32ビット幅のFMCインタフェースに接続された外部の32ビットSDRAMを使用し、ダブル･フレームバッファ戦略を採用します。または、開発者は16ビットのSDRAM、4/8/16ビットのシリアルRAM（Hyper RAMなど）、および200MHz DTRのシリアルPSRAMを使用することもできます。

どの外部メモリでも動作を開始するには何らかの追加サイクルが必要であり、この例では、SDRAMが約80%の効率で動作していると仮定します。

ステップ4: フレームバッファの性能

理論上のRAMのスループットは以下の式で求められます。ここでは前後のバッファが別々のRAMバンクに配置されているとします。

インタフェースの幅 x インタフェースの周波数 = Mbit/sec

32bit x 100MHz = 3,200Mbit/sec = 400MB/Sec

ただし、このスループットはRAMが100%の効率で動作していることを前提としています。ステップ3で推定した効率を考慮すると、実際のスループットは次のようになります。

3,200Mbit/sec x 0.8 = 2,560Mbit/sec = 320Mbytes/sec

ステップ5: ディスプレイ更新後の残りの帯域幅の計算

前にディスプレイには589.82Mbit/secが必要だと確認しましたが、この外部RAMのスループットは2,560Mbit/secです。そこで、スクリーンのレンダリング/アニメーション用に残っている帯域幅を確認します。

2,560Mbit/sec – 589.82Mbit/sec = 1,970.18Mbit/sec = 246.27MBytes/sec

全体的にこの例のシステムはディスプレイ更新を維持することが可能で、これに加えて、追加のアニメーションやその他のUIレイヤ用に約1,970Mbit/secの帯域幅が残っています。

ステップ6: UIレンダリングのパフォーマンス（GUI FPS）

このUIの場合、60FPSのGUIレンダリングをターゲットにしています。つまり、システムは新しいフレームを16ms以内にレンダリングして転送する必要があります。さらに、一部の高度なUIアニメーション用に30FPSまでのドロップを受け入れ可能にして、全体を通して流れるようなユーザ･エクスペリエンスを確保します。

次に、フレームバッファ･スライスあたりのフレームバッファ･パフォーマンス、つまり、各フレーム内でレンダリングできるMbit数（16msあたり）を計算します。まずは、残りのフレームバッファ帯域幅（1,970Mbit/sec）を60FPSで割ります。

1,970Mbit/sec / 60FPS = フレームあたり32.8Mbit（60FPSでおよそ16ms）

つまり、16msあたり32.8MbitのRAMスループットでUIのレンダリングと更新が行われます。

最初のセットアップ図のステップ2には、UIの変更/更新のために使用可能な追加のレンダリングが示されています。フレームバッファは16bppなので、フレームバッファ上のすべての操作は16bppで実行されます。このためフレームバッファへのピクセルの書き込みのために、SDRAM帯域幅の16ビットが取られます。ピクセルのブレンディングが必要な場合は、まずNeoChrom GPUによってフレームバッファからピクセルが読み出されます。ピクセルのブレンディング（変更）後、フレームバッファに書き戻されます。システムは読み出し、変更、書き込み操作のために16ビットを2回転送する必要があるので、16ビット + 16ビット = 32ビットのSDRAM帯域幅を使用することになるわけです（下図参照）。

フレームバッファ上の読み出し、変更、書き込み操作

これで、各フレーム内の1回の操作に使用するピクセル数を計算できます。

32.8Mbit/フレーム / 16bpp = 2.05Mpixels

基準となる数値を示すため、各フレーム内で実行可能な全画面操作の回数を計算します。

2.05Mpixels / 614,000px = 3.34回

つまり、全画面のボックスを描画し、それを別のボックスとブレンドすることが可能です（16bppの書き込み + 16bppの読み出し + 16bppの書き込み）。さらに、画面の17%（34% / 2）を占める3つ目のボックスとブレンドすることもできます。

ステップ6の最初に述べたように、一部の高度なUIアニメーション用に30FPSまでドロップを受け入れることができます。 60FPSと比べて2倍の帯域幅が使用可能なので、各フレーム内で次の回数の全画面操作が可能になります。

3.34 x 2 = 6.68回

各フレーム内で実行可能な全画面操作の回数を断定することはできません。UIの複雑さに大きく依存するからです。さらに、フレームバッファ以外のために外部RAMが必要かどうかを検討することも重要です。しかしながら、少なくとも3回以上というのが多くのアプリケーションにとって合理的なガイドラインだと言えます。

具体例との比較のため、STM32H7S78-DKは、200MHz DTR（100%の効率であれば理論上800MB/S）の外部16ビット･シリアルPSRAMに16ビットのフレームバッファが搭載された、800x480 RGB TFTディスプレイで動作します。このタイプのメモリ･プロトコルは初回に使用するサイクル数が多いので、SDRAMと比べてメモリの初期化効率が低くなります（シリアルRAMのパフォーマンスの詳細については、AN6062を参照してください）。上に示した例と計算によると、この解像度であれば、非常に複雑なUIであっても60 FPSを維持しながらレンダリングが可能です。

もう1つのリファレンスはTouchGFX Demoで、2つの異なるRAMとFlashメモリ周波数による複雑なUIが示されています。

注

上記の計算では使用可能な計算能力が考慮されていないことに注意してください。RAMの帯域幅のみに焦点を当てています。さらに、これらの計算はRAM効率に関する前提に基づいています。これらの前提は恣意的なものではありませんが、やはり前提に過ぎません。

こうした制限はあるものの、この例に示す手順は可能なパフォーマンスを示唆するものとして十分に機能します。

用語

**読み出し、変更、書き込み: あるメモリ領域に対して読み出し、変更し、書き戻すプロセスです。
ピクセル･クロック: ピクセルがディスプレイに転送される周波数で、スクリーンのリフレッシュレートと解像度を決定します。これにより、ディスプレイ･コントローラがディスプレイ･パネルにピクセル･データを送信する速度が定義されます。
フレームバッファ: ディスプレイを駆動するビットマップが格納されたRAM内の領域。フレームバッファにはピクセル値が格納され、ディスプレイ･コントローラがこれらを読み出します。レンダリング操作はフレームバッファに対して実行されます。
ブランキング: ディスプレイのブランキングは非アクティブなピクセル数の合計を示します。 LTDCの画像表示時のポーチが主な要因です。
FMC: フレキシブル･メモリ･コントローラ。 CPUとさまざまなタイプのメモリとの間のインタフェースを管理するハードウェア･コンポーネント（SRAM、NOR、NAND、SDRAMなど）。この例では、外部SDRAMに使用されています。
XSPI: 拡張SPIインタフェース。 SPIの高度なバージョンで、高いデータレートと追加の機能によって周辺デバイスとの通信が強化されています。この例では、外部NOR Flashに使用されています。詳細については、wikiを参照してください。
メモリ･プロトコルのオーバーヘッド: メモリとプロセッサの間の通信やデータ転送を管理するために必要な余分な時間とリソースで、エラー･チェック、ハンドシェイク、アドレス指定などのタスクが含まれます。このオーバーヘッドはシステム全体のパフォーマンスに影響します。
DTR: ダブル転送レート。データは立ち上がりと立ち下がりの両方のクロック･エッジで転送されます。このため帯域幅は2倍になります。

ステップ1: ディスプレイの仕様​

ステップ2: ディスプレイの要件とピクセル･クロックの計算​

Caution

ステップ3: フレームバッファとメモリ戦略​

ステップ4: フレームバッファの性能​

ステップ5: ディスプレイ更新後の残りの帯域幅の計算​

ステップ6: UIレンダリングのパフォーマンス（GUI FPS）​

Further reading

注​

用語​