エンコード・サンプル・アプリケーションの実行の様子をリアルタイム・モニター上で確認した。今一度アプリケーションの構成と測定結果をまとめておこう。約108FPSここでは、パフォーマンスが問題となっていると思われる構成1のアプリケーションを、さらにトレース・キャプチャー機能を利用して詳細に掘り下げてみよう。設定しておけばよいだろう。このトレース・キャプチャー機能はシステムワイドで機能するため、実行状態にあるすべてのスレッドをキャプチャーしてしまう。動作が極めて重くなるので注意しよう。ボタンをクリックし、直後にアプリケーションを実行してみよう。現状、アプリケーションの実行直後にトレース・キャプチャーを自動的に開始するような機能が提供されていないため、手動で両者を実行しなければならないのが手間ではあるが、それでも、メディア・ハードウェア・アクセラレーションのプロファイリングの目的には十分な機能を提供する。プラットフォーム・アナライザーを起動し後からトレースを選択することも可能だ。プラットフォーム・アナライザー上では、キャプチャーされた各スレッドの実行状態が視覚的に表示されていることが分かるだろう。ここでは水平にスレッドの実行状態を視覚化している部分をトラックと呼ぶ。前述のようにシステム全般のキャプチャーであるため、多くのスレッド(トラック)が生成されてしまうが、メディア・アクセラレーションのプロファイリングに重要なトラックはそう多くない。表示されている2つのトラックの合計4つのトラックである。キーでズームイン・アウトできるほか、各トラックを非表示にしたり、トラックの垂直位置をドラッグで移動できる。してトラックを整理したのが図2である。ペインに関数名などの情報が表示される。Analyzerのトラックを整理したところハードウェア・アクセラレーションによるエンコードの詳細それでは、ハードウェア・アクセラレーションによるエンコードの様子を詳細に解析してみよう。ズームインして1フレーム分を中心に配置したのが図3である。そこで、これを便宜上アプリケーション・トラックと呼ぶことにしよう。ライブラリーの実行の様子を表す。トラックと呼ぶことにする。エンコード・ハードウェア・アクセラレーションの動きを表し、この2つのトラックがもっとも重要なハードウェア・アクセラレーションの実体である。以下、それぞれのトラックを見ていこう。アプリケーション・トラックアプリケーション・トラック上では、同期実行する構成1のサンプル・アプリケーションの場合は、その実行状態を表す横棒が1フレーム分のエンコードを表していると考えてよい。実行されており、アプリケーションの実行と対応している。20.7505msかかっていることが分かる。アプリケーションはハードウェアによるエンコードが終了するまでずっとウエイトしているということである。このような同期実行は、ファイルの入出力やGPUへの入力フレームの転送などのレイテンシーを隠蔽できないので、アプリケーションの最適化上は望ましくないのはいうまでもない。解析ツール上で動作を解析する最初のステップとしては、トラック同士の関係が把握しやすいため、有用である。トラックで、アプリケーション・トラックの実行直後に動作が開始されているのがわかるだろう。側にコピーされ、その後、エンコードコマンドが発行され、GPUトラック上で、実際にエンコードが開始される。下段に、その内部動作を表すサブトラックが表示されているのでそこに注目してみよう。実際の画面上ではサブトラック各部分の実行時間が短すぎて把握しにくいため、ここでは分かりやすくするために図式化してみた(図5)。ペインで実行関数名が表示されるので参考にして確認するとよいだろう。これらは大きく2つの内容に分類することができる。転送であり、もう一つは実際のハードウェアに対するエンコードコマンドのセットアップ発行である。されている間、アプリーションはこのメモリー領域を参照することは許されない。上でトレースされないためである。キャプチャーできれば、その間がフレーム転送に要する時間と考えてよく、解析には支障はないだろう。この入力フレームの転送時間はテスト・アプリケーションでは1.5msほどで、これは入力フレームサイズ、言い換えれば転送されるメモリーの量に依存する。前後だが、より小さいサイズであればより速くなるはずである。一連のエンコードコマンドの発行と考えてよい。あるが)、ここで実際にエンコードに必要なさまざま情報をドライバーが管理し、アタッチしているためである。必要となる参照ピクチャーの管理や、出力ビットストリームのメモリーや必要なサーフェスがここでアタッチされる。トラックが順次開始されているのがわかるだろう。よるハードウェア・エンコードの実体である。2つのトラックに分かれているのは、異なる2つのハードウェア・ロジックを利用しているからである。時間的に先行するトラックは、動き補償予測を中心とする動きベクトルの検出やマクロブロックのモードの決定などを行い、続くトラックは、決定されたマクロブロックの情報や抽出された動きベクトルに基づくビットストリームの符号化処理を行っている。算術符号化のアクセラレーションはここに含まれる。時間的に先行するトラックを動き補償予測トラック、それに続くトラックを符号化トラックと呼ぶことにしよう。これらのトラックの実行状態は、残念ながらアプリケーションからコントロールすることはできないが、より厳密にプロファイル結果をチェックするためには内容を理解しておかなければならない部分があるため、さらに詳しく説明してみよう。上の動き保障予測ハードウェアのアクセラレーションを利用しながら実行される。より処理内容が異なり、パフォーマンスも変わってくる。モードでは4つのステージに処理が分割されていることを確認しておこう。パフォーマンスの影響を受ける。実行エンジンからは独立したビットストリーム符号化用のハードウェア上で実行される。ターボ機能の影響は受けないが、独立したハードウェアであるため、実は前半の動き補償予測機能とは並列・独立に実行可能である。プラットフォーム・アナライザー上で、符号化トラックの動作が動き補償予測トラックの動作に続く形でシリアライズされているのは、動きベクトルやマクロブロックのタイプを確定しないと符号化の処理を実行できない、という論理的な依存関係があるからで、これはドライバーソフトウエアによる同期にすぎない。したがって、論理的な依存関係がなければ、ハードウェアとしては、動き補償予測と符号化は並列実行が可能である。細かい点であるが、あえてこの点に言及しているのは、これがパフォーマンス最適化上のポイントの一つであるからである。動き補償予測が複数のステージに分割されているのは、後続する符号化トラックと直接の依存関係がなく独立可能な処理を分離させ、パフォーマンスを向上させるためである。までは、符号化モジュールとは並列に実行が可能である。エンコーダー・アクセラレーションを最大限に利用する場合には、これらの点にも留意するのが望ましいだろう。ライブラリーに報告される。この終了の様子を拡大したのが図7である。かかわらずドライバーによりサーフェスに書き出されている。ここでいう書き戻しは、ドライバーがサーフェスに出力したストリームを、サーフェスからアプリケーション側に転送することを意味する。インストラクションによって転送が最適化されているという点も大きい。書き戻しのオーバーヘッドは極めて小さく、むしろ入力フレームの転送のレイテンシーの隠蔽に焦点をあてればよい。以上を前提に次稿ではパフォーマンス最適化上のポイントをまとめていこう。Devices」の日本語参考訳です。Plus」の日本語参考訳です。サイトはエクセルソフト株式会社が運営しています。社名、製品名などは一般に各社の表示、商標または登録商標です。