Tech と Culture

テクノロジーとカルチャー

motion JPEG再生 3

作成した、ioctlを用いて16個データを unsigned int 型で送り込んで再生しました。
結果は、2.78fps です。
IOCTL_WRITE, IOCTL_PUSH どちらを用いても変わりませんでした。readyのチェック自体は重くないことが分かります。IOCTL_PUSHでは、カーネルに制御が移ってからまとめて、readyのチェックとデータ書き込みを行っています。read, writeハンドラを使うと、readyのチェックで毎回カーネル空間とアプリケーション空間を行き来してしまいます。ここが、IOCTLの良さです。前回の1ライン分まとめて、writeハンドラに渡すものより性能が落ちているのはただ単に一回に渡すデータの量が少ないため、コンテキストスイッチの回数が増えているからだと予想しています。

その他、ユーザー空間からカーネル空間へデータを渡す作業の重さがまだ分かりません。ここが重いのならば、メモリからYCbCr-RGB変換モジュールにデータを直接転送するDMAコントローラを設計し、デバイスドライバは、そのDMAコントローラをキックするだけにする等が思いつきます。

その他、送るデータの個数を変えたり、FIFOの大きさを変えたりして、性能を上げるためにいろいろやって勉強するという手もあると思いますが、ここで一旦一区切りにして次のフェーズに進みます。

というのも、ここで一生懸命性能を上げても勉強になっても大して性能があがらないからです。
とりあえず、INTELプロセッサ上で実行したプロファイルでは、huffman decode ,IDCT, YCbCr-RGB変換の順に処理が重かったです。

performance.png

図のようにハードウェア化した部分が処理が殆ど一瞬で終わり、かつデバイスドライバのオーバーヘッドをどんどん無くして行ったとしても性能は20%UPで頭打ちです。
逆にIDCT,Huffman decodeをハードウェア化して、そのインターフェースやデバイスドライバを一生懸命追い込めばかなり性能が上がることが予想できます。

もともと、あまりにも要素技術をしらないために作ったマイルストーンでしたので、要素技術習得はできたということで、次に IDCTのハードウェア化に進みます。

やっぱり、趣味の日曜工作ですから、ムービーが綺麗に動くところを見てみたいという単純な動機です。