Changes between Version 5 and Version 6 of CALプログラミング(4)

Timestamp:

Mar 22, 2009 4:00:53 AM (16 years ago)

Author:

nakasato

Comment:

--

CALプログラミング(4)

@@ -2 +2 @@
  * ここまでの説明を理解することで、最もシンプルなN体計算プログラムを作成できるはずである。
 
- * 具体的にはGRAPEなどと同じように、ホストから粒子の位置と質量をGPUに送り、GPU上で全粒子間で互いに及ぼし合う力を足しあわせて、結果として加速度を得るようなプログラムである。粒子間に働く力がニュートン重力の場合は、[http://galaxy.u-aizu.ac.jp/trac/note/attachment/wiki/CALによるGPUプログラミング/CAL200808.pdf  CAL200808.pdf] で説明したIL kernelプログラムとなる。ループの部分のみを再掲すると、以下のようなものである。
+ * 具体的にはGRAPEなどと同じように、ホストから粒子の位置と質量をGPUに送り、GPU上で全粒子間で互いに及ぼし合う力を足しあわせて、結果として加速度を得るようなプログラムである。粒子間に働く力がニュートン重力の場合は、[http://galaxy.u-aizu.ac.jp/trac/note/attachment/wiki/CALによるGPUプログラミング/CAL200808.pdf  CAL200808.pdf] (60ページ以降)で説明しているIL kernelプログラムとなる。ループの部分のみを再掲すると、以下のようなものである。
 {{{
 whileloop 
@@ -23 +23 @@
 endloop 
 }}}
+ 
+ * データ構造の定義の詳細についてはファイルを参照のこと。
 
- * このプログラムは、基本構造は(3)と同じであるが、ポインタ変数(ここでは"r2.xy")の処理が異なる。
-
- * なぜかというと、粒子の座標が格納されているid = 0のリソースは2次元のメモリとして宣言されているからである。具体的には、ホスト側のプログラムで以下のようにメモリの宣言をおこなった：
+ * このILプログラムは、基本構造は(3)と同じであるが、ポインタ変数(ここでは"r2.xy")の処理が異なる。なぜかというと、粒子の座標が格納されているid = 0のリソースは2次元のメモリとして宣言されているからである。具体的には、ホスト側のプログラムで以下のようにメモリの宣言をおこなった：
 {{{
 
 }}}
 
- * なぜこうするかというと
+ * こうする大きな理由は、XXにより１次元のメモリとして確保した場合、その次元には8192までという制限があるためである。よって、CAL_FORMAT_FLOAT_4の場合であっても、最大で32k個のデータしか扱うことができない。
 
 = ２次元配列 =