跳轉到主要內容

從外部 RAM 執行圖形處理

本節介紹如何計算以下所示典型設定的圖形效能。 此範例是 1024x600 像素的高解析度 24 位元 RGB-TFT 顯示器，具有儲存在外部 32 位元 SDRAM 中的 16bpp 影像緩衝區。 圖形資產儲存在外部 OSPI NOR 快閃記憶體中。

範例所使用設定的示意圖

目的

  1. 為開發人員提供逐步概述，以便進一步瞭解和評估圖形使用者介面應用程式的系統效能。
  2. 檢查定義的指定系統是否足以維持所選的顯示器及其要求。
  3. 瞭解在定義的子系統內可以發展出多麼複雜的 GUI。

步驟 1：顯示器規格​

STM32H7S78 Discovery Kit 上使用的顯示器是 MB1860。 Discovery Kit 的 BoM 連結請點選此處。 Discovery Kit 上的顯示器解析度為 800px x 480px，低於本範例中使用的解析度。 範例的顯示器規格如下所示：

  • 顯示高度：600px
  • 顯示寬度：1024px
  • 顯示刷新率：60Hz
  • 顯示器消隱區域*：通常為約 10%

*顯示器消隱涵蓋非作用中像素的總和。 主要貢獻是為 LTDC 提供前後沿 (porches)。

步驟 2：顯示器要求和像素時脈計算​

在此步驟中，我們需要計算顯示器要求，以瞭解我們的 MCU 和記憶體選擇是否能夠在所需的規格下操作顯示器。

根據上述指定的顯示尺寸，我們知道像素總數為：

像素高度 x 像素寬度 = 600px x 1024px = 614,400px

顯示器的更新率為 (1000ms/60 = 16ms) 60Hz，因此 LTDC 需要大約每 16ms 擷取影像緩衝區並將其傳送到顯示器。 接著，可以透過以下公式找到保持顯示器以 60Hz (平均值，無消隱) 更新所需的系統 (RAM) 頻寬：

顯示像素 x 更新頻率 x 影像緩衝區色深 (RGB565)

614,400px x 60Hz x 16bpp = 589,824,000 位元/秒 = 589.82 Mbit/秒

透過以下計算可以找到以 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：影像緩衝區和記憶體策略​

在這個範例中，我們使用一個外部 32 位元 SDRAM 連接到一個執行頻率為 100MHz 的 32 位元寬 FMC 介面，採用雙重影像緩衝區策略。 或者，開發人員也可以使用 16 位元 SDRAM、4/8/16 位元序列 RAM (如 Hyper RAM 和 200MHz DTR 的序列 PSRAM)。

對於所有外部記憶體，都需要一些額外的週期來啟動操作，在這個範例中，我們假設 SDRAM 的運作效率約為 80%。

步驟 4：影像緩衝區效能​

目前後緩衝區位於不同的 RAM 庫時，理論 RAM 吞吐量由以下公式得出：

介面寬度 x 介面頻率 = Mbit/秒

32 位元 x 100MHz = 3,200 Mbit/秒 = 400 MB/秒

但是，此吞吐量是以 RAM 達到 100% 的效率為基礎。 如果我們考慮步驟 3 中估算的效率，則實際吞吐量為：

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

步驟 5：計算顯示器更新後的剩餘頻寬​

之前我們看到顯示器需要 589.82 Mbit/秒，而我們的外部 RAM 吞吐量為 2,560 Mbit/秒。 現在，讓我們檢查螢幕渲染/動畫還剩下多少頻寬。

2,560 Mbit/秒 - 589.82 Mbit/秒 = 1,970.18 Mbit/秒 = 246.27 MBytes/秒

整體而言，範例系統可以讓顯示器保持更新，除此之外還有約 1,970 Mbit/秒的剩餘頻寬可用於額外的動畫和更多的 UI 層。

步驟 6：UI 渲染效能 (GUI FPS)​

在這個 UI 案例中，我們的目標是 60FPS GUI 渲染。 亦即系統必須在 16 毫秒內渲染並傳輸新影格。 此外，我們可以接受將一些進階 UI 動畫的影格率降至 30FPS，以確保始終流暢的使用者體驗。

讓我們計算每個影像緩衝區切片的影像緩衝區效能，也就是我們可以在每個影格 (每 16 毫秒) 內渲染多少 Mbit。 首先，我們使用剩餘的影像緩衝區頻寬 (1,970 Mbit/秒) 並除以 60FPS。

1,970 Mbit/秒 / 60FPS = 每影格 32.8 Mbit (大約 60FPS 下每 16 毫秒)。

