「 2011年07月 」一覧

OpenGLでのテクスチャレンダリングパフォーマンスについて


OpenGLでテクスチャレンダリングをする場合には、いくつかの方法が考えられます。

  • FBO(FramebufferObject)をレンダリングごとに用意
  • FBOを1つ作っておいて、その中に書き込み先となるテクスチャを再セット
  • pbufferを使う

最後のやつは、かなりレガシーな古いコードとなりそうなので、
最近の環境であればFBOを使うことにしておいた方がいいと思う。
それでも上記のような2ケースがあるので、どちらがいいか検討してみたいと思う。

ちなみにFBOはiPhone環境でも使えるようで、
OpenGL ES 2.0世代な環境ならば標準的に使えるのかもしれない。
それならますますFBOで良さそうってもんです。

Next-Generation Rendering with OpenGL
“http://origin-developer.nvidia.com/object/gdc_2005_presentations.html”

上記のURLからGDC2005での発表資料をゲットできる。
今となっては6年前の資料だからどこまで信用して良いかわからない。
(6年も立てばGPUのアーキテクチャやドライバも相当進化するし)。

実験

100枚のレンダー先となるテクスチャを用意し、
それぞれにFBOを用意するタイプ(TYPE1)と、FBOは1つでバインドするテクスチャを交換していくタイプ(TYPE2)の2ケースで速度を計測してみました。

環境は、Windows7 SP1で、AMD RADEON 6850 を使用しています。
コンパイラはVisualStudio 2010 Pro です。
計測はリリースビルドで行っています。

種別 速度
TYPE1 4~5 ms
TYPE2 5~6 ms

微妙な差ですが、それぞれFBOを用意してあげる方がより高速な結果となりました。

AMD製なので資料の主張と異なる結果が出てくるかと思っていましたが、同じ結論を得ることが出来て一安心です。

まとめ

テクスチャレンダリングの際にはテクスチャごとに専用FBOを用意してあげるほうがよい。


RemoteFXを試す -失敗編-


先日NVIDIAのGTC2011に行ってきました。
そこでWindowsServer2008R2のRemoteFXについてのデモもあったので見てきました。
パンフレットもゲットです。

一応そこそこのパフォーマンスでDirectXアプリケーションも動くようなので、
この機能を使ってみようと思いました。とりあえず手元でこれらを実験してみます。

  1. WindowsServer2008R2をインストール
  2. Hyper-Vとリモートデスクトップの役割を構築
  3. 仮想マシン(ゲストOS)にWindows7 Ultimateをインストール
  4. インストールしたWindows7 UltimateにServicePack1を適用

ここまで出来たら一度、別マシンからWindows7マシンへ向けてリモートデスクトップを接続できることを確認しておきます。RemoteFXを有効にしてしまうと、リモートデスクトップ接続からしか仮想マシンを操作できないためです。
うまく動作するようなら、仮想マシンを一度止めて RemoteFXデバイスを追加します。

まず仮想マシン側のWindows7 SP1で、ファイアウォールの設定を修正します。「リモートデスクトップ」には既にチェックが入っているものの、「リモートデスクトップ-RemoteFX」という別のルールにはチェックが入っていないです。そこでこれを有効にするようにチェックを入れます。

しかしそれでも
「このユーザーアカウントはリモートログインを許可されていないため、接続は拒否されました。」とエラーになり、RemoteFX 3Dデバイスを有効化した状態の確認をすることはできなかった。

RemoteFX 3Dデバイスの有無で接続可否が変わるので、何かまだ必要な設定があるのかもしれない。一体何が設定まだ足りないのか不明なのですが、一旦ここで終了です。


AMDのOpenGLドライバ


AMDのOpenGLドライバの本体は、
atioglxx.dll(x86), atio6axx.dll(x64)なわけですが、
Catalystを10系から更新したら、このdllの所在が分からなくなってしまいました。
従来は、どちらも System32におかれていたと思います。現在 Catalyst 11.6 ですが、この状況でdllを検索してみたら以下の場所にありました。

  • atio6axx.dll : windows/system32 に配置.
  • atioglxx.dll : windows/system32/SysWOW64 に配置.

またどちらにおいても egl系の関数が含まれていましたので、
OpenGL ESを試すこともできそうです。
NVIDIAのグラフィックボードでも、egl系が使えるようになると
両環境でOpenGL ESを試しやすくなっていいと思うので、そうなってくれないかなーと願ってます。


6850に交換&CubeMapGS性能テスト


ボード交換

グラフィックボードをRADEON HD 6850に換装しました。
5450->6850なので、かなり性能UPです。

この過程で、Catalystのバージョンもあがってしまいました。
現在は、11.6 を使用している状況です。

以前にドライバを更新したらOpenGL環境下でうまく動かなくなった、というトラブルも(今のところはなく)一安心です。

CubeMapGS結果

うちの環境では性能向上が特に分かりそうなCubeMapGSでテストしてみました。

環境 オプション FPS値 9800GT時 5450時
球体モデル UseInstancing 164 119 28
球体モデル 250 61 38.2
車体モデル UseInstancing 80 44 8
車体モデル 98 32 9

以前のテスト結果も一緒に記載してみました。
これをみるとさすがに性能向上を実感できます。
そもそも5450がメモリバス幅64bitだったからなおさらという点もあります。

そしてどうもNVIDIA時には、このUseInstancing有効のほうが得意で、AMD製ではUseInstancingが不得意な印象を受けます。

参考:以前の日記


熱暴走?


ThinkPad T420でESXiいれてサーバーにしていたんだけど、
なにやら熱暴走したっぽい。
家中のネットワークが死亡して、ルーターがかなり熱かったから
そちらを疑っていたけど、まさかサーバーだったとは。

とりあえずは再起動して、風通しをもうちょっと気をつけて設置して様子見です。
ひさしぶりにESXiのパープルスクリーンを見ました・・・。


ゲームプログラマになる前に覚えておきたい技術のコード修正


ゲームプログラマになる前に覚えておきたい技術 のVisualStudio2010対応版を更新しました。修正点は Windows Vista/7 上でヒープ破壊メッセージが出てくるという点です。

配布ページはこちら

情報

  • 起動されたオブジェクトはクライアントから切断されました。
  • ヒープが壊れていることが原因として考えられます。RoboFightFinal.exe または読み込まれた DLL にバグがあります。

などというメッセージが出ている場合には、この修正版で直ります。

補足

出版社のほうから出ている修正版を適用後に、
こちらで配布しているデータを上書きする形にしてください。
(既知のバグについては、slashは修正していませんので…)