「 Windows8 」一覧

DirectX11の場合のシステムメモリとVRAM消費について


今までは OpenGL の場合を調査してきました。今回は DirectX11の場合を調べてみようと思います。ドライバが一緒ならきっと同じ傾向を示すんじゃないかなと予想して実験をスタートです。

実験

DirectX11のプログラムとして、100フレームごとに頂点バッファ 32MB を確保し、次フレーム以降はこのデータを使って描画するプログラムを作成しました。
各フレームでの各メモリの使用状況を取得して、グラフ化しました。

実験は以下の環境で行いました

  • GTX750Ti Windows 7 347.09
  • RADEON HD 5450 Windows 7
  • RADEON HD 5450 Windows 8

結果

それぞれの実験結果のグラフを以下に示します。

nvidia_memory_graph_dx11_win7

radeon_memoy_graph_dx11_win7

radeon_memoy_graph_dx11_win8

NVIDIA も AMD も同じような挙動を示す結果となりました。また VRAM が使用可能な状態であれば、追加のシステムメモリの消費もなく良好といえそうです。(とはいっても追加のメモリを要求されたのは NVIDIA OpenGL の場合のみでしたが)。さすが仕様が決まっている DirectX といえるかなと思います。
 ちなみに RADEON のほうのグラフ末尾がおかしなことになっていますが、このときアプリは相変わらずフリーズ状態になってしまいました。ですので、システムメモリを VRAM リソースとして使用始めたらやや注意が必要になっていきそうです。ビデオメモリ仮想化が入ったといわれる現時点においても、なるべく搭載量を超えないようにするのはマナーとしておいたほうがよさそうです。


Windows 8でXAudio2のトラブルに出遭う 解説編


前回の日記でふれたVisualStudio 2012 + XAudio2 + Windows 8 というコンボ発動で、アプリケーションを正常に起動出来ない!という罠にはまった内容を説明したいと思います。

実は、Windows 7で使用している(できる)最新のXAudio2は、 2.7 というバージョンのもので、これは DirectX SDK 2010 Juneに含まれています。またDirectXの再頒布ランタイムをインストールすることで導入できます。
一方、Windows 8で標準で使用するXAudio2は 2.8 というバージョンのものになります。これは VisualStudio 2012付属のWindows SDKを使用してアプリケーションを作成するとこちらを使うようになります。

標準状態の Windows 8 では、XAudio2は 2.8 のものだけが入っており、従来のDirectX SDKを使用していると 2.7のものを要求するために動作しません。
.Net framework をインストールした後で、DirectXのランタイムをインストールすると、Windows 8でも動作するようになりますが、これをアプリケーションを単に動かしたい人々がやるには手間もいいところです。
できるなら、そのままアプリケーションが動くのを目指したいところです。

これを表にするとこうなります。

DirectX SDKを使ってXAudio2 Windows 8ではそのまま動作しない
VS2012のWindowsSDKでXAudio2 Windows8では動作、Windows7では動かない

Windows7までの環境では対応したDirectX再頒布パッケージがあるのでそれをインストールすることができます。
ただそれらをインストールすること無しで XPから8まで、単一アプリケーションとしてサウンドを再生するには、実はDirectSoundを使用すると良さそうです(XPの標準状態でもDirectSoundは含まれていました)。

おそらくVista以降のDirectSoundはXAudio2より上位にレイヤーとしては位置付けられているようなので、
これを使うことでXAudio2に関係する依存関係を断ち切ってくれそうです。
ただし、DirectSoundは既にレガシーなAPIとなっているため、そのあたりが懸念事項でしょうか。
ただ互換性の点からOSから使用できない・削除されているわけではないため、XPから8まで一応使うことは出来るようです。

※ そのため単一アプリとして提供する際にはとても都合がよかったり。

DirectX9とXAudio2と。

D3DX関連のAPIもVS2012のWindows SDKに入っていないので、DirectX9+XAudio2という構成は VisualStudio 2012での開発にとってはなかなかの鬼門といえそうです。シェーダーのコンパイルはD3DXですし、XAudio2は今回のような問題があるし。

再頒布ランタイムをとりあえず強引にででもインストールさせるのであれば、DirectX SDK 2010 Juneを使って開発しておくでOKでしょう。
なるべくなら標準の状態で開発&配布したいと考えるなら、DirectX9やXAudio2を諦めて、OpenGLとDirectSoundを選択しておくと、余計なことを考えずともどこでも動く状態の物ができあがるように思います。

