VSYNCを待たない問題(描画処理を待たせてみた)

フレーム時間の70%を経過してから描画処理が開始されるように設定してみたところ、目論見通り他の処理を高速化できた。最初の状態の10秒以上が0.5秒になると言ったところ。ほぼVSYNCを待つ環境と同様なのでこの方向で間違いはないだろう。

あとは描画負荷に合わせて待ち時間を調整したりフレームバッファの初期化なんかを待ち時間の前に入れて並列性を高めてみたりでこのあたりは完成とする。VSYNCに同期できないのは腹立たしいが現状では難しいので後回しにしとく。

VSYNC問題は続く

glSwapBufferがVSYNCを待たない問題はまだ解決していない。これを解決しないと何してもクッソ遅いので避けて進むわけにはいかないし。VSYNCを待つような設定や処理にしても待つのは処理がVSYNCを跨ぐ場合だけで、そうでない時は何も待たないのでほとんど意味がない。これはAMDのドライバだけでなくIntelのドライバも同様だ。

描画スレッドを待たせるだけなら周期的に描画スレッドを寝かせればいい。VRでは描画タイミングが大事なのでVSYNCからの時間情報が欲しいところだがないなら仕方ないというところで、ひとまず周期の最初の半分以上は描画スレッドを寝かすことにする。pthreadはコオペレイティブなので他のスレッドが長引くと大きく時間が狂うわけだが...。

---

Bloggerが吐くHTMLがアホなので直接HTMLで書くことにした。改行なんて吐いてんなよ。しかも微妙に間違ってるし。

VSYNC問題

グラボのドライバの中にはVSYNC待ちを無視してくれるものがあって、そういうドライバに当たると描画が忙しくてメッセージの転送や処理が回らなくなることがある。また逆に画像転送などのようにメッセージ処理に時間を取られて描画が疎かになったりする。なので描画とメッセージ処理を別のスレッドにした。スレッドの管理にはpthreadを使う。

メッセージ処理といってもテクスチャのアップデートなどがあるので描画スレッドとOpenGLのリソースは共有しなければならない。X環境ではこれはglXCreateContextでGLXコンテキストを作るときに元のGLXコンテキストを指定してやることでできる。なお、子コンテキストは親スレッドで作る。

で、子コンテキストを作ったらスレッドを起こす。スレッドで子コンテキストをglxMakeCurrentすればおしまい。glxMakeCurrentを調べればわかるがpthreadのスレッドはGLXコンテキストを切り替え対象にしててちゃんと切り替えてくれる。余計な心配は要らない。