kernel 2.6.23.1-10.fc7

ひさびさにyum updateしたらFedora7の2.6.23カーネルがインストールされる様子。今のところrc3のカーネルはちゃんと動いているので文句はないけど(oprofileできなかったけど)、まーこれも経験なのでアップデートしてしまう。

で、アップデート後再起動。起動は無事に行われる。当然。で、

>poweroff

おー、シャットダウンしたよ。

次に

>reboot

おー、リブートしたよ。

最後に

>ps3-boot-game-os

うむ?またFedora7が起動した。rc3カーネルだと問題なかったのに。ちゃんとboot flag changedと出るんだけどなー。shutdownして電源を入れ直すとgame-osが起動したので、フラッシュのフラグは変わっていると思う。ささいなバグですな。

まー、11月11日まではgame-osは起動しないことにしよう。

refine_subpelのSPU化

SPU化するコードを精査するためにoprofileを実施してみた。が、2.6.23-rc3カーネルはoprofileのモジュールが入っていないので実行できず。へたれな自分としてはカーネルコンパイルまでせず、fedora純正カーネルの2.6.22でbootして実行する。なぜかcallgraphは取れないけど実行結果は得られた。2月のgprofの結果とは違う部分もあるし同じような部分もある。

CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples  %        symbol name
44654    16.7263  x264_frame_filter
30927    11.5845  mc_chroma_altivec
23211     8.6943  quant_4x4
17810     6.6712  get_ref_altivec
12499     4.6818  ssim_4x4x2_core
10960     4.1053  pixel_satd_8x8_altivec
9851      3.6899  pixel_satd_16x16_altivec
9810      3.6746  pixel_satd_4x4_altivec
5958      2.2317  zigzag_scan_4x4_frame
5829      2.1834  refine_subpel
5489      2.0560  x264_me_search_ref
5416      2.0287  add4x4_idct
5016      1.8789  dequant_4x4
4551      1.7047  x264_frame_deblock_row
3964      1.4848  x264_macroblock_cache_load
3924      1.4698  ssim_end4
3769      1.4118  pixel_sad_x4_16x16_altivec
2944      1.1027  x264_macroblock_probe_skip
2720      1.0188  x264_mb_analyse_intra
2712      1.0158  add8x8_idct
2636      0.9874  zigzag_scan_4x4ac_frame
2252      0.8435  x264_macroblock_encode
2204      0.8256  x264_cabac_encode_decision
2038      0.7634  pixel_sad_x3_16x16_altivec
1985      0.7435  pixel_satd_8x16_altivec
1976      0.7402  pixel_sad_16x16_altivec
1885      0.7061  mc_copy_w16
1878      0.7035  x264_macroblock_cache_save
1864      0.6982  pixel_ssd_16x16_altivec
1787      0.6694  block_residual_write_cabac
1713      0.6416  pixel_sad_x4_8x8_altivec
1542      0.5776  predict_16x16_p
1372      0.5139  pixel_satd_4x8_altivec
1339      0.5016  x264_macroblock_analyse
1317      0.4933  pixel_satd_16x8_altivec
1221      0.4574  mc_copy_w8
1201      0.4499  add16x16_idct
1148      0.4300  x264_sub8x8_dct_altivec
1124      0.4210  pixel_satd_8x4_altivec
944       0.3536  pixel_sad_x3_8x8_altivec
935       0.3502  x264_mb_encode_8x8_chroma
898       0.3364  x264_mb_predict_mv_ref16x16
838       0.3139  x264_deblock_h_luma_altivec
823       0.3083  mc_luma_altivec
805       0.3015  predict_8x8c_p
737       0.2761  pixel_sad_8x8_altivec
732       0.2742  x264_mb_predict_mv
719       0.2693  x264_macroblock_write_cabac
661       0.2476  deblock_v_chroma_c
653       0.2446  x264_mb_encode_i4x4
650       0.2435  deblock_h_chroma_c
634       0.2375  pixel_sad_x4_8x16_altivec
600       0.2247  predict_4x4_hd
561       0.2101  x264_mb_analyse_inter_p16x16
535       0.2004  predict_4x4_vr
461       0.1727  x264_slice_write
404       0.1513  pixel_sad_8x16_altivec
401       0.1502  predict_4x4_vl
390       0.1461  quant_2x2_dc
383       0.1435  x264_cabac_mb_mvd
381       0.1427  x264_analyse_update_cache
358       0.1341  x264_pixel_ssim_wxh
349       0.1307  predict_4x4_ddr
337       0.1262  pixel_sad_x4_16x8_altivec
337       0.1262  x264_mb_analyse_inter_p8x8
330       0.1236  pixel_sad_x3_8x16_altivec
292       0.1094  predict_4x4_ddl
288       0.1079  x264_sub4x4_dct_altivec
285       0.1068  x264_mb_predict_mv_16x16

