近い状態を保ち、フルに活用することである。前回までの考察を踏まえ、これをエンコーダー・アクセラレーションの場合にあてはめると、以下の2点にまとめることができるだろう。上の動き補償予測モジュールと符号化モジュールを、ギャップなく動作させ続けること。2つのトラックを中心的にチェックし、アイドル状態になってしまってないか確認する。動き補償予測モジュールには、符号化モジュールと並列実行が可能な部分があるため、可能な限りこれが並列に実行されるように構成し、さらなるスループットの向上を図る。トラック上のギャップの確認ここでは、構成1のアプリケーションをさらに解析しながら、より具体的に検討してみよう。フレーム間のギャップ図12のように、構成1の同期実行の状態を確認すると、フレーム間に無駄なギャップがあることが分かるだろう。ここが最適化されるべきポイントであることには疑いはない。トラックにあるギャップであることに注意しよう。ギャップが確認できる。いう数字とほぼ合致すると言ってよい。先行する符号化モジュールと並列動作可能であるため、その並列動作も可能とするようにも工夫すべきということになる。分を短縮することが望ましい。転送とエンコードコマンドの発行をより早期に完了するようにする、ということである。APIを実行すべき具体的タイミングでは、「早期」とは具体的にどのタイミングを指すのであろうか。完了すればよい(図13中の1)、ということになるが、これでは動き補償予測モジュールと符号化モジュールが並列動作できないので、要件(2)を充たさず十分とはいえない。完了することが望ましいと言える(図13中の2)。プラットフォーム・アナライザーで確認してみよう(図14)。近い利用率で活用され、かつ、一部のモジュールがオーバーラップして、並列実行されていることがわかるだろう。ハードウェア・アクセラレーションを効率的に利用すると同時に、もう一歩踏み込んで、異なるモジュールの並列性をも活用しているわけである。2つのトラックに着目し、それが十分に活用されているかを確認するのが近道であろう。GPUのハードウェア・アクセラレーションの利用率とパフォーマンス以上が、GPUのハードウェア・アクセラレーションを利用する上でのエンコード・パフォーマンス最適化のポイントであるが、実は1点つじつまが合わない部分がある。気がついた読者の方はいるだろうか。前後が最高のパフォーマンスだということになるはずである。倍以上のパフォーマンスというのは説明がつかない。Levelが確認できる)。構成1と構成2のアプリケーションを比較したところ両者を比較すると、符号化モジュールのそれぞれ実行時間はほぼ同様と考えてよいだろう。見ると個々のフレームの動き補償予測モジュールの実行時間が違う。構成2の方が、明らかに高速に処理が終了しているように見える。