ようこそゲストさん

すらりん日記

2011/09/03(土) remoteFXを試す -成功編-

Hyper-V
前回チャレンジしたremoteFXネタですが、
yamasaki さんのアドバイスもありうまく動作させることが出来ました。

環境構築

前回同様WindowsServer2008R2 SP1をインストールして、
Hyper-Vを構築、仮想マシンとしてWindows7 Ultimate SP1を用意しました。

動作させている環境は以下の通りです。
  • CPU : Intel Core i5 650
  • Mem : 8GB
  • Graphics: RADEON 5450, Intel HD Graphics
2008R2環境下で一番困ったのはグラフィックドライバが、
うまくインストールされないことでした。
Intel HD Graphics用ドライバインストールするも、途中でエラーが発生するし。
RADEONはCatalystのインストールで失敗するし。

結局CatalystなしのDisplayDriver onlyなパッケージをダウンロード・インストールすることで正常にRADEONは認識できました。
Intelのほうは、ドライバのインストール失敗しているっぽいのに、
何やら再起動したらうまく認識できているようなそんな感じです。

設定方法

仮想マシンWindows7 Ultimate SP1を仮想マシン設定はデフォルトのままインストールします。
そしてWindows7のインストールが完了し、通常のリモートデスクトップを受け付ける設定にしておきます。

ここで1度、別クライアントから接続を確認しておきます。

続いて、
"コントロールパネル"-"システムとセキュリティ"-"システム"を開き、
"リモートの設定"-"ユーザーの選択"ボタンをクリックします。
現在のユーザーにアクセス権が既に設定されていますと明記されていても、
追加ボタンで、ユーザーを追加します。これが大切なポイントみたいです。

ここで一度Windows7を終了しておきます。

Hyper-Vの仮想マシン設定を開いて、remoteFX 3Dデバイスを追加します。
追加した後で再度仮想マシンWindows7を起動します。
この時点ではまだHyper-Vのウィンドウで表示されます。
起動して、remoteFX 3Dデバイスが認識されると再起動を促されるので、
そのまま再起動を行います。
すると、Windowsが起動する途中でHyper-V側のウィンドウでは表示できなくなります。

そうなったら、別PCからリモートデスクトップで接続します。
うまく接続できればremoteFXが有効になっている可能性が高いです。
手元の環境では、Aeroの設定がOFFになっていたので、
手動でAeroのテーマを使うようにしてみました。うまく半透明効果が適用されることが確認できました。

デバイスマネージャーで見ると、
"Microsoft RemoteFX Graphics Device - WDDM"というデバイスとして見えるようです。

動作確認

若干動作が重い気がしたのですが、
どんな感じで動くかを意地悪にもテストしてみました。
  1. 最近のOpenGLアプリのテスト
    1. 動作しないようです。
    2. VertexBufferObject等のサポートがありませんでした。
    3. またこのことからも当然のごとく、GLSLもシェーダーアセンブラも不可能でした。
  2. ビデオ再生
    1. リモートの中からさらにファイルサーバーにあるファイルを再生してみたところ、
    2. ある程度は再生可能なものの、たまに正常に再生されないフレームが発生。
      1. 試したファイルは .ts の録画したファイルです。
    3. 仮想マシン内ローカルHDDにコピーして再チャレンジ
    4. うまく動作している模様。変なフレームが表示されるようには見えない.
  3. DirectX9を用いた自作アプリ
    1. ShaderModel 3でコンパイルしているシェーダーを用いて描画しているコードが通りました。

どうもネットワーク帯域をかなり喰うようですね。
また、OpenGLのサポートは全然ダメなようです。
これからWebGLとか流行り始めたらこの部分も強化されるでしょうか…。

その他

remoteFX有効時だからか、スタートメニューに出てくる切断の部分が
シャットダウンが標準となっていました。
気をつけないとリモートデスクトップ切断したつもりが、
仮想マシンを電源OFFしたことになってしまいそうです。

2011/08/30(火) ESXi 5.0を試す

vmware
先週に公開されたvSphere Hypervisor ESXi 5.0をダウンロードして、
実験マシンにインストールしてみました。

