マイクロプロセッサのグラフィックサブシステムの機能を理解しています

こんにちは！



この記事では、マイクロプロセッサ上にウィジェットを備えたグラフィカルユーザーインターフェイスの実装の機能と、使い慣れたユーザーインターフェイスと適切なFPSの両方を使用する方法について説明します。注意特定のグラフィックライブラリではなく、メモリ、プロセッサキャッシュ、dmaなどの一般的なものに焦点を当てたいと思います。私はEmboxチームの開発者なので、例と実験はこのRTOSで行います。





先ほど、マイクロプロセッサでQtライブラリを実行する方法について説明しました。アニメーションは非常にスムーズであることが判明しましたが、ファームウェアを保存するためのメモリコストもかなりのものでした。コードは外部QSPIフラッシュメモリから実行されました。もちろん、ある種のアニメーションの実行方法も知っている複雑で多機能なインターフェイスが必要な場合は、ハードウェアリソースのコストをかなり正当化できます（特に、このコードをQt用に開発している場合）。



しかし、Qtのすべての機能が必要ない場合はどうでしょうか。 4つのボタン、1つのボリュームコントロール、および2つのポップアップメニューがある場合はどうなりますか？同時に、「見栄えがよく、高速に動作する」ようにしたいです:)次に、lvglライブラリなどのより軽量なツールを使用することをお勧めします。



私たちのEmboxプロジェクトでは、Nuklearが少し前に移植されました。これは、1つのヘッダーで構成される非常に軽量なライブラリを作成し、簡単なGUIを簡単に作成できるようにするプロジェクトです。これを使用して、一連のグラフィック要素を備えたウィジェットがあり、タッチスクリーンを介して制御できる小さなアプリケーションを作成することにしました。



STM32F7-Cortex-M7とタッチスクリーンを使用した検出がプラットフォームとして選択されました。

最初の最適化。メモリを節約する

したがって、グラフィックライブラリが選択され、プラットフォームも選択されます。それでは、リソースとは何かを理解しましょう。ここで、メインメモリのSRAMは外部のSDRAMよりも何倍も高速であることに注意してください。したがって、画面サイズが許せば、もちろんフレームバッファをSRAMに配置することをお勧めします。画面の解像度は480x272です。ピクセルあたり4バイトの色が必要な場合、約512KBになります。同時に、内部RAMのサイズはわずか320であり、ビデオメモリが外部になることはすぐに明らかです。もう1つのオプションは、カラービットの深さを16（つまり、2バイト）に減らして、メモリ消費を256 KBに減らすことです。これは、すでにメインRAMに収まります。



最初に試すことができるのは、すべてを節約することです。256 KBのビデオバッファを作成し、RAMに配置して、そこに描画してみましょう。私たちがすぐに遭遇した問題は、ビデオメモリに直接描画するときに発生するシーンの「ちらつき」でした。Nuklearはシーン全体を最初から再描画するため、最初に画面全体がいっぱいになるたびに、ウィジェットが描画され、次にボタンが挿入され、テキストが配置されます。その結果、シーン全体がどのように再描画され、画像が「点滅」するかを肉眼で確認できます。つまり、内部メモリに単純に配置しても保存されません。

中間バッファー。コンパイラの最適化。FPU

以前の方法（内部メモリへの配置）を少しいじった後、XServerとWaylandの記憶がすぐに思い浮かび始めました。はい、実際、ウィンドウマネージャは、クライアント（カスタムアプリケーションのみ）からの要求を処理し、要素を最終シーンに収集します。たとえば、Linuxカーネルは、evdevドライバーを介して入力デバイスからサーバーにイベントを送信します。次に、サーバーは、イベントに対処するクライアントを決定します。イベント（たとえば、タッチスクリーンを押す）を受け取ったクライアントは、内部ロジックを実行します。ボタンを強調表示し、新しいメニューを表示します。さらに（XとWaylandでは少し異なります）、クライアント自体またはサーバーのいずれかが変更をバッファーに描画します。そして、コンポジターは画面に描画するためにすべてのピースをまとめています。ここで十分に単純で概略的な説明ここ。



同様のロジックが必要であることが明らかになりましたが、小さなアプリケーションのためにXServerをstm32にプッシュしたくはありません。したがって、ビデオメモリではなく通常のメモリに描画してみましょう。シーン全体をレンダリングした後、バッファをビデオメモリにコピーします。