亦即每 16 毫秒的 RAM 吞吐量為 32.8 Mbit，用於渲染和更新 UI。

在最一開始的設定示意圖中，步驟 2 展示了用於變更/更新 UI 的可能額外渲染。 由於影像緩衝區是 16bpp，因此影像緩衝區上的所有操作都是以 16bpp 完成。 因此，在影像緩衝區中寫入像素將獲取 16 位元 SDRAM 頻寬。 如果某個像素需要混合，NeoChrom GPU 將首先從影像緩衝區讀取該像素。 像素混合 (修改) 後，將寫回至影像緩衝區。 這表示系統需要為讀取－修改－寫入操作傳輸兩次 16 位元，因此使用 16 位元 + 16 位元 = 32 位元的 SDRAM 頻寬，如下圖所示。

影像緩衝區讀取－修改－寫入操作的示意圖

我們現在可以計算出每影格內可以對多少個像素執行一次操作：

32.8 Mbit/影格 / 16bpp = 2.05Mpixels

為了提供參考點，我們計算每影格內可以進行多少次全螢幕操作：

2.05Mpixels / 614,000px = 3.34 次

這表示我們可以，舉例而言，繪製一個全螢幕框，然後將其與另一個框混合 (16bpp 寫入 + 16bpp 讀取 + 16bpp 寫入)。 可以進一步與覆蓋螢幕 34% / 2 = 17% 的第三個框混合。

如步驟 6 開頭所提到，對於一些進階 UI 動畫，我們可以接受降至 30FPS。 亦即我們擁有比 60FPS 多兩倍的可用頻寬，使得每影格內可以進行以下數量的全螢幕操作：

3.34 x 2 = 6.68 次

我們無法明確知道每影格內可以執行多少次全螢幕操作，因為這受到 UI 的複雜性很大的影響。 此外，重要的是要考慮是否需要外部 RAM 用於影像緩衝區以外的其他用途。 然而，對於許多應用程式來說，合理的原則是至少應該在 3 次以上。

若要用具體的例子來比擬，STM32H7S78-DK 執行 800x480 RGB TFT 顯示器，在外部 16 位元序列 PSRAM 配備 16 位元影像緩衝區，頻率為 200MHz DTR (如果效率達 100%，理論上為 800MB/S)。 這種類型的記憶體協定最初使用更多的週期，導致與 SDRAM 相比記憶體初始化效率較低 (請參閱 AN6062 進一步瞭解序列 RAM 的效能)。 上述範例和計算顯示，在此解析度下，即使是最複雜的 UI 也可以在保持 60 FPS 的同時進行渲染。

另一份參考資料是 TouchGFX 示範，展示具有 2 種不同 RAM 和快閃記憶體頻率的複雜 UI。

Further reading

附註​

值得注意的是，上述計算並沒有考慮可用的運算能力，而只關注 RAM 頻寬。 此外，計算是基於對 RAM 效率的假設。 雖然這些假設並非任意的，但仍然是假設。

儘管存在這些限制，範例中的程序仍可作為可能效能的指標。

詞彙表​

  • 讀取－修改－寫入：讀取、修改，然後寫回至記憶體位置的流程。
  • 像素時脈：像素傳輸到顯示器的頻率，決定了螢幕的刷新率和解析度， 並定義了顯示器控制器向顯示面板傳送像素資料的速度。
  • 影像緩衝區：RAM 中的一個區域，包含驅動顯示器的點陣圖。 影像緩衝區儲存像素值，由顯示器控制器讀取。 渲染操作在影像緩衝區上執行。
  • 消隱：顯示器消隱涵蓋非作用中像素的總和。 主要貢獻是為 LTDC 提供前後沿 (porches)。
  • FMC：彈性記憶體控制器。 管理 CPU 與各類型記憶體 (如 SRAM、NOR、NAND 和 SDRAM) 間介面的硬體元件。 在此範例中，其用於外部 SDRAM。
  • XSPI：可擴充的 SPI 介面。 SPI 的進階版本，支援更高的資料速率和附加功能，可增強與週邊裝置的通訊。 在此範例中，其用於外部 NOR 快閃記憶體。 更多資訊請參閱維基。
  • 記憶體協定額外負荷：管理記憶體和處理器間通訊和資料傳輸所需的額外時間和資源，包括錯誤檢查、交握和定址等任務。 這些額外負荷會影響系統整體效能。
  • DTR：雙倍傳輸速率。 資料在時脈的上升沿和下降沿進行傳輸。 頻寬因此變成雙倍。