インストール直後に、”お!”と思ったポイントをあげてみます。
  1. RealtekのNICがデフォルトで認識された!
  2. 画面が広くなった。
    1. 文字しかないコンソール画面なのであまりメリットはないですが。
  3. データストアに"非SSD"なる文字が。
    1. SSDを認識するってことですか、これは。
  4. vSphereClientに表示されるメモリ使用量がなんかアテにならない?
さて、vt-dそなえた環境なのでVMDirectPathをまた試してみました。
Intel HD Graphicsをメインとして、RADEON HD 5450を増設し、
これをパススルーできるか試してみたところ、失敗。
AMD製CPUとの組み合わせなら、うまくいったという話もあるし、
IOMMU機能についてはAMDのほうが充実なのかもしれません…

2011/08/29(月) ESXi4.1での蟹NICについて

vmware
ESXi 4.1上でRTL8111/8168を使える設定にしておいて、
しばらく放置していたために発覚しなかった点があった…。

たまたまの問題かもしれないが、H55のチップセットで、
このNICしかない状態でESXiを起動し、Windowsゲストを起動させたところで
うまく動かない点を見つけてしまった。

症状は、以下の2点確認できた。
  • 仮想マシン内のNICにDHCPでアドレスが割り当てられないこと。
  • 固定IPを手動で振って、検索エンジンへWebアクセスさせたがBadrequestになってしまう点
どうもうまく機能していないんじゃないかと思う。
これをIntel NICに取り替えてみたところすんなり動いたし。
やっぱりESXiはIntelのNICを準備しておかないとダメっぽい。

なおこの実験やってる最中に、手持ちのIntel PRO/1000MTが死亡しているのを確認。
家に在庫があっても故障していたりするし、困ったもんだ…。

2011/08/28(日) XenServer6(beta)に期待してみたが。

XenServer
先日 XenServer6(beta)を入手できるようになり、
新機能が魅力的に思えたので、まずはVMwareWorkstationにインストールしてみた。

魅力的な機能としては、
  • ライブマイグレーション
  • GPUパススルー
ってところです。
以前にもXenServerはインストールして使ってみたことがあるのですが、
フリー版は年1回のライセンス更新があってちょっと面倒に思ってしまい最近は止めてしまっています。
この点は、今も昔も変わらずみたいです。


さて、インストールは順調に成功して、
普段使っているWindows7のPCにXenCenterをインストールして早速接続。
仮想マシンをWinXP SP3を作成し、OSインストールしない設定で仮想マシンだけ用意してみました。

なぜって、デバイスのパススルー設定がどのようになるか確認したかったからです。

さて見てみると・・・GPUの項目があるのですが以下のようになっています。

xen_gpu.png

これを見る限りフリー版ではダメみたいです。
さらに調べてみたところ、Enterpriseエディション以上じゃないとダメみたい。

うーん、残念。

Xen4系列をFedoraやCentOSなどにいれて、GPUパススルー環境を作るしか
方法はないのかもしれません。

ちなみに Xen4.0.1をCentOS6に入れてみたのですが、
そちらもGPUパススルーは失敗。ブラックアウトしたままでした。
なかなか難しいですね。

2011/08/03(水) NVIDIA PathRenderingがすごい

NVIDIAからOpenGL拡張のすごいやつがでました。
GL_NV_path_rendering という拡張です。
これは、アウトラインフォントやベクターグラフィックスのようなパス情報からデータを描画する拡張です。

情報はこちらに:http://developer.nvidia.com/nv-path-rendering


3Dグラフィックスにおいては処理がどんどんGPU担当なのに、
ベクタ画像の2DグラフィックスではまだCPUが処理を担当しているという背景からこの拡張が生まれたようです。

この拡張は既存の3Dグラフィックスパイプラインにあたらしいパイプラインが使えることを意味するようです。
  1. 頂点シェーダー入力のかわりに、パス情報の入力
  2. パスの変形処理
  3. パスのフィル、ストローク、の処理
  4. この結果からラスタライズ処理
  5. ピクセル(フラグメント)シェーダー処理
  6. フレームバッファに格納
こんな感じでパイプラインが構築されています。
詳しくは、イントロダクションのpdfを参照ください。