この例では、200 x 200 pxのウィンドウを作成し、そこにグラフィックを描画します。最後のシーン自体は、SDRAMに割り当てたfb_bufバッファーに描画されます。そして最後の行では、memcpyは単に呼び出されます。そして、すべてが無限のサイクルで繰り返されます。



この例をビルドして実行すると、約10〜15FPSになります。それは目でも目立つので、それは確かにあまり良くありません。さらに、Nuklearレンダリングコードには多くの浮動小数点計算が含まれているため、最初にサポートを有効にしました。これがないと、FPSはさらに低くなります。最初の最も単純な（無料の）最適化は、もちろん-O2コンパイラフラグです。



同じ例を作成して実行してみましょう。20FPSが得られます。より良いですが、それでも良い仕事には十分ではありません。

プロセッサキャッシュの有効化。ライトスルーモード

さらなる最適化に移る前に、メモリに直接描画するNuklearの一部としてrawfbプラグインを使用していると言います。したがって、メモリの最適化は非常に有望に見えます。最初に頭に浮かぶのはキャッシュです。



Cortex-M7（この場合）などの古いバージョンのCortex-Mには、追加のプロセッサキャッシュ（命令キャッシュとデータキャッシュ）が組み込まれています。これは、システム制御ブロックのCCRレジスタを介して有効になります。しかし、キャッシュを含めると、新しい問題が発生します。キャッシュとメモリ内のデータの不整合です。キャッシュを管理する方法はいくつかありますが、この記事ではそれらについては詳しく説明しません。そのため、私の意見では、最も単純な方法の1つに移ります。キャッシュ/メモリの不整合の問題を解決するために、使用可能なすべてのメモリを「キャッシュ不可」としてマークするだけです。これは、このメモリへのすべての書き込みが、キャッシュではなく常にメモリに送られることを意味します。しかし、この方法ですべてのメモリにマークを付けると、キャッシュにも意味がなくなります。別のオプションがあります。これは「パススルー」モードであり、ライトスルーとしてマークされたメモリへのすべての書き込みが同時にキャッシュに送信されます。とメモリ内。これにより書き込みオーバーヘッドが発生しますが、一方で読み取りが大幅に高速化されるため、結果は特定のアプリケーションによって異なります。



Nuklearの場合、ライトスルーモードは非常に優れていることがわかりました。パフォーマンスは20FPSから45FPSに上昇し、それ自体はすでに非常に良好でスムーズです。その効果は確かに興味深いもので、データの不整合に注意を払わずにライトスルーモードを無効にしようとしましたが、FPSは50 FPSにしか上昇しませんでした。つまり、ライトスルーと比較して大きな増加はありませんでした。このことから、アプリケーションには書き込みではなく、多くの読み取り操作が必要であると結論付けました。問題は、もちろん、どこですか？おそらく、次の係数などを読み取るためにメモリにアクセスすることが多いrawfbコードの変換の数が原因です。

ダブルバッファリング（これまでは中間バッファを使用）。DMAの有効化

45 FPSで止まりたくなかったので、さらに実験することにしました。次のアイデアはダブルバッファリングでした。このアイデアは広く知られており、一般的には単純です。 1つのデバイスを使用してシーンを1つのバッファーに描画し、他のデバイスは別のバッファーから表示します。前のコードを見ると、シーンが最初にバッファに描画され、次にmemcpyを使用してコンテンツがビデオメモリにコピーされるループがはっきりとわかります。 memcpyがCPUを使用していることは明らかです。つまり、レンダリングとコピーは順番に行われます。私たちのアイデアは、DMAを使用してコピーを並行して実行できるというものでした。つまり、プロセッサが新しいシーンを描画している間、DMAは前のシーンをビデオメモリにコピーします。



Memcpyは次のコードに置き換えられます。

            while (dma_in_progress()) {
            }

            ret = dma_transfer((uint32_t) fb_info->screen_base,
                    (uint32_t) fb_buf[fb_buf_idx], (width * height * bpp) / 4);
            if (ret < 0) {
                printf("DMA transfer failed\n");
            }

            fb_buf_idx = (fb_buf_idx + 1) % 2;

ここにfb_buf_idx（バッファのインデックス）が入力されます。 fb_buf_idx = 0はフロントバッファー、fb_buf_idx = 1はバックバッファーです。 dma_transfer（）関数は、宛先、ソース、および32ビットワードの数を受け取ります。次に、DMAに必要なデータが課金され、作業は次のバッファーで続行されます。



このメカニズムを試した後、パフォーマンスは約48FPSに向上しました。 memcpy（）よりもわずかに優れていますが、わずかです。 DMAが役に立たなかったと言っているわけではありませんが、この特定の例では、全体像に対するキャッシュの効果が優れていました。



