1. 今週の予定
今週は３カ月に一回のお休みの週ですが、先週出来なかったDirectX 12の勉強だけやります。
＜DirectX12の勉強＞
「DirectX 12の魔導書」と「Direct3D 12 ゲームグラフィック実践ガイド」の勉強をやります。
２．DirectX12の勉強
２.1 「DirectX 12の魔導書」の勉強
２.1.1 先週までの勉強の確認
一応、先週で「3.3 画面色のClear」のまとめは終わりました。
かなり時間をかけて流れを理解しましたが、結局はRender Target Viewを作成するにはどうしたらいいのか？が重要だと分かりました。
２.1.２ Chartで流れを確認
以下のようなChartを作成したら
以下に示した専門用語の
それぞれの役割の関係が一目で理解出来る事に気が付きました。
こういうChartのTemplateみたいなのは既にあるだろうと探したんですが見つかりません。
Excelで一々手作業で作成したら上図を作成するだけで30分位かかってしまいました。
Mind Mapだと線が一方にしか引けないです。
あ、Mind MapはWater Fall型のChartなんだ。
そしてこれは非Water Fall型のChartです。
こういうTypeのChartって今までにないかもしれません。
これって結構、世紀の発見かも。
更に調べてみたらこういうChartはBubble Mapと言うそうです。
うーん。
矢印が無いですね。
後、矢印の向きとか矢印に名称が追加出来るのかが無いですね。
CanvaというBubble Mapを作成出来るOnline Serviceがあるみたいです。
無料なので試しに使用してみました。
矢印はありましたが、Textを書き込む事が出来ませんね。
これが出来たら完璧でした。
以下のように矢印の間にNodeを挟む事も出来ますね。
ここまで書いてはっきりしました。
これってVisual Scriptingです。
UEであまりにも長くBPを使用していたのでCodeで読むよりもVisual Scripting化して読むほうが楽になってしまいました。
それでそういう感じで整理しようと無意識でなっていたみたいです。
うーん。
これはこれで面白い観点です。
が、直接の勉強には関係ないです。
Codeのまま理解すればいいだけですので。
うーん。時間を無駄にした。
2.1.3 「3.4 Error対応」を読む
簡単に全部、読みました。
こっちは前節の「3.3 画面色のClear」に比べたらかなり簡単です。
以下に簡単にまとめます。
＜「3.4.1 トラブル原因の究明」について＞
DirectX12にはErrorの原因を追究するための特別なInterfaceがあるそうです。
それがDebug Layerだそうです。
＜＜Debug Layerを有効化する＞＞
Debug Layerの使用方法を解説しています。
＜＜DXGIのエラーメッセージを受け取れるようにする＞＞
更にDebug LayerにDXGI周りのError Messageを受け取れるようにしています。
そもそもDXGIが何なのか知りません。
この辺は実際に勉強する時に確認します。
今週はさわりを理解するだけにしておきます。
＜「3.4.2 Fence」について＞
Fenceについて説明しています。
Fenceは他のthreadが終わるのを待つための物じゃなかったです。
GPU側の処理が終わったかどうかを知るためのものでした。
＜「3.4.3 Resource Barrier」について＞
Resource BarrierはResourceの状態遷移(State Transition)を知るためのものと書かれていました。
状態遷移(State Transition)って何？と思ったら
Resourceは
- 書き込まれる
- 読み込まれる
- Render target先として使用される
- Flip先として使用される
などの多用な方法で使用されます。
これを状態が遷移していると言ってるみたいです。
Resourceにはこの状態遷移(State Transition)があるため、GPUに今のResourceの使用の目的を教える（設定する？）必要があるそうです。
＜＜Resource Barrierの設定＞＞
Resource Barrierの設定方法について解説しています。
＜＜共同体(Union)＞＞
意外と共同体(Union)について知らない人がいると共同体(Union)について解説していました。
はい。
2023-08-14のBlogに書いていますが、私もすっかり忘れていました。
2.1.4 「3.4 Error対応」を読んだ感想
大体理解しました。
来週から勉強して更に実装していきます。
2.2「Direct3D 12 ゲームグラフィック実践ガイド」の勉強
2.2.1 先週の勉強の復習
先週はCreateEvent()関数の意味がよく分からないのでEvent Objectについて調べています。
それで
みたいなImageで理解していたんですが、
公式SiteのUsing Event Objects (Synchronization)[1]を読んでる内にこの解釈だと辻褄が合わなくなりました。
2.2.2 Event Objectを使ってみる
もうこうなったらEvent Objectを実際に作成して使用して確認するしかないです。
Using Event Objects (Synchronization)[1]を自分で実装してみます。
取りあえず最初はSample Codeを丸Copyしてそのまま貼り付けました。
実行します。
結果です。
うーん。
正常に動いてるみたいですね。
Threadは17880、8856、24060そして24064の４つがあるみたいです。
うーん。
大体理解してきました。
まずBufferと言うか４つのThread＋Main ThreadでShareしているMemoryがあります。
４つのThreadはこのMemoryを読むんですが、Main ThreadがこのMemoryを書き換えています。
書き換えが終わる前にこの４つのThreadがこのMemoryを読むと困るのでそれをEventを使用して止める訳です。
Codeを読んでみます。
Main()関数内の実装です。
ここはThreadとEventを作成しているだけなので今はSkipします。
次のCodeです。
うーん。
Reader TheadがSignalを待っている。のが初期状態なんでしょうか？
これはThreadの設定を見ないと分かりませんね。
以下にThreadの設定を示します。
CreateThread()関数です。
ThreadProc()関数がThreadの機能を指定しています。
ThreadProc()関数の実装です。
以下に示したCodeの所で
GhWriteEventのSignalを受け取っています。
GhWriteEventのSignalがWAIT_OBJECT_0の場合は
Main Theadの書き込みが終わったのでBufferの内容を読み込み始めています。
今度はWriteToBuffer()関数の実装を見ます。
こっちはghWriteEventをSetEvent()にしています。
SetEvent()関数は公式SiteのSetEvent function (synchapi.h)[2]に機能の解説があります。
以下のように書かれていました。
これ読むとSignalを発していますね。SetEvent()でSignalを発しています。
ここで私の理解を書きます。
このSignalが発信すると、ThreadProc()のSwitchのCase１が発動します。
つまりそれぞれのThreadがBufferを読み始めます。
ところが以下に示したWriteToBuffer()関数の解説を読むと
However以降に書かれている内容は、私の理解と反しているように思えます。
うーん。
これはあれだ。
Howeverの前提が違うんだ。
私は全てのThreadがGlobal EventがSingalを出すのを待っているから、Bufferに書き込んでも安全。と理解したんですが、この筆者は全てのThreadがGlobal EventがSingalを出すのを待っていたとしても、Bufferに書き込むのは安全と言いたかったのかもしれません。
それだと私のCodeの解釈が正しくてもこの部分の解説とぶつかりません。
うーん。
多分そうなんでしょう。
今週は他の事をするために敢えて勉強しないようにしているのでこの辺で終了します。
３．まとめと感想
なし。
４．参照（Reference）
[1] Stevewhims. (2021, September 16). Using Event Objects (Synchronization) - Win32 apps. Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/sync/using-event-objects
[2] Karl-Bridge-Microsoft. (2023, April 5). SetEvent function (synchapi.h) - Win32 apps. Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setevent
