EXA Performance Issues

　Carl WorthのBlogでのEXAのi965用ドライバのパフォーマンス問題に関する一連の記事が面白かった。
　EXA使うよりアクセラレート機能を使わない方が速い、おかしい！というところから、DRI有効にすると速くなるよ、でもそれでもまだいくつかのテストはEXA enabledな場合の方が遅いよ、と話は進んでいく。
　その後は、i965_prepare_compositeが遅いけど、なんでかしら？→opannotateを使うと関数レベルでどこが遅いのか報告してくれる→いくつかの代入がすごく時間を食ってる→ビットフィールドへの代入がキャッシュされてないメモリへのread-modify-writeを起こしており、これが遅い→スタック上に欲しい値を一回作り上げて、それからmemcpyで代入すると速い　という流れでひとつの改善がされている。
　ここにちょっと疑問があって、キャッシュされてないから遅いって書いてあるんだけど、理由が間違ってるんじゃないかという気がする。diffを見ると変更点はスタック上に構造体を一個確保して、それに対して代入をしてから最後にmemcpyをしているだけ。これで速くなるということは、最初のコードではキャッシュできないビデオメモリ（i965にビデオメモリはないけどな）に対して代入しており、変更後のコードではスタック上の（当然キャッシュに乗る）メモリへ代入しているので、結果として速くなっている、ということなんじゃないかなと思う。まぁ、もともとのアドレスがビデオメモリなのかどうかわからないし、そもそもビデオメモリがキャッシュできるものなのかどうかすら知らない（もっと書くとビデオメモリがこんな風にいじれるものなのかどうかすら知らない）ので、あんまり強く主張はできないんだけど。
　他にも、libcがやたらと実行時間を占めてる→ビデオカードのロックアップを検出するためにgettimeofdayを呼んでるからなんだけど、これは数千回に一回程度呼べば十分だよね、というような話とかもある。
　で、そうやってホットスポットを潰していけば速くなるのかというと、実は大して速くならない。i830WaitSync(pScrn)を呼んでstateをsyncさせるところでbusy waitが発生するので、ホットスポットを潰してもこのbusy waitの部分に速くたどり着けるようになるだけなので、ほとんど処理時間は変わらない。ボトルネックとホットスポットで説明されているとおりの現象だ。（全体としてはちょっとは速くなっているので、まったく同じ現象とは言えないかも知れないけど。）