「 DirectX 」一覧

DirectX11でMSAA


DirectX11でMSAA(Multi Sampling Antialias)を試してみました。
検索でよく見つかるのが、プライマリのバッファをMSAA使用する例はよくみかけるのですが、テクスチャレンダリングする場合においてMSAA有効でレンダリングするというサンプルを見つけることはできませんでした。
そんなに難しい話ではないのですが、サンプルプログラムが見つからなかったので今回作成してみました。

まずは結果です。テクスチャを描画先(レンダーターゲット)として三角形を描画しています。その結果をテクスチャとして取得して、四角形のポリゴンに貼り付けて表示しています。
result-msaa

結果を見てもよくわからないので、MSAA OFFの場合の結果を以下に表示します。

msaa-off

これでもよくわからないかもしれません。そこで両者を比較して拡大したものを示してみます。これならば違いがわかるでしょうか?MSAAが有効なものについては、ポリゴン境界がなめらかに見えるように色が補間された結果が見えています。

msaa-comp

手順について

レンダーターゲットとしてテクスチャを使う方法についてはここでは説明しません。
ここではMSAAテクスチャを作成する方法と、それをテクスチャとして使う方法の2つを説明したいと思います。

MSAAテクスチャの生成

描画先となるテクスチャを作成する際に、MSAA用のパラメーターを設定します。
D3D11_TEXTURE2D_DESC 構造体の SampleDesc内のパラメータが該当するのですが、ここにパラメータを指定します。

これらのパラメータの設定がよくわかりませんでしたが、下記に示すように CheckMultisampleQualityLevels から取得できる Quality値を指定しておけばよいようです。

この例だとおそらく 4x の MSAA が有効となるようです。

MSAAテクスチャとして使う

上記の pRenderTargetにたいして描画行われた後でテクスチャとして使用するためにはResolve処理を行わなくてはなりません。またこのときに、Resolve結果格納先として別のテクスチャが必要になります。
普通はこのResolveされたのテクスチャを他の描画で使用します(正確にはこのテクスチャのShaderResourceViewを、ですが)。

まずはそのResolveテクスチャの作成についてはこんな感じになります。

Resolve処理

簡単ですが、D3DDeviceContextについて以下のAPIを呼ぶだけです。

レンダーテクスチャを使う際の注意点といいますかお作法として、
レンダーテクスチャ(RenderTargetViewとして)セットする前に、そのテクスチャがShaderResourceViewとしてセットされていないか確認し、すでにセットされているならば解除しておくことが望ましいようです。
D3Dのデバッグレイヤー有効にするとわかるのですが、シェーダーリソースとして設定されているものをレンダーターゲットとして設定した際に、警告メッセージが表示されます。これはそのシェーダーリソースがシェーダーで使用されていなくても警告がでますので要注意です。

サンプルプログラム

今回のサンプルプログラム全体です。VisualStudio2012で作成しています。
SampleMSAA11サンプルプログラム(Zip)

まとめ

意外と使われないのか、テクスチャに対するMSAAをやってみました。


OpenGLとDirectX11で、あと何が足りてないか


ここ1ヶ月ほどは主に最近のOpenGLについて勉強しているわけですが、DirectX11と比べてまだ何が足りていないかまとめてみます。

やったこと

  • テクスチャ配列 (DX10だけど)
  • ジオメトリシェーダーでストリームアウト&ポイントスプライト (DX10だけど)
  • ハードウェアでのインスタンシング描画
  • テセレーションのシェーダーについて(TCS, TES)
  • シェーダーの実行関数の動的切替(DX11でいうところのDynamic Shader Linkage)
  • インダイレクト描画

まだやれていないこと

  • Texture Buffer (なんかよくわかっていない)
  • コンピュートシェーダー(OpenGL4.3で入った)
  • UAV関連(↑のコンピュートシェーダーの範疇かも)
  • NVIDIA の DirectX と OpenGL の inteop
  • NVIDIA の bindless 色々(GL4.4では標準化されてGL_ARB_bindless_texture).
  • Tiled Resource (DirectX11.2の機能らしい. GLではGL_ARB_sparse_textureだとか)

