「 DirectX 」一覧

メインメモリ領域をテクスチャにできる?!


DirectX 9.0 Ex の話になりますが、マイクロソフトの MSDN の説明に以下のようにありました。

Applications that need more flexibility over the use, allocation and deletion of
 the system memory can now create textures from a system memory pointer. 
For example, an application could create a Direct3D texture 
from a GDI system-memory bitmap pointer.

MSDN のページとしてこちら :
https://msdn.microsoft.com/en-us/library/windows/desktop/bb219800(v=vs.85).aspx

この内容を見ると、メモリ領域を指定してテクスチャを生成できるように思います。また参照先の内容を見るとテクスチャを破棄するまでその領域は存在しなくてはならないようなので、ある意味でダイナミックなテクスチャが楽に出来そうな気配もあります。
続きを読む


DirectX12 で テクスチャ貼ってみた(1)


以前から随分と DirectX12(仮) 入門なネタが空いてしまいました。色々と追従やらドライバやらあったので、再開できるようにするまで時間がかかってしまいました。

エラーが出るようになってた

まず Build 10130 で気付いたのですが、以前のサンプル類を実行したときに、 “EXECUTION ERROR #552: COMMAND_ALLOCATOR_SYNC” のエラーが出るようになっていました。
コマンドキューの処理の問題があったようで、サンプル類を修正しました。

今回の結果

simple_texture_dx12
上記のように単色のテクスチャを描画できるようになりました。ただし画像からのテクスチャの場合ちょっと問題がありました。詳細は末尾にて。 続きを読む


DirectX12でWARPデバイス


VMWareの中に仮想マシンとしてインストールした Windows 10 でも実は DirectX12 を初期化して動くのを確認できていました。その時にアダプタが複数見つかって、別アダプタを使ったのがきっかけだったのですが、その時のデバイス(アダプタ)は Microsoft Basic Render Driver となってました。実はコレが、WARPデバイスでした。先日 Microsoft から Direct3D 12 UWP Sample という公式なサンプルが公開されたのでこれと比べてみたところ判明しました。

サンプルでは IDXGIFactory4::EnumWarpAdapter で比較的簡単に WARP デバイスを取得できます。この取得したアダプタの情報を見てみたところ、 “Microsoft Basic Render Driver”, VendorID=5140, DeviceID=140 となっていました。
これはVMWare環境下でうまく使えたというアダプタ2つめとも一致していました。

https://msdn.microsoft.com/en-us/library/windows/desktop/bb205075%28v=vs.85%29.aspx

このページの New info about enumerating adapters for Windows 8 の節にもあるように描画専用のアダプタです。

このアダプタを使うと以前の RADEON 環境でもうまく動くのを確認できています。WARPアダプタを使って動いている状態になるので当たり前といえば当たり前ですが・・・。

以下の環境で WARP デバイスを使ってとりあえず DirectX12 の開発を進められることは確認できました。

  • VirtualBox
  • VMware
  • ドライバ不正なRADEON環境

dx12sample_in_vm

VMware Player の中で一応テクスチャ実験のためのサンプルが手元で動いています。

WARPデバイスの取得

サンプルでは IDXGIFactory4 の EnumWarpAdapter を使って取得していますが、以前の IDXGIFactory3 あたりでもちゃんと取得は可能です。単に EnumAdapters で DXGI_ERROR_NOT_FOUND が返ってくるまでインデックスを増やして検索すればOKです。
このときに、指定された VendorId, DeviceId がくるか見ておけばOKです。

これで仮想環境でも実験を始められるので、気軽に DirectX12 を触り始めてみることが出来ますね!


BC7について段階的にデコードしてみた


BC7のCPUデコーダーを作っている過程でおもしろいものが確認できたので記事にしてみました。当たり前の話ではあるのですが、視覚化されたケースって無いようなので。
BC7 はいわゆる第2世代のテクスチャ圧縮技術で、各ブロックごとに最適なモードを選択してデータを圧縮しています。このブロックがどんな風に割り当てられているかを、ブロックごとの色分けで塗ってみたら以下のような結果を得られました。

