主な変更点としては、
x264 のソース管理が subversion から git に変更されていますので、まず は git (StGIT) をインストールして下さい。Fedora(rpm) 系では以下のように します。
$ yum install git stgit
1 patch を使用する場合と、series patch を使用する場合の 2 通りの方 法を用意してありますのでお好きな方をどうぞ。
$ 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
$ 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) が出来 ます。
]]>echo 1 > /proc/sys/kernel/sched_compat_yield
また、関連する commit は以下になります。
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 してみるとすでに以下の記事があってガックリなわけですが、、
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 のドライバを作成するというのも考えていますが、、
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() は使用せず、 スピンロックする(実行権を放棄しない)ようです。
状況による、というありきたりな答えになってしまいますが、 mutex, cond によるロック期間が短ければ sched_yield() を使用しないほうが有利、ロック期間 が長かったり、PPE 上で複数のスレッドが動作する場合は sched_yield() を使用したほうが有利 という感じになるのかな、、
]]>それなら他にもバグらしきものがあるので送ってみようということで、以下のバグ修正 patch を送っています。
[x264-devel] fix x264_macroblock_analyse and x264_mb_analyse_p_rd functionsこの修正も 8x4, 4x8, 4x4 のサブマクロブロックに関するもので、Cell 対応の過程で発見したものです。どれも非常にわかりにくい修正なので何か反応が欲しいところですが、ML 上ではやっぱり反応なしです。
]]>で、patch の内容ですが、
というように本体の修正や、SPU 用の各種関数を作成する上で見つけたものです。 で、このメールを出したのは 11/22 なんですが、全く誰からも反応なしです。 確かに 1 以外はテスト用のもので、1 に関しても p4x4、それも chroma が対象で、patch を適用しても エンコード結果にほとんど影響しないのですが、バグじゃないのかなあ、、
他にもバグらしきものが数点あり、そのうちでも堅いと思われる修正を出したつもり なのですが、どうするかな、、
]]>今回の patch に含まれる 3 関数は、(エンコード用オプションを色々と追加した場合、) それほど負荷があるわけではないため、SPU化の優先順位は非常に低いのですが、 現状では PPU への負担が大きいため、この負担を軽くするのが目的です。
]]>前回の更新後、ずっと DCT, 量子化、ジグザグスキャン等を行う x264_macroblock_encode() の SPU 化を検討していました。が、検討を進めていくと芋づる式に trellis や rd 系の処理も必要に なってきて、そうすると256KBオーバーになり、ずっと頭を抱えていました。で、余裕がなくなり、blog の 更新も止まるという悪循環に、、blog は継続することが重要なのに、イザとなるとなかなか出来ない ですね。
現在は一応の目処がついたので、実装を進めています。
ということで、上記の検討で SPU 用の関数を実装する上で、 PPU(Altivec) の関数を幾つか 実装したので、それを x264-devel ML に送って本体に反映してもらっている所です(commit 済み)。
[x264-devel] add optimised functions ]]>ということで、残った google-perftools を使っています。これも callgraph がおかしかったり、変数が関数として表れたり、怪しいところがあり ますが。
で、この google-perftools、FC5 の時にはよく使っていたのですが、FC6 に した後、しばらく使用しておらず、久々に使うにあたっててこずったため、現象 をまとめておこうと思います。
なお、SDK は 2.1 を使用し、x264 を 32bit でコンパイルしているため、 google-perftools 自体も PS3 上で以下のようにして configure と make をして います。
$ ./configure CC=ppu-gcc CXX=ppu-g++ CFLAGS=-m32 CXXFLAGS=-m32 $ make
google-perftools 自体のコンパイル、x264 とのリンクが出来ていました。
google-perftools 自体のコンパイルは出来るのですが、x264 とリンクしよ うとすると、以下のようなエラーが出ます。
$ ppu-gcc -o x264 x264.o matroska.o muxers.o libx264.a -lm -m32 -lspe2 -lpthread -lprofiler /usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetIPInfo@GCC_4.2.0' collect2: ld returned 1 exit status $
マズイなあと思ったのですが、ダメ元で toolchain を SDK 2.1 (ppu-gcc) から FC6 (gcc) に代えてコンパイル (リンク) してみると、
$ gcc -o x264 x264.o matroska.o muxers.o libx264.a -lm -m32 -lspe2 -lpthread -lprofiler $
出来ました、、実行させてみましたが、エンコード結果も同じになるので、 正しく動作しているようです。
予想としては、エラーメッセージの GCC_4.2.0 から toolchain のバージョ ンの差によるものかなとは思っていますが、判明していません。ま た、_Unwind_GetIPInfo と出ていまずが、x86 の場合はスタック解析用に libunwind というライブラリの使用を推奨しているようです。
ちなみに FC6 の toolchain のバージョンは gcc-4.1.1-30、 binutils-2.17.50.0.3-6 で FC6 インストール時と同じ、SDK 2.1 のバージョン は ppu-gcc-4.1.1-10、ppu-binutils-2.17.50-8 です。
google-perftools 自体のコンパイルが出来ません。調べてみると google-perftools は x86 上でしか動作しなくなったよう (solaris は不明) で、 Fedora ppc 用 rpm も 0.8 までしかないようです。 ML のログ を見ると、PPC MAC OS X 用の patch が流れていましたが、適用しても PS3 で はコンパイル出来ず、、
現在は、x264 と google-perftools-0.8 は SDK 2.1 の toolchain でコンパ イルして、プロファイルしたい時は、FC6 の toolchain でリンクのみしています。
Fedora 7 もリリースされていて、この件が判明するまでは、おりを見てイン ストールしようと思っていましたが、思案中です。調べてみると、Fedora 7 の toolchain のバージョンは、gcc-4.1.2-12、binutils-2.17.50.0.12-4 で、FC6 とは違いますね、、
]]>前回同様、テスト用の動画は 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 (出力ファイル名)
x264 を Cell 対応することで、速度がどうなったか？また、実際に SPE を使用 することで速度がどうなったかです。version は以下を表し、 速度の指標は x264 自体がエンコード後に出力する fps (frames per second) を使用します。
| CPU/SPE | version | thread num | fps |
|---|---|---|---|
| 1PPE/6SPE | r635 070412 cell | 1 | 1.28 fps |
| 1PPE | r635 | 1.44 fps | |
| 1PPE/6SPE | r635 070530 cell | 1.90 fps | |
| core2duo (E6600) | r635 070412 cell sim | 2.70 fps | |
| core2duo (E6600) | r635 070530 cell sim | 3.55 fps | |
| core2duo (E6600) | r635 | 6.39 fps |
やっと 1PPE r635 よりも速くなりましたが、今回から載せている core2duo r635 と比べるとまだまだという状況です。
x264 の --threads オプションで同時に処理するフレーム数 (thread num) を変化させた 場合の結果です。
| CPU/SPE | version | thread num | |||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ||
| 1PPE/6SPE | r635 070412 cell | 1.28 fps | 1.55 fps | 1.94 fps | 2.04 fps | 2.06 fps | 2.06 fps |
| 1PPE | r635 | 1.44 fps | 1.77 fps | 2.02 fps | 2.10 fps | 2.09 fps | 2.09 fps |
| 1PPE/6SPE | r635 070530 cell | 1.90 fps | 2.30 fps | 2.88 fps | 3.02 fps | 3.14 fps | 3.16 fps |
| core2duo (E6600) | r635 | 6.39 fps | 9.12 fps | 12.44 fps | 13.09 fps | 13.12 fps | 13.15 fps |
core2duo r635 は、4GB の RAM を積んでいるため、入力ファイル全体 (360MB) がキャッシュされてしまい、2 回目以降の実行ではディスクアクセスが ほとんど発生しません (しかし、PS3 の RAM は 256MB なのでキャッシュは有効 に働かないと予想される)。。キャッシュによる高速化は、正確には Cell とは関 係ありませんが、キャッシュされた場合のデータを掲載しています。
thread 数が 4 以降でも若干ながら高速にはなりますが、大枠では PPE の SMT による高速化率 (1.5 倍) による制約が大きいため、もっと SPE 側に処理 自体を移動させる必要があります。
| thread num | SPE num | active rate | proc rate | SPE 有効稼働率 |
|---|---|---|---|---|
| 1 | 0 | 10.49 % | 67.89 % | 6.89 % |
| 1 | 9.84 % | 67.84 % | ||
| 2 | 9.83 % | 68.27 % | ||
| 3 | 10.45 % | 67.76 % | ||
| 4 | 10.00 % | 68.03 % | ||
| 5 | 10.30 % | 67.68 % | ||
| 2 | 0 | 12.32 % | 67.75 % | 8.31 % |
| 1 | 11.39 % | 68.31 % | ||
| 2 | 12.71 % | 67.89 % | ||
| 3 | 11.88 % | 68.26 % | ||
| 4 | 12.53 % | 67.91 % | ||
| 5 | 12.43 % | 68.27 % | ||
| 3 | 0 | 15.64 % | 66.90 % | 10.43 % |
| 1 | 14.40 % | 67.19 % | ||
| 2 | 16.48 % | 66.72 % | ||
| 3 | 15.37 % | 66.87 % | ||
| 4 | 15.67 % | 67.23 % | ||
| 5 | 15.86 % | 67.09 % | ||
| 4 | 0 | 16.34 % | 66.71 % | 10.94 % |
| 1 | 15.18 % | 66.91 % | ||
| 2 | 17.13 % | 66.69 % | ||
| 3 | 16.31 % | 66.52 % | ||
| 4 | 16.71 % | 66.87 % | ||
| 5 | 16.67 % | 66.80 % | ||
| 5 | 0 | 17.31 % | 66.14 % | 11.40 % |
| 1 | 16.02 % | 66.46 % | ||
| 2 | 17.90 % | 66.34 % | ||
| 3 | 16.79 % | 66.43 % | ||
| 4 | 17.63 % | 66.36 % | ||
| 5 | 17.46 % | 66.54 % | ||
| 6 | 0 | 17.21 % | 67.07 % | 11.52 % |
| 1 | 16.12 % | 66.85 % | ||
| 2 | 17.84 % | 67.14 % | ||
| 3 | 16.93 % | 66.75 % | ||
| 4 | 17.53 % | 67.22 % | ||
| 5 | 17.64 % | 66.85 % |
proc rate が前バージョンから改善 (57% -> 67%) されていますが、このバー ジョンから DMA リスト自体を分割して複数の 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]]>
SPE 用のコードを CPU で動作させる SPE シミュレーションモード (sim) を持っています。具体的に何をしているかと言うと、
です。最初から SPE での動作を目指すと、実際に動作し始めるまでの難関 (メモリの制限や複雑な DMA 転送) が多いため、バグが取れずに挫折する可能性 が高いと感じ、このモードを付けています。このモードにより、実際の開発はほ とんど Linux PC 上で行っており、結果を確かめながら変更していくことが出来 ました。但し、ソースが非常に複雑 (#ifdef の嵐)になってしまっています。
上記の複雑な DMA 転送というのは、参照画像から実際に動きベクトル探索で 利用する部分を切り出す処理に相当するのですが、具体的には以下の 2 つです (当然、他にもDMA 転送しているデータはあります)。
両者ともに画像の切り出し位置は、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 (出力ファイル名)
まずは、x264 を Cell 対応することで、速度がどうなったか？また、実際に SPE を使用 することで速度がどうなったかです。version は以下を表し、 速度の指標は x264 自体がエンコード後に出力する fps (frames per second) を使用します。
| CPU/SPE | version | thread num | fps |
|---|---|---|---|
| 1PPE | r635 | 1 | 1.44 fps |
| 1PPE | r635 cell sim | 0.56 fps | |
| 1PPE/6SPE | r635 cell | 1.28 fps | |
| core2duo (E6600) | r635 cell sim | 2.70 fps |
以上のように、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) ということであまり減っていません。 これは、以下の理由が挙げられます。
次に x264 の --threads オプションで同時に処理するフレーム数 (thread num) を変化させた 場合の結果です。
| CPU/SPE | version | thread num | |||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ||
| 1PPE | r635 | 1.44 fps | 1.77 fps | 2.02 fps | 2.10 fps | 2.09 fps | 2.09 fps |
| 1PPE/6SPE | r635 cell | 1.28 fps | 1.55 fps | 1.94 fps | 2.04 fps | 2.06 fps | 2.06 fps |
このように thread 数が多くなると 1PPE r635 でも SMT が効いて速くなり ますが、thread 数が増えるにつれて r635 cell 版も 6 SPE が有効に働くよう になり、両者がほぼ同じ (やや負け) 位の速度でエンコード出来るようになって います。
最後は、じゃあ SPE はどのくらい有効に働いているの？ですが、
とすると、thread オプションに対する各 SPE の active rate, proc rate は以下のようになります。
| thread num | SPE num | active rate | proc rate |
|---|---|---|---|
| 1 | 0 | 8.785670 % | 56.992781 % |
| 1 | 7.836577 % | 62.490412 % | |
| 2 | 9.204857 % | 59.048293 % | |
| 3 | 7.165960 % | 62.844794 % | |
| 4 | 8.986283 % | 59.062187 % | |
| 5 | 7.035920 % | 63.182083 % | |
| 2 | 0 | 10.107968 % | 58.416470 % |
| 1 | 10.614589 % | 57.817723 % | |
| 2 | 10.468447 % | 58.328175 % | |
| 3 | 10.941708 % | 57.527256 % | |
| 4 | 9.579995 % | 58.968929 % | |
| 5 | 11.060721 % | 57.915997 % | |
| 3 | 0 | 13.042938 % | 56.386892 % |
| 1 | 13.761920 % | 56.516727 % | |
| 2 | 13.516308 % | 57.191141 % | |
| 3 | 14.277174 % | 56.623944 % | |
| 4 | 12.060944 % | 55.693047 % | |
| 5 | 14.179765 % | 56.892087 % | |
| 4 | 0 | 13.767162 % | 57.188217 % |
| 1 | 13.889416 % | 55.032239 % | |
| 2 | 14.238510 % | 57.168836 % | |
| 3 | 14.951388 % | 56.861344 % | |
| 4 | 13.150053 % | 57.438491 % | |
| 5 | 14.789294 % | 56.637078 % | |
| 5 | 0 | 14.068798 % | 56.949056 % |
| 1 | 14.711695 % | 56.617446 % | |
| 2 | 14.316511 % | 56.909902 % | |
| 3 | 15.203619 % | 56.853118 % | |
| 4 | 13.312675 % | 57.666773 % | |
| 5 | 15.163975 % | 57.012929 % | |
| 6 | 0 | 14.075775 % | 57.279934 % |
| 1 | 14.796232 % | 56.791326 % | |
| 2 | 14.559752 % | 57.344442 % | |
| 3 | 14.659463 % | 55.245073 % | |
| 4 | 13.371265 % | 57.493847 % | |
| 5 | 15.155458 % | 57.292702 % |
--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 % ということになります。
]]>主な変更点としては、
ちなみにテストで主に使用している動画は、H.264 規格の標準化で使用され たと思われる ココ の動画の一番動きの激しいもの (SOCCER_*.yuv) を使用しています。
コンパイルは PS3 + SDK 2.0 (+ libspe2) と x86 Linux PC + SDK 2.1 で確 認してあります。上記の patch をダウンロードして、x264 r635 に適用して下さ い。後は以下を実行することでバイナリが出来ます。
$ ./configure $ make cell]]>
主な変更点としては、
上記で最適化とありますが、SPE 側は何を追加するにしても大規模な変更が 必要であるため、こちらは変更せずに PPE で出来る範囲で最適化してあります。
コンパイルは PS3 + SDK 2.0 (+ libspe2) と x86 Linux PC + SDK 2.1 で確 認してあります。上記の patch をダウンロードして、x264 r635 に適用して下さ い。後は以下を実行することでバイナリが出来ます。
$ ./configure $ make cell]]>
で、肝心の 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 です)。
]]>コンパイル環境は 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 以上の画 像でないと動きません)。
詳しい説明等は来週以降ということで、、
]]>他にも PS3 用 の usb, fb/av driver のマージも行われています。ただ、 net や logo 関連でまだマージされていないものが幾つかあるようので PS3 で はまだ使用できないと思います (Linuxppc-dev ML を追いきれてません、、)。
ともあれ、詳細は以下をご覧下さい。
]]>