x264

x264 for cell をバージョンアップしました。

• patch-x264-cell-r714-080501.bz2 (1 patch)
• patches-x264-cell-r714-080501.tar.bz2 (series patch for quilt, stgit)

主な変更点としては、

• ベースを r635 から r714 に変更。ちなみに現在の最新バージョンは、 怒涛の更新により r839 なので、かなり古いものがベースです。
• SPE で動作するスレッド (x264_enc_thread_spu) を新しく作りました。こ のスレッドでは encode、intra analyse や rd 系の関数を実行します。

使用ツールのインストール

x264 のソース管理が subversion から git に変更されていますので、まず は git (StGIT) をインストールして下さい。Fedora(rpm) 系では以下のように します。

$ yum install git stgit

source tree の作成

1 patch を使用する場合と、series patch を使用する場合の 2 通りの方 法を用意してありますのでお好きな方をどうぞ。

1 patch を使用する場合

$ git clone git://git.videolan.org/x264.git
$ cd x264
$ git branch cell-r714 96a59591e1190a3b4dbcbae79f9b150f09977427
$ git checkout cell-r714
$ bzip2 -dc /hack/cell/x264-cell/patch-x264-cell-r714-080501.bz2 | patch -p1

series patch を使用する場合

$ git clone git://git.videolan.org/x264.git
$ bzip2 -dc patches-x264-cell-r714-080501.tar.bz2 | tar xvf -
$ cd x264
$ stg branch -c cell-r714 96a59591e1190a3b4dbcbae79f9b150f09977427
$ stg import -s ../patches/series	# trailing whitespace warning が出ます

実行ファイルの作成

実行ファイルは以下のようにして作成出来ます。PC の場合も configure を PS3 上で行うことで作成される config.mak, config.h が必要です。

$ ./configure				# PS3 上で実行
$ make cell

これで実行ファイル x264 (ppe), x264_{me,enc}_thread_spu (spe) が出来 ます。

linux kernel v2.6.23 から Completely Fair Scheduler (CFS) という新しいスケジューラが導入 されましたが、これに伴い sched_yield() の挙動が大幅に変更されています。簡単に言うと、スレッド が sched_yield() を発行すると、次回のスレッド実行が以前のバージョンの kernel と較べると遅くなります。で、以前 と同じ挙動にするためには以下のように kernel を設定すれば良いようです。

echo 1 > /proc/sys/kernel/sched_compat_yield

また、関連する commit は以下になります。

• sched: add /proc/sys/kernel/sched_compat_yield

x264 for cell でも sched_yield() は多用しており、v2.6.21 から v2.6.23 にバージョンを上げた 時に速度が低下したため、しばらくは v2.6.21 を使用していました。 が、v2.6.21 は正常にリブート出来ない上に nfs の使用に難があるため、やっぱり v2.6.23 を使用 しようということで kernel source を調べて判明しています。で、原因が sched_yield() にあると 分かって念のため google してみるとすでに以下の記事があってガックリなわけですが、、

• Linux Kernel Watch 12 月版: 望ましい挙動とは？　sched_yieldを巡る議論
• KernelTrap: CFS and sched_yield

x264 for cell ではどう sched_yield() を使用している？

x264 for cell では PPE <-> SPE 間通信が 多対一 となっているため、PPE->SPE は SPU シグナルが使用出来ますが、SPE->PPE は、複数の PPE スレッドが一つの SPE スレッドに対して待ち状態 になっているため、SPU アウトバウンド(割り込み)メールボックスを使用しようとすると、pthread の cond や mutex を組み合わせて複雑な通信方式を実現しなければならないからです。 この代わりとして、 SPE が処理終了時にメモリを変更するので、このメモリを PPE で監視して、 未終了なら sched_yield() するようにしています。 (つまり PPE<->SPE 間で mutex, cond 等を実現する場合と同じことをしています) 速度や実現性を考えると kernel のドライバを作成するというのも考えていますが、、

他の Cell 用ソフトでは？

fixstars 社で公開されている CTK: Cell ToolKit Library でも PPE-SPE 間で使用可能な mutex, cond, queue 等を実現するために使用しています。(source としては以下の辺り)