以後省略

で、この結果や2月のプロファイル結果やコードを見て、refine_subpelをSPU化してみることにする。

x264_fdec_filter_rowのSPU化

x264_fdec_filter_rowのSPU化が動作するようになったのでパッチをアップします。2月にプロファイルを取ったときに全体の約20%の処理時間がかかっていた所です。場所はいつものところ

ベースのコードはr656のままです。

  • SPU化 1スレッド
$ time ./x264 -q 26 ../spiderman2.y4m -o spiderman2.spu.264
yuv4mpeg: 720x480@29970029/1000000fps, 0:0
x264 [info]: using cpu capabilities Altivec
x264 [info]: slice I:9     Avg QP:23.00  size: 11150  PSNR Mean Y:51.27 U:54.89 V:54.90 Avg:52.13 Global:46.43
x264 [info]: slice P:1783  Avg QP:26.00  size:  3911  PSNR Mean Y:42.51 U:46.64 V:47.31 Avg:43.54 Global:43.32
x264 [info]: mb I  I16..4: 68.6%  0.0% 31.4%
x264 [info]: mb P  I16..4:  4.3%  0.0%  4.5%  P16..4: 16.1%  6.8%  1.6%  0.0%  0.0%    skip:66.6%
x264 [info]: SSIM Mean Y:0.9736544
x264 [info]: PSNR Mean Y:42.551 U:46.685 V:47.345 Avg:43.586 Global:43.328 kb/s:946.33

encoded 1792 frames, 5.56 fps, 946.42 kb/s

real    5m22.410s
user    3m37.496s
sys     0m9.006s
  • SPU化 2スレッド
$ time ./x264 --threads 2 -q 26 ../spiderman2.y4m -o spiderman2.spu2.264
yuv4mpeg: 720x480@29970029/1000000fps, 0:0
x264 [info]: using cpu capabilities Altivec
x264 [info]: slice I:25    Avg QP:23.00  size: 15437  PSNR Mean Y:46.90 U:50.35 V:50.51 Avg:47.77 Global:45.57
x264 [info]: slice P:1767  Avg QP:26.00  size:  3802  PSNR Mean Y:42.51 U:46.69 V:47.34 Avg:43.55 Global:43.33
x264 [info]: mb I  I16..4: 63.9%  0.0% 36.1%
x264 [info]: mb P  I16..4:  4.1%  0.0%  4.2%  P16..4: 16.2%  6.9%  1.6%  0.0%  0.0%    skip:67.0%
x264 [info]: SSIM Mean Y:0.9737038
x264 [info]: PSNR Mean Y:42.575 U:46.736 V:47.384 Avg:43.613 Global:43.350 kb/s:950.47

encoded 1792 frames, 8.46 fps, 950.63 kb/s

real    3m32.154s
user    5m17.233s
sys     0m13.426s
  • SPU化 6スレッド
