SL-C3000いじり (随時追記)

Zaurus

KeyHelperはまだ入れてないんだけど、znesterでキーを押しっぱなしにしても処理落ちしない。

フレームバッファは速くなってる気がする。SL-C860までのQVGAモード+znesterではわりと速い180度ローテーションが使われていたが、SL-C3000ではフレームバッファの仕様変更により遅い90度ローテーションを使うようになっている。それでも体感的な速度は変わっていない。

PXA270 LCDCのデータシートを真面目に読んだ。なかなか大変そうだ。カーネルに手を入れないとオーバレイは使えないような雰囲気だが、とりあえずモジュール経由でいじってみることにする。

DMAの設定を行わずにオーバレイを有効にしたらホワイトアウトして固まった。そりゃそうか。DMAの設定にはSL-B500用のコード？(cotulla_fb.c)が参考になりそうな感じだが……。どっちみちカーネルソースが公開されるのだから、こんな泥臭い方法で無駄なことをするのはやめたほうが良さそう。素直にカーネルソースを待つことにする。(すでにオーバレイに関するコードが入っていることを期待して。入っていないとカーネル入れ換え必須になるな)



$ time ./mplayer -vo null -ao null -really-quiet -frames 720 /mnt/card/RL_XQ_640x480_1500_128.avi

real    0m35.410s

user    0m26.340s

sys     0m2.110s

んで、iWMMXt版IPPとリンクしたmplayerでベンチを……と思ったら、demux_open内でSIGILL。んなバカな、と思って調べたところ、浮動小数演算で落ちている。試しにCPARに0を書き込んで実行すると落ちない。なんてこった！ iWMMXtと未定義命令例外による浮動小数演算(hard-float)は両立できないのか？

以前soft-floatについてかるく調べたとき、glibcも含めてすべてのライブラリをsoft-floatで作り直さないとならないように思えたので面倒になって放置していたが、真面目に対応策を考えないといけないのか……。

CPAR=0の状態だとvmemも実行できたので、その結果。



Read rate: 39.26MB/s

Write rate: 37.91MB/s

Memory write rate: 245.27MB/s

Memory transfer rate: 40.76MB/s

上で速くなってる気がするって言ったのは気のせいじゃなかった。メインメモリ->VRAMの速度がC750の2倍ですよ。VRAM->メインメモリにいたっては10倍速以上。640x480 16bppで64fps出る計算で(C750では24fps)、320x240だと258fps！(C750では96fps)。PocketPC機のベンチからしてもう一声速い感じを予想していたのだけど、まぁ贅沢は言いません。これで十分。あとで塚本さんのところの表に追加しておこう。

多分PXA270に内蔵されている256KBのSRAMは使われていないと思う。640x480の動画でもUVプレーンだけなら内蔵SRAMに置くことができるので、さらに速度が上がることになる。

でもQtopiaのほうでは遅くなっている(らしい)のがよく分からんところではある。

あとは液晶パネルが480x640になっているのが不満なだけ。まぁ文句を言ったところで仕様が変わるわけでなし、気合い入れてrotate blitterを書きますか。

なにげなくQVGAモードで実行したらこんなことに。



Read rate: 57.73MB/s

Write rate: 38.96MB/s

Memory write rate: 266.24MB/s

Memory transfer rate: 46.64MB/s

なるほど。QVGAモードでは内蔵SRAMが使われてるんですな。んで、LCDリフレッシュの帯域分だけMemory transfer rateが速くなるわけですな。Write rateがあまり変わらないのが残念だけど、Memory tranfer rateのほうで十分に恩恵が受けられそうだ。

えーちなみにこのLCDCにはImageon 100に無い(と思われる)Indexed Paletteな2bpp,4bpp,8bppモードがある。たとえばPC-9801は4bppなので(PlanerとPackedという違いはあるが)、それに最適化すれば単純に考えて640x400の画面が256fpsで更新できる。PC-9821の8bppでも128fpsか。まぁこれは極端な例。実際には画面更新以外の処理がかなり重そうだし、最適化するにしてもグラフィックまわりを全て書き直す勢いだと思うので労力が半端じゃない。それぐらいのポテンシャルはあるって話です。

これらは僕の知識内で適当に思い付いたことを書いてるだけなんで、鵜呑みにしないでください。そして、それは違うだろってところがあったら遠慮無く突っこんでください。かなり不安です。

http://lists.arm.linux.org.uk/pipermail/linux-arm/2004-January/006877.html

hard-float vs soft-float。わかりやすい。やはりsoft-floatにするにはlibcを含め、すべてのライブラリとアプリケーションをsoft-floatで再ビルドする必要がある、と……。

外部ライブラリの関数でfloatを引数に使っていなければ原理的には問題は無いように思える。しかし、オブジェクトファイルにはその関数がhard-float/soft-floatのどちらで作成されたかが記録されており、たとえfloatを使っていなくても異なるフォーマットのオブジェクトはリンク出来ないようになっている。binutilsでこのエラーチェックを無視するようにすれば、リンクすることも不可能ではないと思う。しかし、mplayerの規模になると普通にfloatを引数に取るlibcの関数(printfだとか)を使いまくっているわけで、この方法で無理矢理リンクしたところで動かないのは目に見えている。

根本的には、CP0/CP1を有効にした場合だけカーネルのFPUエミュレータに制御が渡らないのが問題。これを解決する方向で動くのが今のところは最適解だと思う。とりあえずドキュメントを漁ってみるが、カーネルソースが無いとどうにもならない予感。ソースが出ても僕程度の力ではどうにもできないかも。

別の解は……pdaXromなどの全て自前でビルドすることが可能なシステムを使う……。

まぁ新たにソフトを書き起こすのであれば、一切floatを使わないことで対応は出来ますな。CP0/CP1を有効にした状態でもQtopiaのほうは問題無く動いているみたいなので。

IPPにrotate blitterがあったらいいなぁ、なんて横着なことを思ったけど無かった。残念。

CP0だけを有効にすると浮動小数演算とiWMMXtの両方が通るようにみえる。多分、CP1側がサポートするiWMMXt命令が動かないんだろう。