ソフトウェア高速化専用ページ

最適化項目と最適化計画に沿って最適化を全て実施した性能推移を以下に示す。最適化前では、約41fpsだった処理性能が、 最終的に約57fpsまで向上させることができた。 最適化の内容については、No.1インター時の復号処理の統合から説明する。

最適化計画については下記である。

デコーダプログラムは、参照画像用と完成画像用の大きな作業領域(「フレームメモリと呼ぶ」)を確保している。インター時の復号処理の流れは、基本的に動き補償 →可変長復号→逆量子化→逆離散コサイン変換→差分加算となっている。この中でフレームメモリにアクセスしているのが、動き補償(ストア)と差分加算処理(ロード) であり、キャッシュ効率が非常に悪い形になっていた。 ここでは、大幅な処理構造の変更を行い、動き補償と差分加算を同時に行う形で統合を行った。これにより、フレームメモリへのロード／ストアを大幅に削除すること ができた。本最適化を行ったことによる性能変化を以下に示す。

本デコーダプログラムは、最終的にはRGB32bitフォーマットで出力する仕様であるが、同時にデコード済みの「完成画用のフレーム」として、 実フレームサイズ分のYUVバッファも存在していた。この「完成画用のフレーム」は、RGB変換処理に変更を行うことで、削除可能な中間バッファとみなすことができる。 フレームメモリのようなキャッシュ効率の悪いデータ域へのアクセスを減らすことは、No.1インター時の復号処理の統合と同様、大幅な高速化を見込める。 本項目では、YUVフォーマットの最終画像用の中間バッファを削除し、参照画・カレント用フレームから直接RGB変換を行うことが可能となる形に変更を行った。この変更により、 大幅なストア処理の削除が実現した。

本デコーダプログラムのイントラ処理時では、ブロックデータ解析後、輝度ブロックのデコード処理か色差ブロックのデコード処理かを振り分けるための 条件分岐が頻繁に行われていた。ここでは、これらの処理の条件分岐を外し、シーケンシャルに処理が実行されるように、輝度の処理と色差の処理を別関数に分けた。 また、後の最適化を行うにあたり、コード改修を行いやすくすることにも繋がる。当然であるが、関数を増やすと、コードサイズは増加する。 本手法は、コードサイズがネックになる可能性を考慮して適用するべきである。本件では、若干であるが性能向上した。

本デコーダプログラムが、頻繁に使用するデータに「ブロックデータ」がある。その初期化処理を、キャッシュに乗っているタイミングで行っていなかった。 また、初期化の0クリア処理においても、CHAR型のポインタを使用していたため、命令数の増加に繋がっていた。基本的ではあるが、 これを、INT型ポインタでのストアに変更を行った。処理構造の変更と、キャッシュ効率の改善を起こった結果を以下に示す。

本開発対象デコーダでは、short型のデータに対して、0〜255の飽和演算処理が行われている。元の、飽和演算処理 は下記の流れで処理を行っていた。