$ time ./x264 --threads 6 -q 26 ../spiderman2.y4m -o spiderman2.spu6.264
yuv4mpeg: 720x480@29970029/1000000fps, 0:0
x264 [info]: using cpu capabilities Altivec
x264 [info]: slice I:25    Avg QP:23.00  size: 15437  PSNR Mean Y:46.90 U:50.35 V:50.51 Avg:47.77 Global:45.57
x264 [info]: slice P:1767  Avg QP:26.00  size:  3802  PSNR Mean Y:42.52 U:46.69 V:47.34 Avg:43.56 Global:43.33
x264 [info]: mb I  I16..4: 63.9%  0.0% 36.1%
x264 [info]: mb P  I16..4:  4.1%  0.0%  4.2%  P16..4: 16.2%  6.9%  1.6%  0.0%  0.0%    skip:67.0%
x264 [info]: SSIM Mean Y:0.9737074
x264 [info]: PSNR Mean Y:42.577 U:46.737 V:47.387 Avg:43.615 Global:43.351 kb/s:950.47

encoded 1792 frames, 9.81 fps, 950.63 kb/s

real    3m3.142s
user    5m44.396s
sys     0m16.975s

相変わらず1スレッドはPPUの方が速い。うーむ。どこかに妙な待ちが入っているのか?2スレッドと6スレッドはPPUより速いです。前回の6スレッド版よりも速いので、少しはSPU側で実行する部分が増えて効果が出たということにします。

全体の20%の部分なので、この速度が0になっても処理時間は4/5にしかならないので、まーこんなもんですかね。

さてさて次はx264_macroblock_analyse関数が本命ですが、大きそうなのでx264_me_search_ref関数あたりから攻めますか。コードを見ながら考えましょう。

x264_frame_deblock_rowのSPU化

x264のx264_frame_deblock_row関数のSPU化がだいぶできてきたけど、PPUより遅い。イメージデータの転送が遅いのか、SIMD化していないから遅いのかと色々試しても速くならない。調べた結果、イメージデータはまとめてDMAしていたけど、設定情報系(x264_tで定義されたパラメータ系)を手抜きして変数ごとにDMA転送していたのがまずかった様子。この点を直すことで少なくともPPUと同じレベルには戻りそう。まだバグっているけどもう少しか。

しかし手抜きを許してくれませんなー。

kernel 2.6.22.4-65

先ほどyum updateするとカーネル2.6.22.4-65が入った。

とりあえず起動はできる。が、ps3-ehci-driverがいろいろ文句を言っている様子。シャットダウン時もusbあたりで止まっている。うー。いまいち。最近はもっぱらsshでPCからログインして使っており、こちらにはメッセージがでないけどいい感じじゃないなー。

ubuntuとかのほうが安定しているかなー。

Fedora7再インストール

結局Fedora7を再インストールしています。LVMなしです。

前回同様にネットワーク経由のインストールにすると途中で止まる。しかたなく最低限のソフトのみでとりあえずインストールを行う。

yum updateで問題の2.6.22.1-41カーネルを入れる。再起動。あら?あかんやっぱり止まる。結局よくわからん。

あきらめて現在SDKインストール中。なんか俺の時間を返せー、という感じ。

これを機にPC側もFedora7をインストール。--nosimオプション付きでインストールすると./cellsdk buildが通らない。ヘッダーファイルが無いといわれる。よくわからんがsimulator付きでインストールするとbuildが通る。まーいいや。

LVM

前回の日記から2週間ほどたち、再度yum updateし、カーネルを2.6.22-1.41.fc7に上げました。が、相変わらず起動しません。2chPS3の初心者板だとLVMはダメとのこと。yboot.confの起動パラメータのquietオプションを削除し起動すると確かにLVMのVolumeが見付かっていない様子。うー。デフォルトでLVMになっていたからLVMにしたのに。いれなおしかなー。新しいカーネルは電源切れない問題も直っているという話だしなー。夏休みだしいれなおすかー。面倒だなー。