AGP／PCI Express GPUテクスチャ転送時間まとめ

GPGPUでは、AGP接続のGPUは不向きである事が理論値から
予測されます。
そこで、AGP接続のGPUで、GPUへのテクスチャ転送・
GPUからの読み出し(リードバック)時間を計測してみました。

【AGP(X8)】
CPU→GPU(2.1GB/sec)
GPU→CPU(266MB/sec)

の理論値に対し、

GPU : RADEON 9600 x86/MMX/3DNow!/SSE2
OpenGL 2.0.6287 Win2000 Release

にて

CPU→GPU(362MByte/sec)
GPU→CPU(72MByte/sec)

という結果でした。
先のPCI Express X16の結果

CPU→GPU(433MByte/sec)
GPU→CPU(151MByte/sec)

と比較して、リードバック時間が２倍必要な結果と
なってしまいました。やはり、AGPは上りが苦しそうです。
ただし、テクスチャの読み書き時間については、
GPU上のメモリ接続形態(64bit/128bit)で大きな差異は
感じられませんでした。
どこか別の所で足を引っ張られているのでしょう。

簡単に両者の計測環境・条件についてまとめておきます。

【PCI Express X16 計測環境】
Dell Dimension 8400
GPU：RADEON X300(メモリ64bit接続)
CPU：Pentium4 HT 3.4GHz
OS：Windows XP SP2
◆ 結果(1000回平均)
CPU→GPU(433MByte/sec)
GPU→CPU(151MByte/sec)

【AGP X8 計測環境】
ASRock 939Dual-SATA2
GPU：RADEON 9600(メモリ128bit接続)
CPU：Athlon64 2.75GHz(AGP/PCIクロックは定格)
OS：Windows 2000 SP4
◆ 結果(1000回平均)
CPU→GPU(362MByte/sec)
GPU→CPU(72MByte/sec)

【テスト条件】
1. API／SDK
　OpenGL 2.0／GLUT 3.7／GLEW 1.4.0
2. テクスチャサイズ
　1024×1024
3. CPU→GPUへの転送
　glTexSubImage2D／GL_RGBA／GL_UNSIGNED_BYTE
4. GPU→CPUへの転送
　glReadPixels／GL_RGBA／GL_UNSIGNED_BYTE

※ glFramebufferTexture2DEXT でテクスチャを
　フレームバッファオブジェクトに結びつけて直接レタリング

台風9号接近

台風第9号が、北上中です。
この台風、今後強まる太平洋高気圧にはじき出されるように
「東」から「西」へ日本へ接近する珍しいコースになりそうです。

関東南岸→東海沖へと進む予報が出ています。
勢力が強いまま近づく可能性もあり、警戒が必要ですね。

【台風情報】
米国海軍 [URL]
日本気象庁 [URL]
韓国気象庁 [URL]

【気圧配置】
週間気圧配置図 [URL]
UNISIS GFSx [URL]
韓国長期モデル [URL]


... 来週、飲み会なんだけど(´Д｀;)

WikiScanner日本語版

Wikipediaを編集した組織や企業が分かるツール
「WikiScanner」の日本語版... これは(苦笑)

うちの会社も検索してみると... うぎゃー。出る出る(´Д｀;)
ログ残ってるだろうし、マズイんじゃないかな。
何やってるの＞中の人

それにしても、凄いことになっているのですが、
大丈夫なのでしょうか？

農林水産省から「ガンダム」
文部科学省から「太陽戦隊サンバルカン」
経済産業省から「トップをねらえ2」
首相官邸から「愛の戦士レインボーマン」

GPUBENCH

GPUBENCH
というサイトを見つけました。私のテストしているカードと
ほぼ同じ構成のカードでの結果が出ています。

GPUBench Report RADEON X300 x86/SSE2

Bandwidth: Download
Bandwidth: Readback

の結果を見ると、私の転送レートの結果と
ほぼ同じ値になっています。
(ソースを見ましたが、私の実装とはテクスチャ書式が異なる、
このベンチマークソフトは描画を画面ではなくメモリ上に
行う実装系になっていないといった差異はありましたが
基本的に同じでした)

比較的最近のGPUでは

CPU←→GPU(700MByte/sec〜1000MByte/sec)

ぐらいの速度が出ているものもあるようですね。

GPUBench Report GeForce 7900 GTX/PCI/SSE2
GPUBench Report GeForce 8800 GTX/PCI/SSE2


GPU上への描画処理＝今回は演算処理は、インストラクションを
発行してしまえば、GPU上のシェーダ実行はCPUとは
並列して行えますので、ここを活かすのが鍵です。

ただし、どういう訳かリードバック(GPU→CPUへデータ転送)に
用いている glReadPixels という命令を、OpenGLの描画処理が
終了する前（GPUがシェーダをまだ実行中）に呼び出すと
ロック状態で待っているのにCPUリソースを消費してしまう
現象が起こっています。
この現象が、GPU依存・環境依存なのかはまだ解っていません。
glFinish で、待てば良いのでしょうか？
(DirectXでは、このあたりどうなんでしょう...)

GPGPUにおけるCPUとGPUの並列処理について
でも同じ内容が書かれていますね。


GPUベンダの実装系とGPUベンダの開発するドライバ、
そこに載っているOpenGLやDirectXというGPUをドライブする
API層からの制御になりますので、非常にどこで何をしているか
解りにくく、手探りの状況です。
状況証拠的に、ここの実装は今の処理系ではこうなっている
のかな？... 程度なのが今の私の現状です。

GPGPUはSIMDのお化け

GPGPUで、やっぱりというか予想通りなかなか良い結果が
得られてません。
GPUへの転送・GPUからの読み出し(リードバック)時間が
馬鹿になりません。

【PCI Express X16】
CPU→GPU(4GB/sec)
GPU→CPU(4GB/sec)

の理論値とはかけ離れた数値が出ています。

テクスチャサイズも2の乗数という
転送が効率的にできそうなサイズにしてもです。

GPU : RADEON X300/X550 Series x86/SSE2
OpenGL 2.0.6645 WinXP Release

で

CPU→GPU(433MByte/sec)
GPU→CPU(151MByte/sec)

ぐらいが実測です。(後日、ちゃんとした結果を書きます)
この速度はGPUによってだいぶ違うようです。
最近のGPUは倍ぐらいは出てもおかしくないでしょう。

というか、私が使用しているGPUは
ヘボすぎ＆メモリバス64bitなのでお話になりません。


GPGPUではピクセル単位での並列演算ということで、
粒度の非常に小さな並列処理が可能なわけですが、
うまく使いこなすには、発想の大転換が必要です。

SIMDのお化けはお化けなのですが、CPUのSIMD命令とは
違う実装の難しさを感じています。