L.Entisの日記: GPGPU の特性について 1
日記 by
L.Entis
GPU での光線追跡コーディングを通じて、これまでの結果から
(1). 結果以前に基本的なこととして
NxM のデータを処理し、NxM または、M のデータを返す処理において、NxM の処理が共有メモリに収まるなら、GPGPU は極めて有効な手段である。
また、その演算が規則的であることも条件である。
(2). 光線追跡は、光線数を R、ポリゴン数を P とするなら、PxR の処理で、R の結果を返すが、光線1つの処理に必要なデータは共有メモリには収まらない。(収まる事はほとんど期待できない)
(3). ポリゴンに対して単純な全数判定を行うアルゴリズム(初期のコード)において、GPU の1つのスレッドブロック(グリッド)の中で、1つのピクセルに割り当てるスレッド N と、ブロックにするピクセル数 M は、NxM に対して処理時間はほぼ不変であった。(N, M のバランスを変えても、NxM の値が同じであれば、ほぼ同じ処理時間になった(但し1次レイのみ………しかテストしていなかったと思う))
(4). 絞込みを行って全数判定を避けるようにするアルゴリズム(これによって演算量だけでなくメモリアクセス量も軽減することを期待)において、(3) の N が32未満になると、32以上の場合より極端に(数倍という単位で)性能が悪化する。
N thread 単位で大きくフローが分岐する可能性を意味するが、それが32未満であることによるのか、メモリアクセスに関係した何かなのかは不明だが、とりあえず現在の私のコードではそのようになる。
5. 現状、N は32スレッドで、M は近傍のピクセルに限定するのが最も効率が良い様子。
(1). 結果以前に基本的なこととして
NxM のデータを処理し、NxM または、M のデータを返す処理において、NxM の処理が共有メモリに収まるなら、GPGPU は極めて有効な手段である。
また、その演算が規則的であることも条件である。
(2). 光線追跡は、光線数を R、ポリゴン数を P とするなら、PxR の処理で、R の結果を返すが、光線1つの処理に必要なデータは共有メモリには収まらない。(収まる事はほとんど期待できない)
(3). ポリゴンに対して単純な全数判定を行うアルゴリズム(初期のコード)において、GPU の1つのスレッドブロック(グリッド)の中で、1つのピクセルに割り当てるスレッド N と、ブロックにするピクセル数 M は、NxM に対して処理時間はほぼ不変であった。(N, M のバランスを変えても、NxM の値が同じであれば、ほぼ同じ処理時間になった(但し1次レイのみ………しかテストしていなかったと思う))
(4). 絞込みを行って全数判定を避けるようにするアルゴリズム(これによって演算量だけでなくメモリアクセス量も軽減することを期待)において、(3) の N が32未満になると、32以上の場合より極端に(数倍という単位で)性能が悪化する。
N thread 単位で大きくフローが分岐する可能性を意味するが、それが32未満であることによるのか、メモリアクセスに関係した何かなのかは不明だが、とりあえず現在の私のコードではそのようになる。
5. 現状、N は32スレッドで、M は近傍のピクセルに限定するのが最も効率が良い様子。
ぐぐってみた (スコア:0)
ここ [exth.net]のこれ [exth.net]?
32とか関係しそうなのはここ [kobe-u.ac.jp]かなぁ・・・?
#ぐぐってみただけなのでAC