メイン･コンテンツまでスキップ

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

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

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

目的

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

The last section discusses the hybrid double buffer strategy which can help reduce the load on the external memory bandwidth in some cases.

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

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

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

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

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

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

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

pixel height x pixel width = 600px x 1024px = 614,400px

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

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

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

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

(total number of pixels x refresh rate x (blanking% / 100 + 1)) / 1,000,000.

(614,400px x 60Hz x (10 / 100 + 1)) / 1,000,000 = 40.55 MHz pixel clock

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バンクに配置されているとします。

interface width x interface frequency = Mbit/s

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

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

3,200Mbit/s x 0.8 = 2,560Mbit/s = 320MB/s

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

Earlier we saw that the display required 589.82Mbit/s, and that our external RAM has a throughput of 2,560Mbit/s. そこで、スクリーンのレンダリング/アニメーション用に残っている帯域幅を確認します。

2,560Mbit/s – 589.82Mbit/s = 1,970.18Mbit/s = 246.27MB/s

Overall, the example system can keep the display updated and on top of this there is also ~1,970Mbit/s remaining bandwidth for extra animations and more UI layers.

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

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

次に、フレームバッファ･スライスあたりのフレームバッファ･パフォーマンス、つまり、各フレーム内でレンダリングできるMbit数（16msあたり）を計算します。 First, we use the remaining framebuffer bandwidth (1,970Mbit/s) and divide by 60FPS.

1,970Mbit/s / 60FPS = 32.8Mbit/frame (approximately every 16ms at 60FPS).

This means that the RAM throughput is 32.8Mbit per 16ms to render and update the UI.

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

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

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

32.8Mbit/frame / 16bpp = 2.05Mpixels

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

2.05Mpixels / 614,000px = 3.34 times

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

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

3.34 x 2 = 6.68 times

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

To compare with a concrete example, the STM32H7S78-DK runs an 800x480 RGB TFT display, with 16bit framebuffers in external 16bit serial PSRAM at 200MHz DTR (800MB/s theoretically if 100% efficient). このタイプのメモリ･プロトコルは初回に使用するサイクル数が多いので、SDRAMと比べてメモリの初期化効率が低くなります（シリアルRAMのパフォーマンスの詳細については、AN6062を参照してください）。上に示した例と計算によると、この解像度であれば、非常に複雑なUIであっても60 FPSを維持しながらレンダリングが可能です。

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

Further reading

注​

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

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

Hybrid Double Buffer Strategy​

It is possible to reduce the load on the external memory interface by changing the framebuffer strategy to the hybrid double buffer strategy.
With this strategy all rendering is performed in small buffers in internal RAM. The completed rendering is then copied to the external RAM using a DMA operation.

This limits the accesses to external RAM to a single (burst) write operation. The drawback of the strategy is that it requires large (defaults to 64KB) buffers in internal RAM.

Read more about framebuffer strategies here.

Quality of Service​

Some MCUs have Quality of Service (QoS) settings to control priorities on the internal bus matrix. When this feature is available, and when framebuffers are stored in external RAM, it is recommended to prioritize the LTDC to avoid LTDC underruns. An example for STM32H7R/S can be found here.

用語​

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