DMAのパフォーマンスが予想よりも悪いことに少し驚いた後、私たちは「優れた」ものを思いつきました。それは、いくつかのDMAチャネルを使用するというアイデアでした。ポイントは何ですか？ stm32f7xxで一度にDMAにロードできるデータの数は256KBです。同時に、画面が480x272で、ビデオメモリが約512 KBであることを忘れないでください。つまり、データの前半を1つのDMAチャネルに、後半を後半に配置できるように見えます。そして、すべてが良いようです...しかし、パフォーマンスは48FPSから25-30FPSに低下します。つまり、キャッシュがまだ有効になっていない状況に戻ります。何と接続できますか？実際、SDRAMメモリへのアクセスが同期されているため、メモリでさえ同期動的ランダムアクセスメモリ（SDRAM）と呼ばれるため、このオプションは追加の同期を追加するだけです。必要に応じて、メモリへの書き込みを並列にすることなく。少し考えてみると、メモリが1つであり、書き込みと読み取りのサイクルが1つのマイクロ回路（1つのバス上）に生成され、別のソース/レシーバーが追加されたため、バス上の呼び出しを解決するアービターが追加されるため、ここでは驚くべきことは何もないことに気付きました。 、異なるDMAチャネルからのコマンドサイクルを混在させる必要があります。

ダブルバッファリング。LTDCとの連携

中間バッファからのコピーは確かに良いですが、私たちが知ったように、これは十分ではありません。もう1つの明らかな改善点であるダブルバッファリングを見てみましょう。最新のディスプレイコントローラーの大部分では、使用するビデオメモリにアドレスを設定できます。したがって、コピーを完全に回避し、ビデオメモリアドレスを準備されたバッファに再配置するだけで、画面コントローラはDMAを介してデータを最適な方法で取得します。これは実際のダブルバッファリングであり、以前のように中間バッファはありません。ディスプレイコントローラーが2つ以上のバッファーを持つことができる場合のオプションもあります。これは基本的に同じことです。一方のバッファーに書き込み、もう一方はコントローラーによって使用されますが、コピーは必要ありません。



stm32f74xxのLTDC（LCD-TFTディスプレイコントローラー）には、レイヤー1とレイヤー2の2つのハードウェアオーバーレイレイヤーがあり、レイヤー2はレイヤー1に重ねられます。各レイヤーは個別に構成可能であり、個別に有効または無効にできます。レイヤー1のみを有効にして、フロントバッファーまたはバックバッファーのビデオメモリアドレスを再配置しようとしました。つまり、1つをディスプレイに渡し、もう1つをこの時点で描画します。しかし、オーバーレイを切り替えるときに顕著なジッターが発生しました。



両方のレイヤーをオン/オフで使用する場合、つまり、各レイヤーに独自のビデオメモリアドレスがあり、それは変更されず、一方のレイヤーをオンにしてもう一方のレイヤーをオフにすることでバッファーが変更される場合に、このオプションを試しました。変動もジッターを引き起こしました。最後に、レイヤーがオフになっていないときにオプションを試しましたが、アルファチャネルはゼロ0または最大（255）に設定されました。つまり、透明度を制御して、レイヤーの1つを非表示にしました。しかし、このオプションは期待に応えられず、震えはまだ存在していました。



理由は明確ではありませんでした。ドキュメントには、レイヤーの状態の更新をその場で実行できると記載されています。簡単なテストを行いました。キャッシュとフローティングポイントをオフにし、画面の中央に緑色の四角が付いた静止画を描画しました。これは、レイヤー1とレイヤー2の両方で同じで、静止画を取得することを期待して、ループでレベルを切り替え始めました。しかし、私たちは再び同じ揺れを得ました。



それは別のものであることが明らかになりました。そして、彼らはメモリ内のフレームバッファアドレスの配置を思い出しました。バッファはヒープから割り当てられ、それらのアドレスは整列されていなかったため、アドレスを1 KB整列しました。つまり、ジッターのない期待どおりの画像が得られました。次に、LTDCが64バイトのバッチでデータを減算し、データの不均一性によってパフォーマンスが大幅に低下することをドキュメントで発見しました。この場合、フレームバッファの先頭のアドレスとその幅の両方を揃える必要があります。テストするために、480x4の幅を470x4に変更しました。これは64バイトで割り切れず、同じジッタが発生しました。



