GPGPU

1 名前：デフォルトの名無しさん mailto:sage [2005/10/08(土) 23:15:20 ] いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという GPGPUについて語りましょう 参考リンク 総本山? gpgpu.org www.gpgpu.org/ GPUをCPU的に活用するGPGPUの可能性 pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/ 488 名前：・∀・）っ-○◎● mailto:sage [2007/04/02(月) 06:50:53 ] GK「トップガンならやれる」 489 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 09:49:07 ] >>486 ＞HPの中古EWS それ、Netburst Xeon機だろ。 足下に2台あるけど、（ヘッポコカードとは言え）ビデオカードの音などまったく気にならない。 でも、「五月蠅くない」ってのとは違うだろう。 こんなの自宅で使いたくない。 >>487 今のところRMSの言の通りだね。 業者の非openなドライバに依存していると、いつかテメエの首が絞まる。 490 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 12:59:20 ] 能力の低いopenドライバと能力の高いclosedドライバの 両方があったら俺は後者を使う。 使えなくなったときに移行すれば良いだけだし。 491 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 20:01:51 ] forums.vr-zone.com/showthread.php?t=140444 >As the Fusion programme implies, it will come with an integrated graphics core which is a subset of the R600 VPU. >This graphics core will share system memory with the CPU, >but ATI claims it will be faster than the NVIDIA's new GeForce 8600 GTS, thanks to the inclusion of 16MB of really fast on-die memory. 492 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 23:18:57 ] ネタもとの日付が気になるが Fusionにはたしかに、でかめのキャッシュかレジスタが必要でしょうな。 EDRAMとして使えばXbox360は軽く超えてしまうのか・・・ 493 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 23:27:30 ] Fusionの話かと思ったが、Socket FのGPUの話け？ 494 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 04:16:21 ] BrookGPUって、実行環境で環境変数設定しないといけないけど あれって凄く不便なんだよなぁ・・ 例えば自分の配布ソフトに組み込みたい時とか・・・ 495 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 00:09:04 ] 環境ごとにバッチファイルでも作ればよくね？ 496 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 02:11:33 ] つかCUDA以外全部失敗とみなしてもいいほど糞だ。 オナニー言語とかマジ作るのやめてほしい見てると イライラしてぶっ潰したくなってくるよ 497 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 13:38:48 ] Cgがあの有様なのに、今度はCUDAに期待しろとなｗ 498 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 20:22:18 ] 8800を汎用計算で速度計測したサイトが見つからないんで、教えてほしい。 499 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 20:35:58 ] 8800にあんまり魅力を感じないんだけど研究する価値ある？ 500 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 22:25:28 ] >>499 CUDAが動くのが8800しかないから。 今更後戻りはしないだろうから、新世代毎にCUDAが使える ビデオカードが増えてくるはず。 AMD X19XXはBrockGPUでも使い物になることがわかった(folding) nVIDIAがどういう状態なのかわからないんで。 501 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 23:18:25 ] CUDA_SDK入れてみたけど、サンプルが動作確認的なのばかりで パフォーマンスが目に見えるようなのが無くてちょっと寂しい。 502 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 00:06:01 ] ゲーム用途でなんだが いわゆる、プロシージャル処理をGPUでやらせようっていう動きに AMDは積極的のようですね。 GDCの内容もそれっぽい R600のRubyのデモも雪原はプロシージャル生成らしい ttp://ati.amd.com/developer/gdc/2007/Andersson-Tatarchuk-FrostbiteRenderingArchitecture(GDC07_AMD_Session).pdf これの48ページ目の絵を良く覚えておいて Ruby demoを見てみよう ttp://youtube.com/watch?v=EJ6aMxPh6k0 nVIDIAもトンボのデモでやってるっぽいけど インパクトは・・ 503 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 00:19:25 ] >>502 絵の話はよそでやってくれよ。 504 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 02:29:42 ] とりあえずBrookGPUがなぜユーザーに環境変数を設定させる方式にしてるのかが疑問だ ライブラリの初期化のときにパラメータを与える方式にしない理由がわからん。 bgInit(BG_OPEGL); みたいにさぁ 505 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 03:01:54 ] >498 自分でやれば、論文かけちゃうぞ。 >499 NVIDIAでは前のﾓﾃﾞﾙと構造が違うから、前との比較なんぞをやってしまえばこれもまた研究になると思う。 っていうかCUDAがあるのにBrookGPUを使う意味がわからん。 特定の処理に関しては楽なのか? 506 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 03:09:09 ] CUDAを使うにはGF8シリーズが必要だろ BrookGPUなら、プログラマブルシェーダーを搭載していれば、主要なGPUで動く 507 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 07:26:06 ] GPGPUの壁の一つにそういった汎用性の問題があるよね。 ATIのいう業界標準のAPIに期待。 508 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 16:21:22 ] ATIの業界標準APIってなんだよｗ 標準にならないと、所詮CUDAと同じ 業界標準で言うと、nVIDIAのCgの方がマシ あれはシェーダー搭載している主要グラボにほぼ対応している。 純粋なGPGPU用の言語ではないけどな。 んで、Cg用のコードを吐き出すBrookGPUがまだマシだとあきらめて使われてる理由でもある 509 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 23:19:25 ] 汎用演算が今後広く普及したとしても、 nVIDIAとATiでなかよく一つの業界標準言語を作るのは無理だろうね。 MS（の強要）頼みかな。 510 名前：・∀・）っ-○◎● mailto:sage [2007/04/06(金) 23:27:50 ] SPEのISAは普及しそうにありませんか？（本音：糞食らえ 511 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 00:11:12 ] Cgは一応MSも噛んでるな しかもATiでも的でも使える。 CUDAもそんな感じにするんじゃないの？ 512 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:02:52 ] 自作板で見たんだが、こんなもんがあるんだね。誰か使ってる？ Microsoft Research Accelerator Project The Microsoft Research Accelerator system provides simplified programming of graphics-processor units (GPUs) via a high-level data-parallel library. This download includes a data-parallel library for .NET that targets GPUs, documentation, and sample code using the library. Parties interested in inquiring about commercial licensing of the Microsoft Research Accelerator software should contact msrlg@microsoft.com for more information. research.microsoft.com/research/downloads/Details/25e1bea3-142e-4694-bde5-f0d44f9d8709/Details.aspx 513 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:42:17 ] .NETかよ 514 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 10:21:45 ] Ge86発売日に意味もなく東京に行く出張入れることを成功したぜ。 上司になんでこんな時期に本社へ出張必要なのぉ？って怪しまれたが 気にしない。CUDAするために、２枚購入してくるぜ。 515 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 18:28:10 ] SLI　CUDAできるのかな？ 516 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 18:38:50 ] 出張期間延長で 通販にしとけばﾖｶﾀｰ と嘆きつつPC一式調達してホテルでいじる>>514に乾杯! 517 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 20:41:43 ] ttp://www.kohgakusha.co.jp/support/rtmshadr/index.html ここのソース試した人いる？ ＶＣでまともに動かないんだけど 518 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 03:18:39 ] もうすぐGF8600および8500が出る。 それからが本当にGPGPUが普及するかの正念場だな。 8800はヘビーユーザーだけの代物だったが、8600や8500は十分一般ユーザーの手に入る価格帯だし。 まぁ、その分ベンチは散々だが、所詮ローエンド 519 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 04:33:46 ] まぁ、このスレ何気に4割が俺の書き込みなんだよなぁ・・・。 その状況から言って、やっぱり寂しいものがあるよなぁ。。。 520 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 05:52:11 ] おまいさん>>131か？ 521 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 09:09:30 ] 毎日スレ更新してるのでバンバン書き込んでください＾−＾ 522 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 11:04:36 ] まだ手を出すのは早いからな デフェクトスタンダートが決まりつつあり 日本語ドキュが整備されつつあるぐらいでも 十分遅くない、経験的に 523 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 04:26:21 ] >>514-515 CUDAのforumに、GPUが非SLIで複数ささってれば全部使うよー、って書いてあった気がするんだけど、ソースを失念。 524 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 04:38:03 ] そんな(消費電力とスペースの)恐ろしいことはできないw 525 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 15:21:38 ] 最近のGPUは前世代の2倍のパフォーマンスだけど消費電力も2倍って感じだからなw ATIの新しいのはビデオカードだけで250Wとか酷すぎる。 526 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 15:46:29 ] 8800GTXなんて、+12V電源を30A用意しろと書いてあるよ。 単純計算するとそれだけで360Wだ。 #実際、ボード上に+12V用6pin電源コネクタが二つもある。 527 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 03:40:49 ] CPUのように消費電力が通常の半分で値段が通常の1.5〜2倍の 製品を出してくれれば、一般的な開発者もGPCPUの検討用に買ってみようか、 というやつが増えると思う。 次世代では両者とも検討してほしいところ。 ・・・と思ったが、250Wやら300Wやらじゃ、半分でもNetbust「全盛期」かそれ以上だ。 んなもん、ゲームもしないのに買ってもアホらしいな。 528 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 11:08:03 ] 計算終わった後に「チーン」って音しそうだな。 529 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 13:24:32 ] おい、CUDA SDK 0.81 あるぞ。 530 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 14:16:29 ] あるぞといわれても 531 名前：時々書いてるこのスレの住人 mailto:sage [2007/04/13(金) 14:32:29 ] 取り敢えず拾った。 >>529 THX! 532 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 18:29:20 ] >>529 ｱﾘｶﾞﾀﾏｷﾝ ( ´∀｀)ﾉ⌒ω)Д`)ﾌﾞﾆｭ 533 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 13:13:41 ] けっこうCUDA使い＝8800使いがいるんだね。 簡単な結果でいいから、報告してくれないかな。 534 名前：・∀・）っ-○◎● mailto:sage [2007/04/15(日) 13:21:27 ] おれCUTA使い 535 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 15:41:46 ] ( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ 536 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 16:37:35 ] >>533 なんか適当なベンチマークないかね。 nVideaのサンプルは動作確認っぽいのばかりで動かしても面白くないのだけれど。 #つーか、私も作らないとなんだけどね(苦笑 537 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 16:44:08 ] SDK 0.8だと、どうしても一塊のデータをわっと処理するバッチ系の サンプルしかなかったので、俺の場合まだまだ基本性能を評価する段階だった。 NVIDIA FORUMでは、「演算サーバみたいなもの組めねえぞｺﾞﾙｧ」なトピックがHotだった。 >>529は俺なんだが、今別の遊びをやってるのでCUDAしばらく棚上げだ。 他の誰かがほげってくれるのを待つ! 538 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 23:54:14 ] >>533同意 とりあえず>>424の姫野ベンチの結果が知りたいな 539 名前：536 mailto:sage [2007/04/16(月) 11:31:05 ] Linuxだから無理。 じゃないけどBrook入れてないからめんどい。 540 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 12:17:16 ] 実行だけならBrook入れなくても 出来るよ。 541 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 23:48:51 ] >>533 つーか今CUDAって8800以外で使えるの？ 542 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 18:04:18 ] ｹﾞﾌｫ廉価版出たけどあまりにも性能差が差別化されまくり。 それでも、エミュよりマシだと思えばいいのか。 543 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 20:24:05 ] 8600が出ましたよ。 544 名前：デフォルトの名無しさん [2007/04/18(水) 21:09:01 ] 質問です。 ifやswitchなど条件分岐を一切使わずに汎用プログラミングを行うと言うのがかなり理解出来ないのですが 一般的にGPUでのプログラミングでは、この辺はどのようにしているのでしょうか？ 例えば、GPGPUによる、動画のエンコーダーなどの分野は期待しているのですが あの手の処理は、条件分岐の塊だと思うので、GPUではそれらが使えないとなると有効な実装方法が思いつきません。 545 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 22:05:46 ] >>544 分岐の分だけmain()を作る 今はもうレガシな手法になりつつあるが。 当然個々のフラグメントプログラムは 画一したフローを踏むことになる。 546 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 22:16:00 ] >>545 一瞬びっくり！という感じだけど、やっぱりわからない。 if文は普通にc++で書いて特定の箇所で飛ばすのに比べて、 mainたくさんというのは、どういうメリットがあるの？ 547 名前：・∀・）っ-○◎● mailto:sage [2007/04/18(水) 22:43:44 ] mainじゃなくてもサブルーチンでもいいけど、分岐の頻度を最小限に減らさないといけない パイプラインが長いと、分岐の度に大きなペナルティ食らうわけよ んで for (i = 0; i < 1000; i++) { if (a == b) { 　　　//HogeHoge 　} else { 　　　//BokuhaKamiyamaMangetuChan 　} } よりも if (a == b) { 　for (i = 0; i < 1000; i++) { 　　　//HogeHoge 　} } else { 　for (i = 0; i < 1000; i++) { 　　　//BokuhaKamiyamaMangetuChan 　} } のほうが速いよね。 パフォーマンス重視なら、分岐を繰り返し処理の外に追い出せる場合は なるべくそうしたほうがいい。たとえ冗長になってもね。 普通のCPU向けプログラミングでも同じ （最近は分岐予測のほうが賢くなってるから一概にはいえないけど） 548 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 23:12:58 ] >>547 >>545の話はそういう話なのかい？ ＞mainじゃなくてもサブルーチンでもいいけど あんたのコードで//HogeHogeのところで別プロセス呼んでたりしたら、 普通は頭がおかしいコードだと思うよね。 549 名前：・∀・）っ-○◎● mailto:sage [2007/04/18(水) 23:19:36 ] プログラムって基本的にループの塊なんで、 むしろループがプロセスの単位だと思ってくれ 550 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 23:24:46 ] いやさ、おれもコード書きのはしくれなんで、forkくらいは使うけど、 >>545のはGPUを使うときの独自の流儀の話をしてんじゃないの？ってこと。 551 名前：・∀・）っ-○◎● mailto:sage [2007/04/18(水) 23:24:58 ] ちなみにGPUにプロセスの概念はない。GPU上でOSは動かないだろ。 552 名前：・∀・）っ-○◎● mailto:sage [2007/04/18(水) 23:32:44 ] たとえばJPEGの量子化なんかだと、除算値を定数化できれば大幅に高速化できるわけで。 でもコンパイル時には不定なわけで。 でも除算値毎にEXE作ってたらアホらしいから、普通のCPUだと、動的に命令コード生成したり する。一般人はこんな面倒なことやらないけど、トップガンの常套手段ね。 でもGPUだとそういうことできないから（CPU側でやれば可能かも） モジュールを複数作ってパラメータにあったのをロードすると。 そんだけの話でしょう。 553 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 23:59:05 ] >>552 いちおう理解できたようだ。感謝。 でも>>547は関係ない話だろう。 554 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 00:13:38 ] スレが伸びてると思ったら糞団子かよ 555 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 00:46:37 ] トップガン(藁 556 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 00:50:39 ] 分岐コストが高いなら、両方のルートを計算すればいいだけ。 そういう頭の使い方ができない香具師にはGPUを使いこなすのは難しい。 557 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 01:04:55 ] つまり下手鉄砲も数打ちゃ当たる？ 558 名前：・∀・）っ-○◎● mailto:sage [2007/04/19(木) 01:07:57 ] 弾の数が勿体ない。 スループット落ちるじゃないか。 559 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 01:09:19 ] 252 ：Socket774 [sage] ：2007/04/19(木) 00:15:30 ID:0/nRKtHL Larrabeeはかなり本気で開発している模様 > またRattner CTOが基調講演で触れたIAコアによるテラフロップCPUに関し、 > もう少し細かい話も出てきた。デモで紹介された80コアの試作チップはIAコアでは > なく、もっとシンプルなものだったが、IAコアを搭載するものを同社は開発中で、 > コードネームは「Larrabee」であることがGelsinger氏から明らかにされた。 > > 実際のコア数がどのくらいになるのかは不明だが、命令セットが拡張された > IAコアを搭載することになるようだ。これは製品化を前提にした開発のようで、 > 「来年にもデモが披露できる予定」とGelsinger氏。 そしてGPGPU終了のお知らせ > 最後にMicrosoft ResearchのDavid Williams氏の「Intelのこのアプローチは、 > GPGPUコンピューティングに関するディベートを終わらせることになる」という > コメントを引用し、Larrabeeに対する自信を見せた。 journal.mycom.co.jp/articles/2007/04/18/idf06/index.html 560 名前：・∀・）っ-○◎● mailto:sage [2007/04/19(木) 01:12:33 ] 早い話がIntel版Cellだな 561 名前：デフォルトの名無しさん [2007/04/19(木) 01:19:22 ] さすが団子ﾁｭｰさん＾＾ 562 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 10:22:20 ] ダンゴの一言は重みがあるな 563 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 20:33:33 ] GPUで出来ることの幅が広がるのはうれしいけど 本来のGPU的の使用には向かなくなってるのかな？ 例えば、これからコアもっとリッチに、粒度をもっと細かくしていくと 行き着く先はCell+だよね。で現状CellはGPUの代わりは出来ていない。 564 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 20:42:46 ] 上の奴は何を言ってるんだ? もっと勉強してこいと言いたい。 565 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 20:51:19 ] 今のGPUがやっているような、パラレリズムの特徴を利用してメモリアクセスの レイテンシーを隠ぺいできるような仕組みがないと、PUの利用効率が悪くなって 大きなファクターでの性能向上は難しいような気がする。 個人的には David Williams 氏のいうことはあまり信用できないな。 566 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 21:34:20 ] >>556-558 ItaniumやXbox360 GPUのプレディケーションって奴では？ XBOX360なら48 shader 分岐待ちしてるのと、演算にリソース使うの どっちが良いんだろう？ まぁ、R520系のように分岐ユニット（？）をつければ良いのかな・ 567 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 21:42:32 ] G70系のように比較的大きい粒度だと小さいレジスタですんでたのが R520系では小さい粒度のためG70系に比して大きいレジスタを搭載している。 NVIDIAはどうか知らないがAMDは更に小さくするんじゃないかな？粒度 568 名前：536 mailto:sage [2007/04/20(金) 18:36:53 ] 取り敢えずCUDAのサンプルと同等の処理をgccでコンパイルして較べてみた。 3.4GHzXeonで66ms掛かる処理が8800GTXで0.23ms。 #サンプルはsimpleTexture。 こういうサンプルだと確かに速いね。 #いかん、Xeonの方はsse使ってないやw 569 名前：536 mailto:sage [2007/04/20(金) 19:28:19 ] で、Xeonでsse使ったら(ベクタ化してないけど)44msにはなった。 でも、200倍近く。これなら取り敢えず、実験でお金が貰えそうだw 570 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 05:44:09 ] >>568 ども。 Xeon Quad DPのコア当たり性能が仮にNetburst Xeon 3.4GHzの倍だとしても、 x 2 x 4 x 2 でもまだ、10倍以上か。 double演算エミュレーションのサンプルみたいのはあるのかな？ 571 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 06:18:08 ] コード示さんとわからん。 572 名前：536 mailto:sage [2007/04/21(土) 08:21:24 ] GPU側はCUDAのサンプル、CPU側はそれを移植したもの。 どうしても見せろってことなら後で載せるよ。 #どうせだからこのPCでもコンパイルしてタイムを計ってみるか。 573 名前：536 mailto:sage [2007/04/23(月) 18:28:24 ] あー、載せるの忘れてた。CPU版のソースはこんな感じ。これをGPUのサンプルのtransform()と入れ替えて辻褄合わせた。 #でも、CUDAではgetData()相当で単純に整数化しないでニアレストネイバーか何かでサンプリングしているのでその分更に差が開く…… static float getData(float * data, float x, float y, int width, int height) { int ix = static_cast<int>((x + 1) * width + 0.5f); int iy = static_cast<int>((y + 1) * height + 0.5f); ix %= width; iy %= height; return data[iy * width + ix]; } void transform(float * rdata, float* g_odata, int width, int height, float theta) { for (int y = 0; y < height; ++y) { for (int x = 0; x < width; ++x) { float u = x / (float) width; float v = y / (float) height; u -= 0.5f; v -= 0.5f; float tu = u*cosf(theta) - v*sinf(theta) + 0.5f; float tv = v*cosf(theta) + u*sinf(theta) + 0.5f; rdata[y*width + x] = getData(g_odata, tu, tv, width, height); } } } このコード、Celeron1.2GHzでは109msだった。 574 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 19:42:27 ] >>573 おいおい、そのCPU用のコードはいくらなんでも冗談だろ？ 575 名前：536 mailto:sage [2007/04/23(月) 19:49:31 ] >>574 何か問題でも? getData()はCUDAのサンプルの出力からの類推ででっち上げたから問題があるとしたらその辺かな? transform()に関してはCUDAのサンプルのロジックそのままだからそれについては何もコメントできないけど。 576 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 20:21:04 ] >>575 CUDAで実行した場合に transformKernel() 内のすべてのロジックを 各画素について糞真面目に計算してるとでも思ってるのか？ そのCPUコードじゃGPUと対等じゃないよ。 577 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 20:37:55 ] 普通に考えて、width, height, thetaのみに依存する（入力ストリーム全体に対して不変の） ロジックは先に計算してGPUの定数レジスタに格納する、くらいの最適化はしてるだろうね。 DirectXのHLSLシェーダをアセンブリにコンパイルしたときのpreshaderみたいに。 578 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 21:22:20 ] >>573 CPU側をこんな感じにすればGPUの計算量に近くなるかな void transform(float * rdata, float* g_odata, int width, int height, float theta) { 　float inv_width = 1.0f / width; 　float inv_height = 1.0f / height; 　float sin_theta = sinf(theta); 　float cos_theta = cosf(theta); 　for (int y = 0; y < height; ++y) { 　　for (int x = 0; x < width; ++x) { 　　　float u = x * inv_width; 　　　float v = y * inv_height; 　　　u -= 0.5f; 　　　v -= 0.5f; 　　　float tu = u*cos_theta - v*sin_theta + 0.5f; 　　　float tv = v*cos_theta + u*sin_theta + 0.5f; 　　　rdata[y*width + x] = getData(g_odata, tu, tv, width, height); 　　} 　} } 逆にCUDAのほうでsin, cosの中身をthetaだけじゃなくビルトイン変数blockIdxとかに依存させたら 各入力に対して毎回三角関数を計算せざるを得なくなるから劇的に遅くなるんじゃないかな 579 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 21:58:44 ] gcc、それくらいの最適化は任せられなかったっけ？ 気持ちが悪いから、可読性が落ちないなら、速い方にするけど。 >>573にもう一度回してもらうのが一番手っ取り早いか。 580 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 22:24:02 ] >>579 sinf, cosfは外部のライブラリ関数で、Cコンパイラはその処理内容を知る立場にないから、 for文の中にある関数の呼び出し回数を勝手に減らすような最適化は普通しないと思うよ。 インライン関数だったらそういう最適かも可能だけど。 581 名前：536 mailto:sage [2007/04/23(月) 23:00:41 ] うい、流れは理解した。 明日にでも試してみる。 >>580 gccはsinf()はインライン展開しないようだね。 このテストじゃないけれど、iccはsincos同時に求める専用関数に置き換えるくらいのことはする。 iccの方は現在手元にないから水曜日になるけどテストしてみま。 582 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 23:33:10 ] >>581 投げてばっかりで悪いけど、よろしく。 8600でも買おうかと思ってたけど、unitが半分のはずが1/4しかないんでちょっと萎えてる状態。 583 名前：デフォルトの名無しさん [2007/04/24(火) 06:46:36 ] CUDAって、Vistaにまだ対応してないよね？ あと、XPはx64にも対応してないけど、これってネイティブな64bitモードで動かないってだけ？ 俺メインマシンがVistaとXP x64とのデュアルブートだから、CUDAの導入に踏み切れない・・・。 対応してるなら、早速グラボ買って来るんだが・・・ 584 名前：デフォルトの名無しさん [2007/04/24(火) 06:58:26 ] 積は最近遅くない気もするがね。 void transform(float * rdata, float* g_odata, int width, int height, float theta) { 　float inv_width = 1.0f / width; 　float inv_height = 1.0f / height; 　float sin_theta = sinf(theta); 　float cos_theta = cosf(theta); float v = -0.5f; 　for (int y = 0; y < height; ++y, v += inv_height) { float u = -0.5f; 　　for (int x = 0; x < width; ++x, u += inv_width) { 　　　float tu = u*cos_theta - v*sin_theta + 0.5f; 　　　float tv = v*cos_theta + u*sin_theta + 0.5f; 　　　*rdata = getData(g_odata, tu, tv, width, height); ++rdata; 　　} 　} } 585 名前：536 mailto:sage [2007/04/24(火) 17:56:14 ] ほい、お待たせ。 結論から言うと、10msそこそこまで速くなった。 #コンパイルオプションつけ捲くりw(-O3 -funroll-loops -msse2 -mfpmath=sse) コードの方は>584をベースにgetData()も手動最適化したくらい。ってことで、念の為にコード。 static float getData(float * data, float x, float y, int width, int height, float wf, float hf) { int ix = static_cast<int>(x * width + wf); int iy = static_cast<int>(y * height + hf); ix %= width; iy %= height; return data[iy * width + ix]; } 呼び出し側は、 float width_half_up = width + 0.5f; float height_half_up = height + 0.5f; しておいて *rdata = getData(g_odata, tu, tv, width, height, width_half_up, height_half_up); ちなみにアセンブリ出力を眺めたところ、rdata[y*width+x]と*rdata, ++rdataでは一番内側のループ内のロジックは同一。 この程度の最適化はするらしい。どうやら主な違いはu, vを計算しなおすのにx, yを使う関係でcvtsi2ssが入る辺りじゃないかと。 #掛け算より遅いかどうかは知らないけれど。 ってことで、レスくれている人達THX。こちらもどうせいろいろ資料作らなければならないんで、ネタ提供してもらって助かってます。 #そう言えば、DOSPARA辺りで8800積んだBTOのPC出始めてますねぇ。 586 名前：536 mailto:sage [2007/04/24(火) 18:31:54 ] >>583 この辺は参考にならない? forums.nvidia.com/index.php?showtopic=28716 587 名前：デフォルトの名無しさん mailto:sage [2007/04/24(火) 20:27:32 ] >>585 どうもです。10msそこそこってのはCeleron1.2GHzですか？ getData（テクスチャフェッチ）はGPUが非常に得意な部分だからそこでかなり差が付いてるかもね。 588 名前：デフォルトの名無しさん mailto:sage [2007/04/24(火) 23:38:13 ] Celeron 1.2GHzならメモリが遅過ぎでしょう。 あとCeleronの場合、整数だけで座標を演算した方が速いと思う。 それにしても比較するのは酷な環境。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef