2011年9月26日月曜日

RawSource.dll その6

RawSource26(avisynth2.6.0以降専用)を更新しました。

rawsource_26_dll_20110925.zip
https://github.com/chikuzen/RawSource_2.6x

*widthの最大値を65536に変更。
*あらたに最大解像度を設定(width x height <= 134217728)。
*その他少々の手直し(出力には影響なし)

必要なもの
avisynth2.6.0α2以降
sseが使えるマシン
msvcr100.dll (Microsoft Visual C++ 2010 再頒布可能パッケージのことです)

以前、読み込み用のバッファの確保をオリジナルのMAX_WIDTH x 4から動的確保に変更したので、現在のコードベースにおけるwidth及び解像度の上限は、単に非常識に大きな数値を入力された場合のout of memory回避のために設けてあります。
とりあえず最大width4096で十分だろうと思っていたのですが、一部の変な人達にはそれでは足りないらしいので増やしました。
まあ、たとえwidth=65536, height=2048の場合でも、
読み込み用バッファのサイズは65536*4=256KiB (RGB32の場合)
avisynthが用意する1フレーム分のメモリは134217728x4=512MB(RGB32の場合)
なので、とりあえずこれだけでクラッシュすることは無い(はず)です......大丈夫だといいなぁ

それにしても最近のDoom9はMTとhigh-bit-colorと64bitでグチャグチャになっておりますな。
自分はそういうハックに夢中になる暇があるなら、とりあえずさっさと2.6.0の正式リリースに漕ぎ着けられるよう、協力体制を取って欲しいものですが。
2.6.0が正式リリースになれば2.5.8なんて誰も使わないのは目に見えてるんですから、もはや2.5.8でも使えるような配慮は単なる時間の無駄だと思っています。

2011年9月20日火曜日

xvidcore-1.4.0

今月に入ってxvidのMLに幾つかビルド関連のパッチを投げたりしてみた。
http://list.xvid.org/pipermail/xvid-devel/2011-September/thread.html

もともと自分はただビルドするだけなのにパッチを当てたりするのは嫌いである。
第一に、パッチの存在を知らない人間にはパッチは役に立たない。
第二に、パッチを管理するのはめんどくさい。
第三に、殆どの場合ビルドエラーの原因はあほらしい理由によるものなので、原因が分かったときに激しい虚しさに襲われることになる。

たしかに開発本家にパッチ投げるのってパッチ書く以上にめんどいけど、やらないといつまでもその状態が続いてしまうので、とりあえず出来そうなところは修正してもらったほうがいいだろう。

で、まあ、結果としていくつか採用されてsvnにコミットされたので、いままで必要だった手間は幾分減ることになった。
次のstable release予定の1.4.0では、インストール時にライブラリを別名でコピーするくらいで済むのかな。

追記 2011年10月22日
Ubuntu11.10上でクロスコンパイルしようかと思いsvnのログを確認してみたら、ライブラリ名変更のリクエストもちゃんと受理してもらえてました。
http://websvn.xvid.org/cvs/viewvc.cgi?view=rev&revision=2044
これで自分としてはパッチは完全に不要になりました。
Isibaarさん、ありがとうございました!

2011年9月19日月曜日

avs2pipemod その8

更新しました。

avs2pipemod-20110919.zip
https://github.com/chikuzen/avs2pipemod

*新機能'trim'を追加。

Doom9で「avs2yuvみたいに-seekや-framesをサポート出来ないか」とリクエストを受けたので追加してみました。
内部でavisynthのTrim()を呼び出すだけの簡単なお仕事だし、まああっても邪魔にはならないと思ったので。

使い方
avs2pipemod -y4mp -trim=100,200 input.avs > output.y4m
というふうにすれば、avsの最後にTrim(100,200)を書いたのと同じようになります。
-infoと-x264bdでは無視されます。

ところでリクエストしてきたStephen R. Savage氏は別名thewebchatというファンサブ界の厄介者らしい。
そーいや昔120fpsAVIの作り方とか調べてたな…物好きなこと。

2011年9月4日日曜日

コンパイラによる最適化の押し付けにむかついた件について

GCCの各オプティマイズレベルで有効になる最適化を調べるを読んでちょっと興味がわいたので、いろいろ手元の環境でも確認してみた。
試したマシンはQ9450とT7300のせいかどれもリンク先と同じ結果になったわけですが、とにかく意外だったのは
*-O2と-Osの違いは-finline-functionsの有無だけ(-Osは有り、-O2は無し)。