その結果、両方のバッファーを64バイトで整列させ、幅も64バイトで整列させ、nuklearを実行したことを確認しました。ジッターはなくなりました。うまくいった解決策は次のようになります。レイヤー1またはレイヤーのいずれかを完全に無効にしてレイヤーを切り替える代わりに、透明度を使用します。つまり、レベルを無効にするには、その透明度を0に設定し、有効にするには-を255に設定します。

        BSP_LCD_SetTransparency_NoReload(fb_buf_idx, 0xff);

        fb_buf_idx = (fb_buf_idx + 1) % 2;

        BSP_LCD_SetTransparency(fb_buf_idx, 0x00);

70〜75 FPSを取得しました！オリジナルの15よりもはるかに優れています。



ソリューションは透明度制御を介して機能し、レベルの1つを無効にするオプションと、レベルアドレスを再配置するオプションにより、FPSが40〜50の大きな画像ジッターが発生することに注意してください。理由は、現時点では不明です。また、先に進むと、これがこのボードのソリューションであると言えます。

DMA2Dを介したハードウェアシーンの塗りつぶし

しかし、これは制限ではありません。FPSを増やすための最後の最適化は、ハードウェアシーンの充填です。その前に、プログラムで充填を行いました。

nk_rawfb_render(rawfb, nk_rgb(30,30,30), 1);

ここで、rawfbプラグインに、シーンを塗りつぶす必要はなく、ペイントするだけであることを伝えましょう。

nk_rawfb_render(rawfb, nk_rgb(30,30,30), 0);

DMA2Dコントローラーを介したハードウェアでのみ、シーンを同じ色0xff303030で塗りつぶします。DMA2Dの主な機能の1つは、RAM内の長方形をコピーまたは塗りつぶすことです。ここでの主な便利な点は、これが連続したメモリではなく、メモリ内にブレークのある長方形の領域であるということです。つまり、通常のDMAをすぐに実行することはできません。Emboxでは、このデバイスをまだ使用していないため、STM32Cubeツール（BSP_LCD_Clear（uint32_t Color）関数）を使用してみましょう。DMA2Dで画面全体の塗りつぶしの色とサイズをプログラムします。

垂直ブランキング期間（VBLANK）

しかし、80 FPSでも、顕著な問題が残っていました。ウィジェットの一部は、画面上を移動するときに小さな「切れ目」で移動しました。つまり、ウィジェットは3つ（またはそれ以上）の部分に分割されているように見え、それらは並んで移動しましたが、わずかな遅延がありました。その理由は、ビデオメモリの更新が正しくないことが原因であることが判明しました。より正確には、間違った時間間隔で更新します。



ディスプレイコントローラにはVBLANKなどのプロパティがあり、VBIまたは垂直ブランキング期間でもあります。隣接するビデオフレーム間の時間間隔を示します。より正確には、前のビデオフレームの最後の行と次のビデオフレームの最初の行の間の時間。この間隔では、新しいデータはディスプレイに転送されず、画像は静止しています。このため、VBLANK内のビデオメモリを更新しても安全です。



実際には、LTDCコントローラーには、次のフレームバッファーライン（LTDCライン割り込み位置構成レジスタ（LTDC_LIPCR））の処理後にトリガーされるように構成された割り込みがあります。したがって、この割り込みを最後の行番号に構成すると、VBLANK間隔の始まりが取得されます。この時点で、必要なバッファ切り替えを行います。



そのような行動の結果、絵は正常に戻り、ギャップはなくなりました。しかし同時に、FPSは80から60に低下しました。この動作の理由が何であるかを理解しましょう。次の式は



、ドキュメントに記載されています。

          LCD_CLK (MHz) = total_screen_size * refresh_rate,

ここで、total_screen_size = total_width xtotal_height。LCD_CLKは、ディスプレイコントローラがビデオメモリから画面にピクセルをロードする周波数です（たとえば、ディスプレイシリアルインターフェイス（DSI）を介して）。ただし、refresh_rateはすでに画面自体の更新速度であり、その物理的特性です。画面の更新速度とその寸法がわかれば、ディスプレイコントローラーの周波数を構成できます。STM32Cubeが作成する構成のレジスターをチェックした後、コントローラーが60Hzの画面に調整されていることがわかりました。それで、それはすべて一緒になりました。

この例の入力デバイスについて少し

アプリケーションに戻って、タッチスクリーンがどのように機能するかを見てみましょう。ご存知のように、最新のインターフェイスは対話性、つまりユーザーとの対話を意味します。