Draw Indirect 系を調べてみた (OpenGL vs DirectX)


OpenGL では Draw Indirect 系が充実しているとの情報があったので、DirectXとどのように違うのかを調べてみました。

DirectX 11 では、 DrawInstancedIndirect(), DrawIndexedInstancedIndirect() の2つの関数が DrawIndirect系として使用可能です。DirectX10では DrawAuto() という関数が存在して、DirectX11ではこれを汎用化して上記の関数群となったようです。

上記の関数はインデックスバッファ有・無しの違いで分かれているだけで、インスタンス描画を考慮するもののそれ以上の機能は持っていないようです。

一方で OpenGL の Draw Indirect 系は次の関数が用意されています。

  • glDrawArraysIndirect()
  • glDrawElementsIndirect()
  • glMultiDrawArraysIndirect()
  • glMultiDrawElementsIndirect()

ちなみに、glMultiDrawArraysIndirect() は、複数回の glDrawInstancedIndirect() を1回の呼び出しとするようなものです。また glDrawArraysIndirect() が DrawInstancedIndirect() に相当するようです。Indirectのバッファの中には、インスタンス数を指定する項目も含まれるようです。

複数回の描画を束ねられる glMultiDrawArraysIndirect ですが、結局のところ CPU 側に描画数を通知しておく必要があります。そこが何ともうまくないところですが、ARB_indirect_parameters という拡張でこの対策がおこなわれているようです。
 ARB_indirect_parameters では、インスタンス数を格納しておくためのバッファが追加サポートされるようになります。そのバッファが GL_PARAMETER_BUFFER というもので、GLsizei のデータを入れておく入れ物となっています。関数としては、glMultiDrawArraysIndirectCount, glMultiDrawElementsIndirectCount となっています。


VisualStudio 2013をインストールしてみた


MSDNのほうではVisualStudio 2013がRTMになってダウンロード可能となったのでインストールしてみました。
今回はその記録です。

まず素のWindows7にインストールしようとしたら、セットアップできませんでした。
InternetExplorer10 を要求するようです。
DirectX SDKを使って開発している場合にはこれが少々問題になって、IE10インストール後はPiX for Windowsが使用できなくなるようです(詳しくはこちら)。
IE10のインストール後は、VisualStudio2012の付属のツールを使って調査して下さい、ということのようです。
・・・でもこれだとDirectX9が非対応のようで残念なのですが。時代的にもうDirectX9は積極的なサポートのほうは終了という意思の表れのように感じます。

ランタイムで気になった物のバージョンを調べてみました。

  • .NET Framework 4.5.1
  • VCランタイム 12.00.21005.1
  • Windows Kitsフォルダ内には 8.0 と 8.1 の両方のファイルが存在
    • d3dcompilerもそれぞれにあった。d3dcompiler_46/47.dll, d3dcsx_46/47.dll となっていて、これらは再配布可能フォルダにあった。

Windows8 RTMでは .NET Framework 4.5 だったのでわずかに上がってます。Windows7 SP1のころでは、.NET Frameworkは 3.5.1だったので、4がスキップされてますね。

続きを読む


DDSのRGB 10bitフォーマットの罠


今更といえば今更な話なのですが、あまり情報がないようにみえたのでここにメモしておきます。DDSフォーマットの A2R10G10B10 や A2B10G10R10 の並びの画像データについて罠というか、マイクロソフトも承知のバグが潜んでいました。具体的には、チャンネルのマスクビットが逆転しています・・・。

続きを読む


VRAMの使用状況を取得するアプリ


先日からやっているVRAMの使用状況についてですが、別の手法で実装してみました。
取得コードはネイティブで、GUI部分をC#で作ってみました。
これはWindows7以降の環境で動作します。
意外とWindow操作で使用量が変動するので見ていてもおもしろいです。

DirectXやOpenGLなどの描画APIによって左右されずに、システム全体での使用量がわかります。

ViewVRAM_v100 のダウンロード
ViewVRAM v1.01 のダウンロード