-Osはサイズ優先の最適化のはずだけど、-O3(とにかくスピード優先)でも-finline-functionsがつくのであれば、これを有効にすればそこそこスピードアップの可能性があるということだろう。
じゃあ、-O2の存在意義って一体なあに?
-O3程ではないが、それなりにスピード優先のはずなんだけど…。

とまあ、前置きはこのくらいにして、今度は各プロジェクトが設定しているデフォルトの最適化設定を調べてみた。

例えばx264は--extra-cflagsを設定しなければ
"-O3 -ffast-math -march=i686 -mfpmath=sse -msse -fomit-frame-pointer -fno-tree-vectorize -fno-zero-initialized-in-bss"
がつく(x86の場合)。
いかにも互換性を気にしつつも速そうな設定という感じですね。
まあ、クリティカルな部分はほぼすべてasmで書かれてCPU検出で自動的に有効にするので、コンパイラによるCコードの最適化はあまり影響しないそうですが。

これがxvidだと
"-O2 -fstrength-reduce -finline-functions -ffast-math -fomit-frame-pointer"
となっている。
configure.inには
First we test if CFLAGS have been passed on command line
I do that because autoconf defaults (-g -O2) suck and they would kill performance.
To prevent that we define a good defult CFLAGS at the end of the script if and only
if CFLAGS has not been passed on the command line
なんて書かれてますが、それにしては中途半端という印象が否めない。
現在でも更新は続いているんだから、いい加減sseをデフォルトにするくらいはしてもいいのでは?
configure.inにはこのデフォルト値に対して"Default CFLAGS -- Big impact on overall speed"とも書かれているあたり、コンパイラによる最適化はかなり重要みたいなんだけど…自分で設定したほうがよさそうですな。

さて問題はa52dec。
これのconfigure.inは以下のような感じになっている。
if test x"$GCC" = x"yes"; then
    changequote(<<,>>)
    OPT_CFLAGS=`echo "$CFLAGS"|sed "s/-O[0-9]*//g"`
    changequote([,])
    OPT_CFLAGS="$OPT_CFLAGS -O3"
    AC_TRY_CFLAGS([$OPT_CFLAGS],[CFLAGS=$OPT_CFLAGS])
なんとコンパイラがGCCだったら有無を言わさず-O3強制です。
たとえば何らかの理由でデバッグビルドしようと思ってCFLAGS="-O0 -g"しても、-O0は削除されて"-g -O3"なんていうへんてこりんなコードが出力されてしまいます。
しかも-O3は勝手につけるのに、-fno-tree-vectorizeはなし。
liba52はとても古いプロジェクトでCVSの最終更新は7年前。もはや死んだといってもおかしくない。
当時は-O3だけでも問題なかったのかも知れませんが、現在ではまともな出力が得られるかどうか非常に疑わしい、地雷コードと化しています。
これは不安定な-ftree-vectorizeを-O3で有効にしたままなかなか直さない(直せない?)GCCが悪いとも言えるかも知れないけど、素人がコードいじらなきゃいけないような自体はなるべく避けて欲しいなぁ。
とりあえずこんなパッチを書いてみたので、何かの事情で今時a52decをビルドしなければならない人は当てたほうがいいかもしれません。

あともう一つ、openjpegプロジェクト。
現在のstable release?であるはずのopenjpeg_v1_4_sources_r697.tgzをビルドしてみたら、設定したCFLAGSが全く反映されません。
なんでかな?とlibopenjpeg/Makefile.amを見てみたら
INCLUDES = -I.. -I.
COMPILERFLAGS = -Wall -O3 -ffast-math -std=c99
if with_sharedlibs
COMPILERFLAGS += -DOPJ_EXPORTS
else
COMPILERFLAGS += -DOPJ_STATIC
libopenjpeg_la_LDFLAGS += -static
endif
CFLAGS = $(COMPILERFLAGS) $(INCLUDES)
お前もかよ(そしてこれも-fno-tree-vectorizeなし)。
svnの最新コードなら直ってるかなと見てみると今度はcomfigure.acのほうで
if test "x${want_debug}" = "xyes" ; then
   OPJ_COMPILER_FLAG([-g])
   OPJ_COMPILER_FLAG([-O0])
else
   OPJ_COMPILER_FLAG([-O3])
fi
あくまでも-O3は決定ですかそーですか...........むかつくわホント

追記:
gcc4.7ではOsに-foptimize-strlenも追加されたようです(O2は追加なし)。
ますますO2の存在意義って…?