image_partition

この段階でも各ブロックの特徴によってモード選択されているのが確認できます。そのためおおよその画像の検討が付く程度にはなっています。これらのブロック種別を順番に展開してみます。 続きを読む


DirectX12テスト機をNVIDIAに変えた


NVIDIA が DirectX12 へ正式対応したドライバをリリースしました。ハードウェア的に既に対応を果たしていて先行していたと思われる AMD よりも早く、です。今のところ開発機として RADEON を使用していたのですが、テクスチャ周りでうまく機能せず Intel HD Graphics 5xxx だったら動くのかなと期待していたので、まずは NVIDIA の正式ドライバで試してみようと思い、交換するに至りました。

さて NVIDIA のものに交換&正式ドライバをインストールしたあとは予想以上にうまく動作するようになりました。テクスチャの件も余所で見かけたコードでうまく動きました。さらには VisualStudio 2015 RC のグラフィック診断の機能もうまく動作するようになりました。 AMD の RADEON ではうまく動かず、 RC だからなのかドライバなのか保留していました。もちろん先日まで紹介している立方体を回転させるサンプルもそのまま NVIDIA の環境でも正常に動作しました。

結論として、テクスチャの件に悩まされていたのはドライバの不十分さによるものだったと言えそうです。このドライバの対応がダメだったせいで D3D12CreateDevice に成功しないわ、テクスチャの転送&描画がうまくいかないわで、さんざんでした。 NVIDIA の DirectX12 対応正式ドライバということで今回の挙動は正しいと言えそうです。

近いうちにテクスチャの部分もちゃんと説明しようと思っていますが、現状の RADEON でもテクスチャ関連正常に動作させようとすると UPLOADヒープに転送した後で、 DEFAULT 領域に転送するのが必要です。 NVIDIA を始め、他の環境では CommitedResource の領域に書き込んだもので正常描画が可能でした。


DirectX12 でポリゴン描画 (VS2015RC版)


VisualStudio 2015 RC になって従来のコードが動かなくなってしまったので、その対応第2弾です。今回は立方体を回転させるサンプルまで復活できたのでそのお話になります。

注意事項

現時点において DirectX12 の部分は実装途中となっています。正式版では大きく変更される可能性があります。よってここの情報は 2015/05 現在の限定された環境でのみ動作するという点をご理解ください。

必要なもの

  • VisualStudio 2015 RC
  • Windows10 Insider Preview 10074
  • AMD RADEON の新しいドライバ(15.200.1023.0)

ほか、以前に説明した内容はこちらを参照してください。

DirectX12プログラミング

cubedx12
通常の Win32 アプリケーションを作成します。ウィンドウの作成関連は割愛して、DirectX12 部分だけ抜粋していきます。また、 DirectX12 についても前回までの内容については省略させていただきます。今回説明する内容で出来るのは上図で示したようなサンプルになります。 続きを読む


DirectX12 で画面クリアまでの最小サンプル実装(VS2015RC版)


以前は VS2015 CTP6 と Windows10 10041 で画面クリアのサンプルを作りましたが、既に今現在はそのコードはビルド不可能な状態になってしまいましたので、再度作り直すことにしました。本当に色々とあってようやく画面クリアまで出来るようになりました。

注意事項

現時点において DirectX12 の部分は実装途中となっています。正式版では大きく変更される可能性があります。よってここの情報は 2015/05 現在の限定された環境でのみ動作するという点をご理解ください。

必要なもの

  • VisualStudio 2015 RC
  • Windows10 Insider Preview 10074
  • AMD RADEON の新しいドライバ(15.200.1023.0)

ここで新しいドライバというのが大事です。つい最近Windows Update で提供されました。それまではドライバの不具合で DirectX12 の初期化が正常に行えませんでした。

DirectX12 プログラミング

通常の Win32 アプリケーションを作成します。ウィンドウの作成関連は割愛して、DirectX12 部分だけ抜粋していきます。