ここではすべてが非常に簡単に配置されています。入力デバイスからのイベントは、シーンをレンダリングする直前にメインプログラムループで処理されます。

        /* Input */
        nk_input_begin(&rawfb->ctx);
        {
            switch (mouse->type) {
            case INPUT_DEV_MOUSE:
                handle_mouse(mouse, fb_info, rawfb);
                break;
            case INPUT_DEV_TOUCHSCREEN:
                handle_touchscreen(mouse, fb_info, rawfb);
                break;
            default:
                /* Unreachable */
                break;
            }
        }
        nk_input_end(&rawfb->ctx);

タッチスクリーンからのイベントの処理は、handle_touchscreen（）関数で行われます。





実際、これは入力デバイスイベントがNuklearが理解できる形式に変換される場所です。実際、おそらくそれだけです。

別のボードで起動

かなりまともな結果を受け取ったので、別のボードでそれらを再現することにしました。別の同様のボード、STM32F769I-DISCOがありました。同じLTDCコントローラーがありますが、解像度が800x480の異なる画面です。起動後、25FPSを取得しました。つまり、パフォーマンスの顕著な低下です。これは、フレームバッファのサイズによって簡単に説明できます。これは、ほぼ3倍の大きさです。しかし、主な問題は異なることが判明しました。画像が非常に歪んでいて、ウィジェットを1か所に配置する必要がある時点で静止画像がありませんでした。



理由は明確ではなかったので、STM32Cubeの標準的な例を調べました。この特定のボードのダブルバッファリングの例がありました。この例では、開発者は、透明度を変更する方法とは異なり、VBLANK割り込みでフレームバッファーへのポインターを移動するだけです。最初のボードでこの方法をすでに試しましたが、うまくいきませんでした。しかし、STM32F769I-DISCOにこの方法を使用すると、25FPSからかなりスムーズな画像の変化が得られました。



喜んで、最初のボードでこの方法を（ポインターを再配置して）再度テストしましたが、それでも高FPSでは機能しませんでした。その結果、レイヤーの透明度（60 FPS）を使用する方法は一方のボードで機能し、ポインターを再配置する方法（25 FPS）はもう一方のボードで機能します。状況について話し合った後、グラフィックスタックの詳細な調査まで統合を延期することにしました。

結果

それでは、要約しましょう。示されている例は、マイクロコンピューター用のシンプルでありながら一般的なGUIパターン（いくつかのボタン、ボリュームコントロール、またはその他）を表しています。グラフィックに重点が置かれているため、この例にはイベントに関連するロジックがありません。パフォーマンスに関しては、かなりまともなFPS値が得られました。



パフォーマンスを最適化するための蓄積されたニュアンスは、グラフィックスが最新のマイクロプロセッサでより複雑になっているという結論につながります。ここで、大規模なプラットフォームと同様に、プロセッサキャッシュを監視し、外部メモリに何かを配置し、より高速なメモリに何かを配置し、DMAを使用し、DMA2Dを使用し、VBLANKを監視する必要があります。それはすべて大きなプラットフォームのように見え始めました、そして多分それは私がすでに何度かXServerとWaylandに言及した理由です。



おそらく最も最適化されていない部分の1つはレンダリング自体であり、シーン全体を最初から完全に再描画します。マイクロシステム用の他のライブラリーでそれがどのように行われるかは言えません。おそらく、この段階がライブラリー自体に組み込まれている場所です。しかし、Nuklearでの作業の結果に基づくと、この場所ではX ServerまたはWaylandの類似物が必要であるように思われます。もちろん、軽量であるため、小さなシステムが大きなシステムのパスを繰り返すという考えにつながります。



UPD1

その結果、透明度を変更する方法は必要ありませんでした。両方のボードで、共通のコードが機能しました-v-syncによってバッファーアドレスを交換しました。また、透明度のある方法も正しいので、必要ありません。



UPD2

トリプルバッファリングを提案してくれたすべての人に感謝します。まだ実現していません。しかし、これは古典的な方法であることがわかります（特に、ディスプレイへのフレームレートが高いFPSの場合）。これにより、特に、v-syncを待機することによるラグを取り除くことができます（つまり、ソフトウェアが画像よりも著しく進んでいる場合）。私たちはまだこれに遭遇していませんが、それは時間の問題です。そして、私が言いたいトリプルバッファリングについての議論に特別に感謝しますbesitzeruf そして ベラブ！



連絡先：



Github：https：//github.com/embox/embox

ニュースレター：embox-ru [at] googlegroups.com

テレグラムチャット：t.me/embox_chat