./ctk/sync/ppu/ctk_mutex-impl.h
./ctk/sync/ppu/ctk_sem-impl.h
./ctk/sync/ppu/ctk_cond-impl.h
./ctk/sync/ppu/ctk_genericq-impl.h
./ctk/sync/ppu/ctk_barrier-impl.h
./ctk/sync/ppu/ctk_queue-impl.h

また、SPE 側では sched_yield() に該当する箇所で random delay させており、スラッシング しないように工夫されています。

逆に、Cell SDK 内で提供されている libsync の mutex, cond では sched_yield() は使用せず、 スピンロックする(実行権を放棄しない)ようです。

sched_yield() は使うべき？使わないべき？

状況による、というありきたりな答えになってしまいますが、 mutex, cond によるロック期間が短ければ sched_yield() を使用しないほうが有利、ロック期間 が長かったり、PPE 上で複数のスレッドが動作する場合は sched_yield() を使用したほうが有利 という感じになるのかな、、

前回の blog で書いたとおり、 x264-devel ML にバグ修正 patch を送ったのですが、 結局、何の反応もありません。 commit されないんだろうなぁとあきらめていましたが、 先日、何の前触れもなく commit されてました。

それなら他にもバグらしきものがあるので送ってみようということで、以下のバグ修正 patch を送っています。

この修正も 8x4, 4x8, 4x4 のサブマクロブロックに関するもので、Cell 対応の過程で発見したものです。どれも非常にわかりにくい修正なので何か反応が欲しいところですが、ML 上ではやっぱり反応なしです。

x264-devel ML にバグ修正 patch を送っています。

で、patch の内容ですが、

1. サブマクロブロック 4x4 の動きベクトル探索後の chroma 生成に関するバグ
2. idct4x4dc 関数のテスト実行条件に関するバグ
3. quant 系関数テスト時のメモリ未開放に関するバグ (GBクラスのメモリを持つ PC では問題に なりませんが、256KB しかメモリがない SPU ではガッツリ発現します、、ハマりました)
4. intra predict 系関数テストで、関数がバグっている場合に表示されるメッセージに関するバグ

というように本体の修正や、SPU 用の各種関数を作成する上で見つけたものです。 で、このメールを出したのは 11/22 なんですが、全く誰からも反応なしです。 確かに 1 以外はテスト用のもので、1 に関しても p4x4、それも chroma が対象で、patch を適用しても エンコード結果にほとんど影響しないのですが、バグじゃないのかなあ、、

他にもバグらしきものが数点あり、そのうちでも堅いと思われる修正を出したつもり なのですが、どうするかな、、

x264-devel ML に PPU 向けの patch を送っています(commit 済み)。

今回の patch に含まれる 3 関数は、(エンコード用オプションを色々と追加した場合、) それほど負荷があるわけではないため、SPU化の優先順位は非常に低いのですが、 現状では PPU への負担が大きいため、この負担を軽くするのが目的です。

久々の更新です。前回の更新が 6 月下旬だったので、もう止めてしまったのかと思われた方 も多いと思いますが、、、

前回の更新後、ずっと DCT, 量子化、ジグザグスキャン等を行う x264_macroblock_encode() の SPU 化を検討していました。が、検討を進めていくと芋づる式に trellis や rd 系の処理も必要に なってきて、そうすると256KBオーバーになり、ずっと頭を抱えていました。で、余裕がなくなり、blog の 更新も止まるという悪循環に、、blog は継続することが重要なのに、イザとなるとなかなか出来ない ですね。

現在は一応の目処がついたので、実装を進めています。

ということで、上記の検討で SPU 用の関数を実装する上で、 PPU(Altivec) の関数を幾つか 実装したので、それを x264-devel ML に送って本体に反映してもらっている所です(commit 済み)。

r635 070530 版の性能についてまとめました。

テスト条件

前回同様、テスト用の動画は SOCCER_704x576_60_avc_3000.yuv を使用し、以下のように動きベクトル探索を最大限行うようオプションを付けて実行しています。

$ ./x264 --bframes 3 --ref 5 --mixed-refs -A all --me umh --bime -m 7 --8x8dct \
         --threads (thread num) SOCCER_704x576_60_avc_3000.yuv -o (出力ファイル名)

Cell 対応による速度の変化

