「2013/09/25-03」の編集履歴(バックアップ)一覧はこちら
「2013/09/25-03」(2013/09/26 (木) 00:43:34) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
**続・DirectX11.1
先程、田中美香社長はニセモノだとの密告メールがやってきました。
時を同じくして別の情報が。
&color(red){DirectX11.1って実質的にAMDでしか使えないはずなんですが。}とのこと。
そして開発担当がAMDだと。
私は評論家でも何でも無いので、大人の話は良くわかりませんが...
でも、そうなると全く話は別かもしれませんね。
-----
恐らくこのあたりを積極的に使ってくるでしょう。
[[Microsoft DirectX11.1 SDK Create larger constant buffers than a shader can access>>http://msdn.microsoft.com/en-us/library/windows/desktop/hh404562(v=vs.85).aspx#create_larger_constant_buffers_than_a_shader_can_access]]
[[Microsoft DirectX11.1 SDK Map SRVs of dynamic buffers with NO_OVERWRITE>>http://msdn.microsoft.com/en-us/library/windows/desktop/hh404562(v=vs.85).aspx#map_srvs_of_dynamic_buffers_with_no_overwrite]]
どちらも&b(){Buffers}で共通ではありますが、
昔からBufferなんてものはどこにでもあったわけで、
特別に新しいものではありません。
特に上のconstant buffersはlargerと書かれている通りサイズが増えただけです。
これは三角関数などGPUのSPにとって非常に負荷が高い演算処理を事前にCPUで行い、
結果を表形式でGPU内に格納しておくケースなどで多用されます。
例えばSin(30)=0.5を計算するには相当のクロック数を要します。
(考えやすく30「度」にしていますが、内部的にはラジアンを使用します)
そのため、Sin(0)からSin(359)まで全ての値を事前にCPUで計算し、
360個の配列(一覧表)にしてGPU側へ転送してしまえばGPUは一切計算を行わず配列を参照するだけで答えが得られます。
(Sin(1.5)やSin(30.456)などをどうするかは別のテーマなので割愛)
人間的には「かけ算九九」をイメージすると良いかもしれません。
8×6と問われて、本当にかけ算を頭で実行する人はまず居ません。
また8を6回足し算する人もいません。
外国人はどうだかわかりませんが。
少なくとも日本人なら計算せずに瞬時に48と回答が得られるはずです。
計算する前に丸暗記してしまう方式。まさにこの原理ですね。
----
凄そうに感じるかもしれませんが、
あくまでもlargerになっただけの話で以前から使えた技術です。
但し、以前は相対的にSmallerだったわけですが、
Smallには収まらない程の一覧表を作ると性能差が生じます。
でも、わざわざそんなことするかな...
まさか3GBのVRAMってこのために使うわけでは...
Sin(0.0000000001) = xxxxxxxxx
Sin(0.0000000002) = xxxxxxxxx
Sin(0.0000000003) = xxxxxxxxx
Sin(0.0000000004) = xxxxxxxxx
.
.
.
.
Sin(179.9999999999) = xxxxxxxx
(笑)
----
ほんの少しだけAMD有利かもしれませんが
ベンチマークにあらわれるほどの差にはならないと思います。
(&Counter())
表示オプション
横に並べて表示:
変化行の前後のみ表示: