他のシステムのインストールがなくなる？
こちらよると「他のシステムのインストール」がなくなる？
http://japanese.engadget.com/2010/03/29/ps3-v3-21/
最近PS3はDVDプレーヤーと化しているものの、「他のシステムのインストール」があるから旧型を残しているのに。旧型からこの機能を削除するのだけはやめてくれ。
コメント
コメントどうもです。
最近すっかりがんばっていません。x264の場合は規模が大きいのでどの処理ブロックをSPEにさせるか難しいです。
当初はとにかくSPEのLSに押し込んで、これを7つのSPEで並列に走らせるつもりでしたが、8段のパイプラインのように処理させた方がよいかもしれないと考えはじめ、そうするとx264のオリジナルコードをそのままとはいかずちょっとめげています。
CUDA対応のTMPGEncも苦労しているようですが、難しいですね。あちらは自前のコードですし、仕事ですからだんだんこなれてくるんでしょうね。
LarrabeeはCellに似てますが、メモリ管理はCPUがやってくれるのが羨ましい。SPEはDMAでまいどまいど転送するのが面倒くさい。
最近我が家のPS3もすっかりDVDプレーヤーと化しているです。もちべーしょんがあがったらまたがんばります。
pixel_satd_wxhのSIMD化
あけましておめでとうです。
さてなんとかpixel_satd_wxhもSIMD化して、さらに速くなりましたが、元通りとまではいかず。
とりあえず現状をまとめて、上の階層をSPUに持ってくることになりそう。
今回の速度は、
- SPU(SIMD化)
- 477秒
- PPU(前回の測定値)
- 320秒
前回PPUのrefine_subpelの処理時間は98秒で、それ以外の処理時間は222秒。ということはSIMD化したSPUでは255秒かかったことになる。前回SPU側の処理を呼び出して、LSへメモリを転送するだけの処理が219秒かかったことになっているので、SPUの実処理時間は36秒。ちょっと嘘がある。今回はDMA転送を関数の最初でスタートして処理する直前で転送完了を待つようにしたのでメモリ転送しながら少し処理している。が、それでもかなり速度アップしたことになる。ええこっちゃ。
とはいえ、結局メモリ転送に時間がかかってプラスマイナスのマイナスになっている。次は上の階層としてx264_me_search_refのSPUに移動するか。その前にSDK3.0もインストールしたほうがいいし、オリジナルコードもだいぶリビジョンが上がっているだろうし、マージせねば。
refine_subpelの検証
前日のちょっとがっくりな結果をもう少し調べる。
まずはSPUで処理した場合とPPUで処理した場合の違い。
- SPU
- 2.20 fps 815.859 sec
- PPU
- 5.59 fps 320.839 sec
- PPU+SPU
- 1.96 fps 913.871 sec
ということは、913-815の98秒がrefine_subpelのPPUでの実行時間。全体が320秒なので、98/320=0.30、つまり全体の30%の処理となる。2月にgprofでとったプロファイルの結果とほぼ同じなので、妥当な値だろう。
逆に913-320の593秒がrefine_subpelをSPUで実行した時間。PPUが98秒だから6倍も時間がかかっている。うー。遅すぎ。で、どこがネックか。
- PPU+SPU(呼び出すだけ)
- 4.54 fps 394.674 sec
- PPU+SPU(呼び出してMEM->LS転送するだけ)
- 3.33 fps 539.166 sec
呼び出すだけというのはmbox経由でSPUに処理を渡して、何もせずに戻るだけにした場合の時間。394-320で74秒。呼び出してMEM->LS転送するだけというのは、SPU側でメインメモリからLSにメモリを転送するだけで何も処理せず戻る時間。539-320で219秒。すると592-219の373秒がSPUによる処理時間ということになる。PPUの4倍弱。PPU側はAltivecだけどSPU側は普通のコードだしなー。メモリ転送も遅いなー。ブロック単位でちょこまかコピーしているからなー。
まずSPUの処理をSIMD化して、メモリ転送ももう少し考えなければ。もっと上の関数からSPU化して呼び出し回数減らさないとなー。AltivecのコードはそのままSPUでビルド通るんだっけなー。