これのDLL部分は後日ヘッダ+DLLで別途公開予定です。

追記

こちらのほうでDLLらを公開しました。


Windows8でDirectX9デバッグランタイム不可らしい


先日公開したライブラリはWindows8でも動くだろうと思っていたのですが、実は動かないことが判明しました。とりあえず修正コードを埋めてみたり色々といじってみたのですが、どうやら本格的に使えないようです。
これは明らかにDirectX9を捨てた感じです・・・。DirectX11に乗り換えてねってことなんでしょう。

さて、具体的にはDirect3DCreate関数の中で、デバッグランタイムへの切り替えのコードがまるっと存在しないようです。
言ってしまえばWindows8に付属するd3d9.dllはWindows8専用で、それ故にデバッグランタイムの存在など知らない、という感じです。一方Windows7までは一応存在そのものは知っていて、一応切り替えが出来るようなコードが埋めてあるようです。

思ったよりDirectX9デバッグランタイム制御ライブラリの出番は少ないようです。時期が遅すぎたのかもしれません。
もうちょっとだけ関数インターフェースいじったらもう放置になっちゃいそうです。


DirectX9デバッグランタイムの制御ライブラリ


DirectX9を使用している人は割とおなじみの SDKをインストールすると使用できる DirectX DebugRuntime というものがあります。
これは使用方法が不味いときにエラーを出力してくれたり、冗長な設定を行っているときに警告を発してくれたりととても役立つツールです。
ちょっと厄介なのは、SDKのインストールが必須で、再配布を行えないところとVista以降では管理者権限を必要とするようでUACによる暗転が発動してしまうことです。

今回、開発者が一時的にSDKをインストールしていないターゲットで問題解決のためにデバッグランタイムを使用するという想定で、
ターゲットでデバッグランタイムを使用可能にするライブラリを作成しました。

こちらからダウンロードしてください。d3d9_drt_v100

開発者の環境から必要なDLL(d3d9d.dll, XPならd3dx9_32,33.dllも)をアプリケーションexeと同じ場所にコピーするという手間と、ライブラリを組み込むという手間はかかりますが、デバッグランタイムを使用することが出来るようになります。

メリット/デメリット

  • 管理者権限が不要
  • SDKのインストール無しにデバッグランタイムが使える
  • プログラム主導でデバッグランタイムのON/OFFが(起動時に)設定できる
  • 安定動作しないかも。動作チェックが十分ではない
  • 再配布禁止の物を使えるようにするという性質上、公開がぁゃιぃ。公開停止要求受けたら閉じます

使用方法

プログラムは以下のようになります。Direct3DCreate9の前後で関数を呼び出します。

不具合とか

発見したらコメントの方で報告頂けると、修正を検討することが出来ます。

動作環境

ターゲット環境としては以下のものを想定しています。
調査した結果、Windows8では動きません!! 追記しました 2013/06/04

  • WindowsXP
  • WindowsVista
  • Windows7
  • Windows8 (まだ未検証. レポート求む)

ライブラリのリンクについては、下記のツールで確認しています。

  • VisualStudio2010 Professional SP1
  • VisualStudio2012 Professional

おそらく VisualStudio2010(SPなし), VisualStudio2012 Update XX らでも問題なく動作すると思います。
また、VisualStudio2008でもリンクは正常に出来る気がしています。

注意事項

WindowsVista以降の環境から d3d9d.dllをコピーして、WindowsXP環境へ持って行くことはできません。
これはVista以降の環境でインストールされるd3d9d.dllがVista以降専用のもののためです。
一度別のWindowsXP環境にDirectX SDKをインストールして、d3d9d.dllを取得するようにしてください。

「プロシージャエントリポイント _ftol2_sseがダイナミックリンクライブラリ msvcrt.dll から見つかりませんでした」というようなエラーがWindowsXPで表示された場合、このケースに該当していると考えられます。

最後に

機能として足りていないところもあるかと思いますので、ひとまずは要望などありましたらコメントの方にお願い致します。
開発において本ライブラリが役立ってくれることを願います。


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 なら今や多くの環境でそのまま動くことでしょう。