初期化処理

まずはコードを先に示します。画面クリアするのに必要になるものだけを生成していますが、コード量は多めです。

このコードについて簡単に説明していきます。
最初にデバッグ情報を多く出してくれるようにするための設定をしています。DXGIにも DXGI_CREATE_FACTORY_DEBUG フラグを渡していますし、 D3D12 もデバッグ情報を出してくれるようにするために D3D12GetDebugInterface でインターフェースを取得して有効化しています。従来は CreateDevice でフラグを渡す、でしたが今回から変わったようです。
 また、本来ならばアダプタを列挙して処理が必要になるのかもしれませんが、ここでは最初のアダプタに対して D3D12CreateDevice をするようにしています。コメントにあるように DirectX12 のデバイスは最低でも D3D_FEATURE_LEVEL_11_0 の機能レベルを要求するようです。

 その後、コマンドアロケーター、コマンドキューを作成したあと、スワップチェインを作成します。ここでは2つのバックバッファチェインを持つようにして初期化をしています。また カレントのバックバッファインデックスを取得するために、DXGI の IDXGISwapChain3 で作成することにしました。

 さらにその後、コマンドリストを作成し、レンダーターゲットのディスクリプタを格納するためのオブジェクトを作成していきます。ディスクリプタヒープには先ほどのスワップチェインのバックバッファ数分だけのレンダーターゲットビューを準備しておきます。このとき、ディスクリプタヒープのポインタのインクリメントサイズがデバイスから取得できます。

描画処理

初期化のコードが終わったので、画面クリアの描画ループについて説明します。基本的にはクリアのコマンドをコマンドキューに設定して(積んで)、実行をキックする、その後コマンド完了を待って画面に描画、という感じです。
ただし、クリアの際には描画先のリソースをリソースバリア処理(関数)を用いて状態を変更していく必要があります(SetResourceBarrier関数)。これから扱うリソースがどの状態になるのか、正しく変更されるか、といったためにこんな仕組みになっているのだろうと予想しています。バッファの扱いが柔軟になったため故だと思います。
 描画に関しては以下のようなコードとなっています。

まとめ

ようやく現在の状況での正常に動くコードを作成できました。とはいってもまだ画面クリアだけですが、最初の1歩を再び歩み出せたと思います。従来のコードからは変更箇所は多いですが、考え方そのものは変わっていないなと思います。

ソースコードについて