x264 を Cell 対応することで、速度がどうなったか？また、実際に SPE を使用 することで速度がどうなったかです。version は以下を表し、 速度の指標は x264 自体がエンコード後に出力する fps (frames per second) を使用します。

• r635: rev:635 オリジナル版
• r635 070530 cell sim: rev:635 070530 の Cell 対応 (sim) 版
• r635 070530 cell: rev:635 070530 の Cell 対応版
• r635 070530 cell sim: rev:635 070412 の Cell 対応 (sim) 版
• r635 070530 cell: rev:635 070412 の Cell 対応版

やっと 1PPE r635 よりも速くなりましたが、今回から載せている core2duo r635 と比べるとまだまだという状況です。

スレッド数増加による速度変化

x264 の --threads オプションで同時に処理するフレーム数 (thread num) を変化させた 場合の結果です。

core2duo r635 は、4GB の RAM を積んでいるため、入力ファイル全体 (360MB) がキャッシュされてしまい、2 回目以降の実行ではディスクアクセスが ほとんど発生しません (しかし、PS3 の RAM は 256MB なのでキャッシュは有効 に働かないと予想される)。。キャッシュによる高速化は、正確には Cell とは関 係ありませんが、キャッシュされた場合のデータを掲載しています。

thread 数が 4 以降でも若干ながら高速にはなりますが、大枠では PPE の SMT による高速化率 (1.5 倍) による制約が大きいため、もっと SPE 側に処理 自体を移動させる必要があります。

SPE の稼働率

• active rate: SPE で何らかの命令を実行している時間の割合。
• proc rate: 上記でかつ、(DMA 転送待ちに関連しない) 命令を実行してい る時間の割合。
• SPE 有効稼働率: SPE が有効な演算をしている時間の割合。各 SPE の active rate * proc rate / 100 の平均値を載せています。

proc rate が前バージョンから改善 (57% -> 67%) されていますが、このバー ジョンから DMA リスト自体を分割して複数の DMA リストとし、リストの作成と 転送を並列に行うようにしており、この変更による所が大きいです。

x264 for cell をバージョンアップしました。

• patch-x264-cell-r635-070530.bz2
• patches-x264-cell-r635-070530.tar.bz2 (for quilt, stgit)

変更点としては、

• 動きベクトル探索を行う時には、最初に幾つかのベクトルの初期値候補から適切な初期値 を決定します 。前バージョンまでは PPE で行っていたこの処理を、SPE で行うようにしました。
• 各 SPE は、整数画素単位の探索用に 256x192 画像を 2 枚分持っていましたが、大きさと枚数 を変更して、128x128 画像を 6 枚分持つようにしています。また履歴管理は LRU で行っています。
• 1/2, 1/4 画素単位の探索用画像を転送する時に、マクロブロックのタイプを考慮して画像の 大きさを決定することで、転送量を削減しました。
• PPE - SPE 間の通信データを更新タイミング毎に分割し、適切なタイミングで更新する ようにしました。
• DMA リストの作成を組み込み関数 ( spu_*() ) を使用して高速化しました。
• プロファイル機能を見直して、DMA 転送待ち時間が正確に取れるようにしました。

コンパイルは PS3 FC6 + SDK 2.1 と x86 Linux PC + SDK 2.1 で確 認してあります。上記の patch をダウンロードして、以下のように x264 r635 に patch を適用して make することで実行バイナリが出来ます。(PC の場合も configure を PS3 上で行うことで作成される config.mak が必要です)

$ svn co -r 635 svn://svn.videolan.org/x264/trunk x264
$ cd x264
$ bzip2 -dc ../patch-x264-cell-r635-070530.bz2 | patch -p1
$ ./configure
$ make cell

今回は、パフォーマンス計測機能の出力結果を元に、現バージョンの性能をまとめて おきます。

x264 for cell (070412) の概要

SPE 用のコードを CPU で動作させる SPE シミュレーションモード (sim) を持っています。具体的に何をしているかと言うと、

• DMA 転送 は memcpy() で代用
• mailbox (SPE への処理依頼) は 関数呼び出し で代用
• 各 SPE で同時に複数の処理が動作しないように排他制御 (pthread_mutex 使用)
• 各 SPE が個別に持つリソースの管理
• SPE 専用のコードと同等の処理を行う CPU 版のコードを用意 (x264 自体 が対応)