パス情報については、SVGやPS(PostScript)のサブセットが使えるようです。


なかなか強力な拡張が入ってきたと思うのですが、
NVIDIAだけなので使用用途はまだまだ限定的ですね。
ですが、そのうちに自分でもコードを書いてみようかと思っています。

2011/08/01(月) PVRテクスチャ形式の解析 その1

解析というほどでもないですが…調べてみた&わかったことをしばらく書いてみたいと思います。
PowerVR-SDKをダウンロードすると中に文章が入っています。
これが全てなのですが、防備録も兼ねてメモしていきます。

必要な物は PVTRC Texture Compression.Usage.Guide(PVRTexLibの中のドキュメント)です。ここにファイルの中の画像データに関する情報が詰まっています。
ほか、PVRTCアルゴリズムの元であるSimon Fenny氏の論文"Texture Compression using Low-Frequency Signal Modulation"です。

PVRTC圧縮の特徴

  • 2BPP/4BPPから選択
    • RGBA8の画像に比べると 1/16, 1/8の圧縮率
  • 2べきサイズの正方形な画像である必要がある
  • アニメ調は不向きで写真のほうが向いている
  • スマートフォン用GPUではこの形式を直接扱える
    • PowerVR系ならば.
    • Tegra2とかでは使えない。

処理概要

PVRTCのデータから圧縮を解除してみることを考える。
PVRTCデータを伸張すると仮想的な3つのイメージデータが出てくる。
この3つのデータを合成し、最終的な画像を生成する。
ざっくり説明してしまうとこんな感じ。

3つの画像データのうち、1つはその他2つの画像をどのように合成するかのパラメータが格納された物である。
そして、2つの画像データ(画像A, 画像Bとしておく)は、元の画像データと比較して1/4のサイズになっている模様。

2011/07/25(月) 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 です。
計測はリリースビルドで行っています。
種別速度
TYPE14~5 ms
TYPE25~6 ms
微妙な差ですが、それぞれFBOを用意してあげる方がより高速な結果となりました。

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

まとめ

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

2011/07/24(日) RemoteFXを試す -失敗編-

Hyper-V
先日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デバイスの有無で接続可否が変わるので、何かまだ必要な設定があるのかもしれない。一体何が設定まだ足りないのか不明なのですが、一旦ここで終了です。

1: yamasaki 『同じく「このユーザーアカウントはリモートログインを許可されていないため、接続は拒否されました。」と出ました。。原因がわからず・・・』 (2011/08/28 27:23)

2: yamasaki 『原因が分かりました。 仮想環境のWindows 7 SP1を起動して、コントロールパネル→システムとセキュリティ→システム→リモート設定のリモートデスクトップで、 「ユーザーの選択」ボタンを押して、コンピュータ名¥ユーザー名(仮想環境に構築したWindows 7のコンピュータ名とユーザー名)を登録しておく。 を明示的にやるとつながる事が分かりました。「****にはアクセスがすでに与えられています。」と書いてるんですけどね。 RemoteFx 3Dデバイスを外した場合は、ユーザ追加しなくてもつながることからRemoteFx特有の何かがあるようですね。』 (2011/08/29 4:29)

3: yamasaki 『http://cloud.watch.impress.co.jp/docs/column/virtual/20100913_392477.html を参考にしました。』 (2011/08/29 4:31)

4: slash 『情報および解決策をありがとうございます。 こちらでも再度環境を用意してやってみたいと思います!』 (2011/08/31 21:22)

2011/07/23(土) 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を試しやすくなっていいと思うので、そうなってくれないかなーと願ってます。

2011/07/20(水) 6850に交換&CubeMapGS性能テスト

ボード交換

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

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

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

CubeMapGS結果

うちの環境では性能向上が特に分かりそうなCubeMapGSでテストしてみました。
環境オプションFPS値9800GT時5450時
球体モデルUseInstancing16411928
球体モデル-2506138.2
車体モデルUseInstancing80448
車体モデル-98329
以前のテスト結果も一緒に記載してみました。
これをみるとさすがに性能向上を実感できます。
そもそも5450がメモリバス幅64bitだったからなおさらという点もあります。

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

参考:以前の日記(291)