今回のソースコードの全貌は GitHub に上げてあります。気になる方はそちらを参照していただければと思います(https://github.com/techlabxe/testD3D12 の HelloDX12 )。


DirectX12 の初期化が成功しない Build 10074とVS2015RC


どうにもこうにも DirectX 12 のインターフェースが変わってからというもの、自分の環境で DirectX12 の初期化 D3D12CreateDevice が成功しない状況でした。試行錯誤していたのですが、原因がやっとわかりました。

その理由というのが Catalyst Driver の問題というもので、Build 10.0.10074 broke Direct3D 12 on most recent Catalyst WDDM 2.0 driver とあります。
このドライバのバージョンは 15.200.1018.1 (2015/04/01版) となっていました。このバージョンが新しくなるまではダメそうです。

他の環境であれば成功するらしいので、RADEON を使用している人はしばらく待ちな感じです。ハードウェアがちゃんと対応しているのは RADEON だと思っているので、こいつがちゃんと使えないとは残念です。AMD しっかりしてほしいところです。さらに他の環境としては VirtualBox にインストールしてみた Windows10 では初期化に成功するところまで到達できました(しかし、まだクリア処理まで到達できず)。


Raspberry Pi 2 向け Windows10 IoT Core Insider Preview で DirectX11 アプリ


前回の内容と手順自体はほとんど変わらないで、 DirectX11 のテンプレートを使用するだけで Raspberry Pi 2 でも動作することを確認できました。動作は今のところ重いですが・・・。

DirectXアプリのプロジェクト

プロジェクトの作成は Visual C++ / Windows / Windows Universal / DirectX App (Windows Universal) を選びます。

vs2015rc-directxapppi2-project

プロジェクトが作成されたら、 x86 の構成ではなく ARM の構成を選びます。あとはデバッグの設定を前回と同様に Raspbery Pi 2 のIPアドレスを設定します。以下の図は前回の流用です

windows10-iot-debug-conf

これで実行すると Raspberry Pi 2 の画面で以下のようにキューブが回っているのを確認できます。1280×1024 という解像度でおよそ 17FPS でした。強引に 640×480 にしてみましたがそれでも 40FPS 程度. HARDWAREデバイスが DirectX 11.1 で作成されており問題はなさそうなのですが、正式版が出る頃にはパフォーマンスアップしているといいなぁと思います。

DSC_0388


DirectX9 と DirectX9Ex の違いをテクスチャの観点から


DirectX 9.0Ex では D3DPOOL_MANAGED が使えなくなりましたが、基本的にはデバイスロストが発生しなくなりました。そのため D3DPOOL_DEFAULT を使ってリソースを作成しても問題がなくなりました。もっとも D3DPOOL_DEFAULT でなければリソース生成に失敗してしまいますが。こんな便利になった DirectX 9.0Ex があまり注目を浴びていなかったようなのと、ちょっとした差異があるようだったので記事にしてみました。以降、 DirectX9 を DX9, DirectX9.0Ex を DX9EX と表現します。

基本的にはより厳密な制御を求められるようになった感じです。
従来の DX9 で D3DPOOL_MANAGED でリソースを作成し、何も気にせず Lock メソッドを使った場合、システムがよろしく制御を行ってくれました。パフォーマンスロスなどは発生しますが、動作はしていました。これもデバッグランタイムを使用していれば警告メッセージ等は出ていたかと思います。しかし、 DX9EX ではこれらについてエラーとなるようです。

ここではテクスチャについて見ていきます。

これは DirectX 9.0 では問題が発生しなかったコードです。しかし D3D9EX では、CreateTexture で失敗してしまいます。先ほど述べたように D3DPOOL_MANAGED が使えないためです。ここを D3DPOOL_DEFAULT にしてみると、テクスチャの生成には成功しますが、後続の LockRect で失敗します。このときのエラーメッセージは以下のように表示されました。

というわけでLockで書き込む際には D3DUSAGE_DYNAMIC が必要なようです。このことは、 D3DPOOL_MANAGED で作成し、LockRect にてテクスチャからの読み込みのコードを書いていた場合に失敗するということを意味しています。頻繁な読み書きをする場合には D3DUSAGE_DYNAMIC が必須という感じです。
 恐ろしいことに、D3D9 において Lockのフラグで D3DLOCK_READONLY をつけて読み込みロックをしていた場合でも D3DPOOL_MANAGED では書き込みすることが出来てしまいました。しかもそれが反映されるケースもありました。 D3D9EX では書き込み結果は反映されません。正しい挙動をしているといえます。

D3D9EX でテクスチャをCPUで読み書きする場合には、 D3DUSAGE_DYNAMIC フラグが必要といえると思います。このフラグさえ設定しておけば D3D9 のコードと他の部分は違いはなく動作できそうです。
逆に初期化だけで使えるスタティカルなテクスチャはどう作成するかを考えてみたところ、CPU上でのスステージングテクスチャを作成して、それを転送するという方法が考えられます。手順の擬似コードとしては以下のようになります。

まとめ

頂点およびインデックスバッファも同様ですが、一番違いの影響を受けそうなテクスチャについて調査してみました。

DirectX 9.0 Ex のよい点はデバイスロストからの解放だけでなく、フルスクリーンで自分のプログラムを動かした際に、他のプログラムに対してもデバイスロストを発生させないというのもあります。他のプログラムが DirectX 9.0だったとしても自分のプログラムが 9.0Ex でフルスクリーン化しても向こうもデバイスロストにならないのです。