Windows Vista以降だけでよいというなら、WASAPI も選択肢に上がってくるかと思いますが、これは使うのが大変なので手軽にという点も考慮するなら、やはり情報も多いDirectSoundでお茶を濁しておくのが手っ取り早いでしょう。

参考元
XAudio2 Versions


Windows 8でXAudio2のトラブルに出遭う


VisualStudio 2012を使っていたら、Windows8でのXAudio2で問題に遭遇したのですが、
この件で、有名な吉野屋テンプレがうまく使えそうだと閃いたためちょっと貼ってみます。
ちゃんとした説明は次回に行いたいと思います。

では、どうぞ。

昨日、XAudio2 を使ったアプリを Windows 8 で動かしたんです。Windows 8。
そしたらなんかアプリが起動出来ないって言われるんです。

で、よく見たらヌルポでアクセス違反、とかのようなんです。
もうね、アホかと。馬鹿かと。

お前らな、XAudio2 引き如きで普段使わない Windows 8に来てんじゃねーよ、ボケが。
XAudio2 だよ、XAudio2。

なんかDirectX9とかもいるし。DirectX9 + XAudio2でWindows 8か。おめでてーな。
よーしパパ、プログラムをWindows 8対応しちゃうぞ、とか言ってるの。もう見てらんない。
お前らな、Windows SDK やるからその席空けろと。

Windows 8 対応ってのはな、もっと殺伐としてるべきなんだよ。
OS環境ごとにプログラムを用意しないで、
単一プログラムがそのまま動くか動かないか、そんな雰囲気がいいんじゃねーか。
女子供は、すっこんでろ。

で、やっと座れたかと思ったら、隣の奴が、WASAPI で、とか言ってるんです。
そこでまたぶち切れですよ。

あのな、WASAPI なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、WASAPI、だ。

お前は本当にWASAPIを使いたいのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、WASAPI って言いたいだけちゃうんかと。

Windows 8通の俺から言わせてもらえば今、Windows 8での最新流行はやっぱり、
DirectSound、これだね。

素のDirectX9+DirectSound。これが通の頼み方。
DirectSoundってのは古くからあるDirectXのサウンド担当。そん代わり今やオーバーヘッドが多め。これ。

で、素のDirectX9(D3DXとかナシ)。これ最強。

しかしこれを頼むと次からマイクロソフトにマークされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、OpenGL + DirectSoundでも使ってなさいってこった。

※ 注意: OpenGL + DirectSound なら今や多くの環境でそのまま動くことでしょう。


USB 3.0 Kernel Debugging のための準備


Windows8 で カーネルデバッグを行うのに USB 3.0 が使えます。
ただしこのUSB 3.0で接続をするには、PCとPCを USBケーブルで接続しないといけません。
そして、PCは基本的にホスト側であることを想定されているため、タイプA形状のコネクタを持っています。
つまり、A-Aのケーブルが必要になります。

今までの USB 2.0 の場合は、特殊な機器を購入してそこに2台からのUSBケーブルを差し込む形になっていたようです。

さて、この接続するためのケーブルについてが特殊なので今回のネタとなっています。
WinDbgのヘルプには、こうあります。
「A USB 3.0 debug cable. This is an A-A crossover cable that has only the USB 3.0 lines and no Vbus」

これを読み解くと、USB3のラインだけ接続されたクロスオーバーのデバッグケーブルで、接続するとなります。
また、色々と調べてみてわかったのですが Universal Serial Bus Specification を紐解くとターゲットOSのデバッグ用の接続についても考慮された仕様が決められていました。
これらの情報から、デバッグケーブルを自作してみました。

デバッグケーブルを自作する

ケーブルの一部を切り開いて加工し、最後に一応シールド用としてアルミを当ててそっとケーブルを閉じてみました。

こうやって作成したケーブルで試したところ、先日のWindows8をターゲットとしてWindows Kernel Debugができた、というわけです。

簡単にケーブルを作成していますが、この状況にもっていくまでに何本かは失敗しています。
シールドの問題や、加工のしやすさ(&慣れ)、といった部分から失敗前提でチャレンジが必要かもしれません。
自作にチャレンジされる方は、パーツ数に余裕を持っておいたほうがよいとおもいます。

使用したもの

加工に向いたケーブルがなかなか見つかりませんでした。上記のものは amazon で購入した以下のケーブルを使っています



透明ウィンドウ(半透明ウィンドウ)の話 その3


透明なウィンドウということで、このシリーズも第3回。今回が最後となりそうです。
ようやく Windows7,Windows8両方ともで動かせるやり方が発見できました。
なお、Windows7のAeroGlassOFF状態でも動くので、注意して実装すればWindowsXPでもこの方法でいけるのではないかと思います。