です。最初から SPE での動作を目指すと、実際に動作し始めるまでの難関 (メモリの制限や複雑な DMA 転送) が多いため、バグが取れずに挫折する可能性 が高いと感じ、このモードを付けています。このモードにより、実際の開発はほ とんど Linux PC 上で行っており、結果を確かめながら変更していくことが出来 ました。但し、ソースが非常に複雑 (#ifdef の嵐)になってしまっています。

上記の複雑な DMA 転送というのは、参照画像から実際に動きベクトル探索で 利用する部分を切り出す処理に相当するのですが、具体的には以下の 2 つです (当然、他にもDMA 転送しているデータはあります)。

• 192 line の DMA リスト転送 (整数画素単位の動きベクトル探索用に 256x192 の輝度部分画像 1 枚分)
• 120 line の DMA リスト転送 (1/2, 1/4 画素単位の動きベクトル探索用に 48x24 の輝度部分画像 4 枚分と 32x12 の色差部分画像 2 枚分 (24*4+12*2) )

両者ともに画像の切り出し位置は、DMA の 16byte アラインを考慮して SPE 側で計算しています (CPU 側が SPE で使用しているデータを把握していないとい うことです。デバッグ時はこれが一番問題に、、)。

また、両者ともに DMA 転送する画像の切り出し位置が処理の直前にしかわか らない、かつ、前者は DMA リスト転送するかどうかを判定する場所が複数ありま す。よって、(ようするに非常に複雑なので) ダブルバッファ等を使用することで 転送中も演算処理を行って転送時間を隠蔽するのが高速化の基本ですが、現在の バージョンでは行っていません。

各 SPE への処理の割り当ては、基本的には符号化対象画像毎に割り当ててい ますが、P (前方参照のみ) の場合と B (前方参照と後方参照) の場合で、処理量 の差が約 2 倍 ( P>B ) ありましたので、何番目の参照画像かも考慮することで 処理量を平均化しています。

テスト条件

テスト用の動画は SOCCER_704x576_60_avc_3000.yuv を使用し、以下のように動きベクトル探索を最大限行うようオプションを付けて実行しています。

$ ./x264 --bframes 3 --ref 5 --mixed-refs -A all --me umh --bime -m 7 --8x8dct \
         --threads (thread num) SOCCER_704x576_60_avc_3000.yuv -o (出力ファイル名)

Cell 対応による速度の変化

まずは、x264 を Cell 対応することで、速度がどうなったか？また、実際に SPE を使用 することで速度がどうなったかです。version は以下を表し、 速度の指標は x264 自体がエンコード後に出力する fps (frames per second) を使用します。

• r635: rev:635 オリジナル版
• r635 cell sim: rev:635 の Cell 対応 (sim) 版
• r635 cell: rev:635 の Cell 対応版

以上のように、Cell 対応をすることで、速度が約 1/3 (1.44 -> 0.56) になっていますが、 実際に SPE を使用することで挽回 (0.56 -> 1.28) しています。現状、それでも 1PPE の ほうが速いわけですが、、参考までに core2duo (E6600) での結果も載せていま す、、完敗してます。

また、処理のほとんどを SPE に移した関数 (x264_me_search_ref()) の時間を google performance tool で測定してみましたが、実行時間に対する割合は 55% (r635) -> 40% (r635 cell) ということであまり減っていません。 これは、以下の理由が挙げられます。

• SPE に処理を依頼するためのパケットの複製 (オリジナルでは複製する必要が ない) に時間がかかっている。
• PPE 側に残した処理は、使用するデータのランダム性が高いため、キャッ シュミスが大量に発生している。
• sched_yield() 呼びすぎ (PPE が SPE に依頼する処理としては粒度が小さいすぎる)。

スレッド数増加による速度変化

次に x264 の --threads オプションで同時に処理するフレーム数 (thread num) を変化させた 場合の結果です。

このように thread 数が多くなると 1PPE r635 でも SMT が効いて速くなり ますが、thread 数が増えるにつれて r635 cell 版も 6 SPE が有効に働くよう になり、両者がほぼ同じ (やや負け) 位の速度でエンコード出来るようになって います。

SPE の稼働率

最後は、じゃあ SPE はどのくらい有効に働いているの？ですが、

• active rate: SPE で何らかの命令を実行している時間の割合。
• proc rate: 上記でかつ、(DMA 転送待ちに関連しない) 命令を実行してい る時間の割合。

とすると、thread オプションに対する各 SPE の active rate, proc rate は以下のようになります。

--bframes や --ref オプションの値にもよりますが、各 SPE への処理の 平均化は全体的にはうまくいっているようです。

SPE が有効な演算をしている割合 (有効稼働率) は active rate * proc rate / 100 となりますが、thread 数が 6 の時の SPE 有効稼働率は、平均 active rate を 14.5 %、平均 proc rate を 57 % とすると、 14.5 * 57 / 100 = 8.25 % ということになります。

x264 for cell をバージョンアップしました。

• patch-x264-cell-r635-070412.bz2
• patches-x264-cell-r635-070412.tar.bz2 (for quilt, stgit)

主な変更点としては、

• 画像サイズの制限に関するバグ修正 (174x144, 352x288, 704x576 で確認) 。
• PPE 側の処理の最適化に関するバグ修正。

ちなみにテストで主に使用している動画は、H.264 規格の標準化で使用され たと思われる ココ の動画の一番動きの激しいもの (SOCCER_*.yuv) を使用しています。

コンパイルは PS3 + SDK 2.0 (+ libspe2) と x86 Linux PC + SDK 2.1 で確 認してあります。上記の patch をダウンロードして、x264 r635 に適用して下さ い。後は以下を実行することでバイナリが出来ます。

$ ./configure
$ make cell

x264 for cell をバージョンアップしました。

• patch-x264-cell-r635-070411.bz2
• patches-x264-cell-r635-070411.tar.bz2 (for quilt, stgit)

主な変更点としては、

• 幾つかのバグ修正 。
• パフォーマンス計測機能の追加 (SPE で行う各種処理の実行時間や DMA 実 行時間を計測して表示します)。
• PPE 側の処理の最適化 (SPE への処理の割り当て方法や sched_yield() に よるスケジューリングの最適化)。

上記で最適化とありますが、SPE 側は何を追加するにしても大規模な変更が 必要であるため、こちらは変更せずに PPE で出来る範囲で最適化してあります。

コンパイルは PS3 + SDK 2.0 (+ libspe2) と x86 Linux PC + SDK 2.1 で確 認してあります。上記の patch をダウンロードして、x264 r635 に適用して下さ い。後は以下を実行することでバイナリが出来ます。

$ ./configure
$ make cell

Cell SDK 2.1 がリリースされましたので、Momonga trunk rev:15290 にインストールしました。と言ってもベースは Fedora に近いので、なんの問題もなく toolchain のインストールとサンプル等のコンパイルができてます。

で、肝心の Cell SDK 2.0 との差分ですが、先日リリースした x264 for cell を 2.0, 2.1 でコンパイルして、spu 用のバイナリを readelf したところ、printf() 等の newlib 関連の関数のサイズには違いがありましたが、x264 の関数のサイズには違いはありませんでした。

但し、spu overlays のサンプル (overlay) の spu 用バイナリを objdump -d してみると、overlay 用に toolchain が用意するコードが若干変わっているようです (se.o は相変わらず、非 overlay section です)。

Cell 上で x264 が動作するようになりました。とは言っても SPE が行うの は動きベクトル探索のみで、SPE も有効に使えてないので速くないです (つまり、 とりあえず動きましたレベル)。

• patch-x264-cell-r635-070331.bz2
• patches-x264-cell-r635-070331.tar.bz2 (for quilt, stgit)

コンパイル環境は PS3 + SDK 2.0 を想定しており、libspe2 が必要です。ま ずは上記の patch をダウンロードして、x264 r635 に適用して下さい (2007/03/31 の trunk は r636 ですが、PPC でコンパイルできないので一つ古い revision です)。あとは、

$ ./configure
$ make cell

すれば、怪しげな warning が沢山でますが、x264 と SPE 上で動作する x264_me_thread_spu が出来ます。あとは、通常と同様に x264 を実行すればデバッ グメッセージと共に SPE を使用してエンコードします (多分、400x300 以上の画 像でないと動きません)。

詳しい説明等は来週以降ということで、、