CELLプロセッサ

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 への負担が大きいため、この負担を軽くするのが目的です。