その方法は、レイヤードウィンドウを使う方法です。
これを使っての半透明ウィンドウはWindows7,Windows8ともに正常に動作することが手元では確認できました。
ただし、レイヤードウィンドウの簡単なサンプルによくあるSetLayeredWindowAttributes関数を使ってしまうと、ウィンドウ全体での半透明設定や、カラーキーによる抜き色指定になってしまうため、背景とうまく溶け込ませた半透明の処理があまりうまく出来ないため、使用しないでおきます。

半透明もうまく処理するレイヤードウィンドウの作り方としては、DIBとUpdateLayeredWindowとを使って実現します。
DIBで半透明用のメモリ上のフレームバッファを用意して、その中にデータを書き込み、その結果をUpdateLayeredWindow関数で転送して、画面に表示します。この部分はGDIに関係する処理となります。
この手順の中で、「その中にデータを書き込み」の部分ですが、レイヤードウィンドウの各ピクセルの条件において、乗算済みアルファであることを要求されるので、その点に注意しながら実装を行います。

さて、ピクセル列にまでなったデータを表示する方法はこれでわかりました。あとはこれをどう用意するかですが、これにはDirectXであれOpenGLであれ、一度書いたデータをメインメモリ上に読み直す、取得し直すことが必要になってきます。いくつかの方法はあるでしょうが、環境に合わせてパフォーマンスと相談しながら実装を検討することになるかと思います。手頃で簡単なものは、DirectXであればバックバッファをロックできるようにフラグを立ててしまうか、OpenGLならglReadPixelsの関数で読み出してしまうとか。
ただ、ラスタライズした結果を読み戻す処理になるのでそれなりに負荷がかかるのは仕方のないことでしょう。
(ただ、今はPCI-Express接続になっているし、昔のAGP接続に比べて転送がネックになることが少なくなってきている、との話もあるので実際に計測してみないことには何とも。)

結果

手元で実装したものの結果を貼っておきます。まずはWindows7で動かした物です。
背景にコードが若干見えると思いますが、これはOpenGLで実装しているものです。

一方で、これをWindows8で実行したものです。こちらはスマホのカメラで撮ったのでちょっと画質がイマイチです。

でも、どちらの場合でも描画した結果をデスクトップ上に半透明も有効にして重ねて描画できていることが確認できるかとおもいます。

 

追記

この透明ウィンドウ関連の話をされている、こちらhttp://umezawa.dyndns.info/wordpress/?p=3455 のページでもレイヤードウィンドウを使ってWindows8で期待通りに動いてくれる、とあります。 Windows8ではやはりこの方法できまり、という感じですかね。


Windows8でG41ドライバがない?


G41のWindows8用ドライバがない

実験機にWindows8をインストールしたのですが、OpenGL動くかな?と思って試してみたところ、GDI Generic状態になっていました。これはまともに動いていない!ということで、デバイスはG41だったのでそれにあわせてWindows7用のドライバを入れようとしました。しかしながら、これが失敗。最低条件を満たしていないという意のメッセージが出てきました。

Windows7用を使おうとしたのは、IntelのページでWindows8用が見つからなかったためです。

このような状態ではやりたいことのチェックが出来なかったので、RADEON HD 5450を追加して、Catalyst 12.10をインストールしてOpenGLが使えるのか?というチェックをしてみたいと思います。

(しかしこのままだとG41でWindows8はちょっと使えないかも。DirectXのみのサポートという感じになるのだろうか・・・。)
サポート範囲なら早く対応ドライバが出て欲しいところです。
→ どうやら旧チップはWindows同梱版でのみの対応となり、メーカーでは出さないようです。これによりOpenGL対応は絶望的。CPU内蔵のグラフィックスであればIntelさんが個別に出していくとのことです。

ソース: http://communities.intel.com/docs/DOC-19646

RADEON 5450にて

ドライバインストールして、とりあえず使えるのかどうかを見るために、OpenGLの初期化および各情報を取得してみました。
以下その中身。

デスクトップモードでアプリ動かしてみての結果ですが、使えそうです。


Windows8のブートローダー


Windows8を既に複数のOSが入ったディスクにインストールしてみたら、ブートローダーがさらに変わってた!

以前のようなコンソールの味気ない物に比べると、かなり見栄えがよくなったように思います。
ちなみにこの写真は、自分の動作検証用PCに入れてみたときのものです。検証用なのでいくつものOSを入れてます。

Windows7以降のVHDブートは便利ですね。できればVistaから対応して欲しかった・・・。