- 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/
- 369 名前:デフォルトの名無しさん [2007/02/27(火) 12:16:50 ]
- >>365 を Cg で書くとどんな感じ?
- 370 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:25:46 ]
- 今はCgよりCUDAの方が。。。
まぁ古いGPU(俺を含めて)の人には仕方ないが。
- 371 名前:デフォルトの名無しさん [2007/02/27(火) 12:48:48 ]
- >>369
kernel void func(float v1<>, float v2<>, float v3, out float o<>){ o=v1+v2+v3; } int main(void){ int i; float img[height][width];float a; float v1<width>;float v2<width>;float v3<width>; float o<1>; for(i=0;i<height; i++){ streamRead(v1, img[i]);streamRead(v2, img[i-1]);streamRead(v1, img[i+1]); func(v1,v2,v3,o); streamWrite(o, &a); } } BrookGPUで書くとこうかな。そのままCg用のコードを生成してくれるはず。 でも、このコード、aは上書きだし、0から始まる変数でi-1とかやっちゃってるし、色々アレだね。 そういえば、BrookGPUでループ中にstreamReadを大量にやると、VRAM食いつぶしてマシンがフリーズするな。。。 何かVRAMの内容を開放する関数は無いのかな?
- 372 名前:デフォルトの名無しさん [2007/02/27(火) 14:02:44 ]
- じゃあCUDAで書くとどうなるの?
- 373 名前:デフォルトの名無しさん mailto:sage [2007/02/27(火) 14:32:25 ]
- >>371
手抜きするなーw 外側のループもはずせるだろ。 いや、面倒だから俺はやらないけどなw VRAMは自動開放だからな…、俺もよくフリーズさせてしまう。正確にはフリーズじゃなくて単に低速化するだけなんだろうけど プロセスも殺せなくなるのが嫌だな
- 374 名前:デフォルトの名無しさん [2007/02/28(水) 01:06:47 ]
- Brookでやるからだよ。
頑張って自分でCgとか使ってゴリゴリ動的にメモリを管理するんだ。 って言うか、あれは隠蔽されすぎてて何やってるのかわからんし、パフォーマンスが出るような組み方ができないので 遅すぎる。BrookGPU使ってCPU処理より速い処理ってかけるの?どう頑張ってもReadBackである意味速度差がつけられちゃうよ。
- 375 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 01:17:19 ]
- 何度見てもスレタイをゲプゲップと読んでしまう
- 376 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 02:16:30 ]
- ぐぷぐぷってよんでる
- 377 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 04:54:13 ]
- intからfloatへの変換で+/-32768.0の範囲へ正常に変換できる様にGPUで計算したいのですが
CPUだと、 hoge*(1.0 / ( 1L << (8 * sizeof(int) - 16))); 一般的なWintel環境だと、hoge*(1.0 / (32768.0)); だと思うんですが、GPUだとこのままだとint型とfloat型の扱いの違いか、正常に変換出来ません。 GPUでやる場合、どういう風にすればいいのでしょうか?
- 378 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 05:24:56 ]
- あ、スマソ
単純ミス。。。 GPU側にfloatで値を渡してたから、2重に変換されてた・・・
- 379 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 14:07:17 ]
- GPUにint型をfloatで送っちゃった時点で、桁落ち発生するでしょ。
- 380 名前:デフォルトの名無しさん [2007/02/28(水) 15:29:00 ]
- 桁落ちするの?
- 381 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 21:34:28 ]
- assert((float)0x7FFFFFFF != (float)0x7FFFFFFE);
- 382 名前:デフォルトの名無しさん [2007/02/28(水) 22:11:09 ]
- Brookもint型が扱えればな…。
floatとintだと、個人的にはfloatの方が高度なものだと思うんだけど なんで、float扱えて、int型が扱えないのかなぁ・・・
- 383 名前:デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:47:15 ]
- >>377
キャストしてGPU側に送って、GPU側で更にint型にキャストじゃ駄目なん? って、GPGPUの言語名に使ってるかわからんけど、大抵intは無理なんかな
- 384 名前:デフォルトの名無しさん [2007/03/01(木) 16:20:02 ]
- ところで、おまいらAMDのフュージョンは期待してますか?
- 385 名前:デフォルトの名無しさん [2007/03/01(木) 16:29:50 ]
- AMDはコンパイラが期待出来ないから駄目
ここは嫌でもIntelやnVIDIAと共同で第3機関を作り、命令セットの仕様を管理させた方が良い。 じゃなきゃ3D NOWの二の舞さ。 どうせIntelもGPUコアとの統合を考えてるんだろ? そうなった場合、どうせどこかで命令セットが共通化するんだから(しなかったら終わってる) 最初からそういう機関を作っとけよ。
- 386 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 17:39:38 ]
- そうなるよりチップセットにプログラマブル演算機能があった方がいいな。
メインメモリへ近いしCPUである程度処理して 並列化できる処理ではCPUがそのメモリアドレスを投げて 結果をCPUに戻すかGPUなどのバスに転送させる。 定数時間で出来る処理ならメモリ転送の代わりにできる。
- 387 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 17:45:11 ]
- チップセットにCPUくっつけたらいいんじゃね?
- 388 名前:デフォルトの名無しさん mailto:sage [2007/03/01(木) 17:51:27 ]
- >>387
すでにAMDのCPUはメモリに直接つながってるからその状態では。
- 389 名前:デフォルトの名無しさん mailto:sage [2007/03/02(金) 00:22:20 ]
- >>385
> じゃなきゃ3D NOWの二の舞さ。 AMD64はよくがんばったと思わないか?
- 390 名前:デフォルトの名無しさん mailto:sage [2007/03/02(金) 00:29:55 ]
- あれは先にIA64が大コケして自爆しただけ。
- 391 名前:デフォルトの名無しさん mailto:sage [2007/03/02(金) 00:48:26 ]
- IA-64はよくガンガッテルお
Itanium2プロセッサベースのサーバ上で動作するアプリケーションの数が1万種類を超えた www.itmedia.co.jp/enterprise/articles/0610/24/news002.html Itaniumベースのサーバが急成長を続けており71.5%成長で11億ドル市場 journal.mycom.co.jp/news/2007/02/27/104.html Itanium搭載サーバ、売上ベースのシェアが国内RISCサーバの6割相当に拡大 www.rbbtoday.com/news/20070301/39100.html Montecito搭載、HP Integrity SuperdomeがTPC-Cで世界記録 www.tpc.org/tpcc/results/tpcc_perf_results.asp
- 392 名前:デフォルトの名無しさん mailto:sage [2007/03/02(金) 01:12:33 ]
- >>389
あれは殆どマイクロソフト主導じゃん MSの戦うプログラマの人がAMD64自体の開発に関わってたし 後は、あれはあくまでx86命令の拡張で、今までのCPUの延長線上のものだが 今回のフュージョンは、アーキ的には全然比べ物にならないくらいの大改造だから…
- 393 名前:デフォルトの名無しさん [2007/03/03(土) 03:45:34 ]
- CPUコアに統合されれば、GPGPUの最大の問題点であるReadBackの遅さが解決するな。
そもそも、CPUの命令に自然に溶け込む形みたいなので、GPGPUとか意識せずとも、勝手にコンパイラがやってくれそうな気もする。
- 394 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 00:53:22 ]
- 粒度はどんなのになるんだ?
現行GPUでいうところ quad とか batch とかにあたるもの。
- 395 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 01:06:43 ]
- 自分でループ展開して並列化して、各GPUをプログラマに管理させたりしてw
まぁ、コンパイラが勝手にやってくれるんじゃないかな。 それ以外の場所は、一般的なクラスタリングシステムみたいにやってくれるって事はないと思われ そういうことは研究されてるけど、まだまだ一般的なコンパイラ1発でやってくれる仕組みは完成しているとは言いがたい。 最適な粒度をコンパイル時に調べてくれるとかやっても、別環境で実行する場合変わるしなぁ。
- 396 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 12:47:40 ]
- いや、俺が知りたいのは、それぞれのユニットがプログラムカウンタを持つのか、コプロセッサ命令でシェーダアレイコントローラに命令するのか、ということなんだ。
全部のユニットにプログラムカウンタがあったら、そりゃサブプロセッサが沢山載ったマルチコアでしかないじゃん。 コプロセッサ命令になるにしても、拡張命令で1度に1つのユニットに1命令送るだけじゃ意味ないから、適当なグルーピングが必要だと思うんだけど。 x86ISAの拡張ってんだから、後者ではあるんだろう。 で、その粒度はどんなのになるんだろうな、と。 >395 の話題も面白そうだけど、他のプロセスなりスレッドとのユニットの取り合いとかも考えるとやってらんないね。
- 397 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:14:04 ]
- 偉そうな口調で頓珍漢な事言ってる人は、出て行って欲しい。
んがぁ、無理なんだよね。 ひろぽんは、殺伐とした方が情報の濃度が上がるとか言うけど、 白痴や馬鹿が沢山いるのに、そりゃああり得ない話。 頓珍漢なこと言ってると理解出来るレベルの人にとっては、 その情報って情報価値を持たない情報だったりするし。
- 398 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:27:13 ]
- 日本語でおk
- 399 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:28:36 ]
- ウォッカはストロワヤが一番。やっぱりウォッカはロシアだね。
スレ違いスマソ。 自分の、これはダメかもわからんねは、 バイクで50キロぐらいで2車線目を走っていた。 するといいきなり目の前に1車線目に止まっていた車が右に、 フルブレーキするまもなく追突(前輪あたり) 10m程飛ばされて頭、ほんとにてっぺんからアスファルトに直撃。 その瞬間首が変な方向に、ぐにっとなった時。 結果は頭を支点にそのまま背中をまたアスファルトに直撃。 シボンヌ・・・、と思ったら生きてる。 その瞬間、車に腹が立って立ち上がり走っていってボンネットの上に飛び乗った。 運転手ポカーン、 んで警察に行って、病院行って、CT撮って診察の時。 他に痛い所は?と先生。 タンクで金タマ打って少し痛い。と言うと 顔色を変えてそれはいかんな、チョット見せて (看護婦ちょっとはにかんだ様な顔でカーテンを引く) 先生、漏れの金玉をうねうねコロコロして。 ん〜、大丈夫でしょう。しばらくすると痛みも引きます。 と言いながらカルテにカキコしてるのを見ると 睾丸hit これはだめかもわからんね・・・
- 400 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:58:53 ]
- 朝鮮語でおk
- 401 名前:デフォルトの名無しさん mailto:sage396 [2007/03/04(日) 22:07:30 ]
- >>397
流れ的に俺のことなんだろうが、フロントエンドにしか興味ないのか?
- 402 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 22:14:46 ]
- ネットワークのスレとかにも現れる
「おまえらバカばっかりだな」系の人だろ もちろん具体的な議論はしません
- 403 名前:デフォルトの名無しさん mailto:sage [2007/03/05(月) 15:18:23 ]
- >>401
何処の人か分からないけど、ごめん。 イント、フロートでごちゃごちゃ言ってた人のこと。
- 404 名前:デフォルトの名無しさん mailto:sage [2007/03/05(月) 18:45:01 ]
- それも多すぎてわからん。
- 405 名前:デフォルトの名無しさん mailto:sage [2007/03/05(月) 23:09:11 ]
- 【キーワード抽出】
対象スレ: GPGPU キーワード: イント 403 名前:デフォルトの名無しさん[sage] 投稿日:2007/03/05(月) 15:18:23 >>401 何処の人か分からないけど、ごめん。 イント、フロートでごちゃごちゃ言ってた人のこと。 抽出レス数:1
- 406 名前:デフォルトの名無しさん mailto:sage [2007/03/05(月) 23:32:35 ]
- イント人もびっくり
- 407 名前:未来人 [2007/03/07(水) 16:29:31 ]
- GPUってCPUに取り込まれて無くなってたよ。
CPUは、FPUとSPUとGPUで構成されてたよ。
- 408 名前:デフォルトの名無しさん [2007/03/07(水) 20:51:05 ]
- >>396
「何時の時代の人だ(と言ってもたかだか数年前だが・・)」的な ことを今更「俺が知りたいのは」とか書くから荒れる。勉強しろ。
- 409 名前:デフォルトの名無しさん mailto:sage [2007/03/08(木) 01:13:12 ]
- >>408
url か検索ワードくらい教えてくれ。 英語でなんて表現したらたどり着くのか見当も付かん。
- 410 名前:デフォルトの名無しさん mailto:sage [2007/03/08(木) 03:00:48 ]
- 【Penryn】次世代モバイルCPU雑談スレ 3【Nehalem】
http://pc9.2ch.net/test/read.cgi/notepc/1160039483/537 537 名前:[Fn]+[名無しさん][sage] 投稿日:2007/03/07(水) 17:10:43 ID:o4rB4JJN GPUだからコプロセッサではない。 同様にデュアルコアだからデュアルCPUではない。 たしかに正しい。 でもこの視野の狭さがアホな言動につながるのです。 プログラムから見るとどう見える? 概念レベルではどう見える? そんな視点は一切ない。
- 411 名前:デフォルトの名無しさん [2007/03/08(木) 05:54:39 ]
- GPGPUの研究発表を聞いた
CPUのみに比べて若干早くなっている程度 たぶんプログラミングレベルが低いのもあるんだろう コストパフォーマンスについて聞いたら 「将来的には」を連発してた CPUよりコストパフォーマンスの伸びが良い予定らしい
- 412 名前:デフォルトの名無しさん mailto:sage [2007/03/08(木) 06:29:53 ]
- だってさ、1度でもGPGPUでコーディングした人ならわかるでしょ。
GPUを活かせる箇所が少ない事に…。 GPUといえども、1つあたりのストリームプロセッサの能力はCPUに比べて鼻くそだし、ReadBackのコストも馬鹿みたいにかかるんだから 並列化できなけりゃ意味がない・・・。そんな都合の良いループ部分が現状のコードや計算式見てそんなにあるか?
- 413 名前:411 mailto:sage [2007/03/08(木) 06:57:00 ]
- 早起きなのか徹夜かどうかはさておき、さっそくどうも。
うちのソースは機械系で有限要素的なので割とあるんだな。 PS2の時に1GFlops程度出たけどP4のSSEにトータルで負けた。 CellとGPGPUは期待してるけど過剰期待は禁物だと思ってる。 いちおうGeForce8800買ってみるよ。 Cellはソフト作る気にもならないのでライブラリ充実待ち。
- 414 名前:デフォルトの名無しさん mailto:sage [2007/03/08(木) 07:33:26 ]
- 私のところも並列できる応用は色々ある。
実際、ClearSpeedやXTrillionのようなアクセサレータボードで速度が出ている。 それらに較べれば、コストはGPGPUなら桁違いに掛からないわけで。 #CELLも評価対象になってるけどね。
- 415 名前:デフォルトの名無しさん mailto:sage [2007/03/08(木) 09:02:04 ]
- ムダ毛対策にもGPUによる並列処理が効果的らしい。
- 416 名前:デフォルトの名無しさん mailto:sage [2007/03/08(木) 11:01:34 ]
- >>415
全身大やけどしました
- 417 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 18:20:19 ]
- >>412
動画のエンコードだと1つのキーフレームを1つのストリームプロセッサに 担当させることによって、簡単に並列化できる。
- 418 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 17:50:05 ]
- 標準的なグラボは
VRAM128M ストリームプロセッサは64基 1コアあたり2Mしか使えん。(それ以前に128M丸々使えるわけが無い) 丸々割り当てるのは辛いんじゃないか?
- 419 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 02:50:52 ]
- メモリ容量は768MBを想定してたから確かに128Mの場合は辛いなぁ。
GPU側のメモリを使いきるごとにCPU側のメモリに渡すというやり方で なんとかなりそうな気はするけど。
- 420 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 03:07:17 ]
- 完全にCUDA世代のグラボ前提の話になってるな
まだ遠い話だ・・・
- 421 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 07:20:12 ]
- ttp://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats
GPGPU遅いとかいうのはnVIDIAのG7x前提だからだったんだね・・・ ATIのR580速いや・・・ Cellの倍の実パフォーマンス・・・ 1台あたりは PS3 30GFLOPS GPU 60GFLOPS
- 422 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 10:07:36 ]
- そのCellもフルパワー出てるかわからないけどね
- 423 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 10:43:06 ]
- >>421
俺、G7xに限らず、G80でも試したが、結果は似たようなもんだったぞ。 ぶっちゃけGPGPUは、もはや言葉だけが先行した流行りモノに過ぎない気が・・・ 実際、BrookGPUとか使えばC使える人なら簡単にGPGPU出来るようになったのに 誰も使ってないし、使ってる人は割りと失望してる人が多い・・・
- 424 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 12:59:13 ]
- G80持ってる人ここのヤツ試してくれん
ttp://gpgpu.jp/ ttp://gpgpu.up.seesaa.net/image/himeno0507.zip ttp://gpgpu.up.seesaa.net/image/brookbench_001.zip 姫野ベンチ その2 ttp://gpgpu.jp/article/17502609.html brookbench ver.0.01 ttp://gpgpu.jp/article/17266520.html G80とG7xでそんなに違わないって>>423の発言が気になる。 G70とRV530で十倍近い差有るし・・ じつは、G80もG70同様遅いのかな?
- 425 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 13:31:21 ]
- 上手く全てのコアを綺麗に動かせれば、当然差が出るけど
実際の場面で、汎用処理でそういうことをするのは難しい。 姫野ベンチのようなプログラムだと差が出るだろうけどな
- 426 名前:デフォルトの名無しさん mailto:sage [2007/03/24(土) 22:24:06 ]
- いい加減ナントカシェーダという呼び方はやめなさい
- 427 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 02:00:17 ]
- 既に定着してしまっているモノを変えたければ、
より多くの人に共感してもらえて説得力のある代替案を出さなきゃ。
- 428 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 02:08:48 ]
- David Kirk 「この命名はおかしいと自分も思う。Shader(プロセッサ)はプロセッサと呼ぶべきだと思う」
pc.watch.impress.co.jp/docs/2006/1121/kaigai320.htm
- 429 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 02:46:49 ]
- nvidiaはストリームプロセッサと呼んでるじゃん
- 430 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 05:51:54 ]
- シェーダーって元々影処理専門だったんだっけ?
- 431 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 06:59:56 ]
- それはシェイドシェイダーユニットの役割ですね
- 432 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 14:44:57 ]
- shade (r)だから影erみたいなもんだろ。
- 433 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 17:09:13 ]
- 元が3DCG用語だからな
それをgenericな用途に使おうとしてるんだから 呼び方に違和感が出てくるのはしかたあるまい
- 434 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 19:00:37 ]
- 3DCGの範疇であるvertex shaderの時点でもうおかしいわけなんだが
- 435 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 19:44:42 ]
- ピクセル影er
頂点影er プログラム可能な影er
- 436 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 22:56:05 ]
- CG用語のシェーダーっていうのは凄く広い意味を持ってるからややこしい。
基本的に与えられたデータを元にピクセル出力するためのプログラムは全てシェーダー。 頂点処理をするのもそうだし、毛を生やしたりするのもシェーダーと言ったりする。
- 437 名前:デフォルトの名無しさん mailto:sage [2007/03/25(日) 23:08:12 ]
- 「シェーダ」は元々はRenderManとかmental rayとかの用語でしょ
- 438 名前:デフォルトの名無しさん mailto:sage [2007/03/26(月) 04:57:07 ]
- vertex shaderはピクセルの出力と全く関係ないような
- 439 名前:デフォルトの名無しさん [2007/03/26(月) 09:44:43 ]
- CUDAを使ってトリップ検索させると速いですか?
- 440 名前:デフォルトの名無しさん mailto:sage [2007/03/26(月) 09:46:56 ]
- そういうのには向いてません。
高速にcryptを実行するってのは前に試したけど いい感じにかきなおせなかったわ。
- 441 名前:440 mailto:sage [2007/03/26(月) 09:49:34 ]
- ちなみに、cryptの能天気な話は
ttp://www.gpgpu.org/forums/viewtopic.php?p=4642&sid=fa945081fc53f719b6da6ade288b0ac8 ここみてちょ。 ここに載ってるパワポは見た上で試したが…。 こいつら、分かってて書いてるんだろうけどさ・・・。
- 442 名前:デフォルトの名無しさん mailto:sage [2007/03/26(月) 10:09:49 ]
- >>439
8800GTSで試したんだけど遅くはないけど激速じゃない。(4M程度) コストパフォーマンスではC2Dよりちょっと分が悪い。 春に廉価版が出揃って、CUDAのバージョンが上がったらモノになるかな? 整数演算のイマイチ度については各方面から突き上げが激しいので 次アーキでは劇的に改善される可能性はなきにしもあらず。 >>440 俺はLUTで試したけど、MP内にてLoadネックで 並列度が頭打ちになってる感じ。>>440が試した結果をもすこし詳しくきぼん
- 443 名前:デフォルトの名無しさん mailto:sage [2007/03/26(月) 10:59:36 ]
- ■後藤弘茂のWeekly海外ニュース■
CPUとGPUの大きな違い ●汎用コンピューティングで近づくCPUとGPU pc.watch.impress.co.jp/docs/2007/0326/kaigai346.htm
- 444 名前:デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:18:04 ]
- >>442
C2DでもTrip-Monaで500k程度だから4Mでも十分じゃん
- 445 名前:・∀・)っ-{}@{}@{}@ mailto:sage [2007/03/26(月) 19:38:01 ]
- やきとり屋さんだよ
- 446 名前:デフォルトの名無しさん mailto:sage [2007/03/26(月) 20:56:14 ]
- utripperはathlon64 2GHzで動かすよりCeleron 1.3GHzの方が速かったんだけどそんなもん?
- 447 名前:・∀・)っ-○◎● mailto:sage [2007/03/26(月) 21:06:48 ]
- アレはキャッシュのレイテンシ依存だし
PS3で10Mうめぇwwwwとか言ってるの俺だけ?
- 448 名前:デフォルトの名無しさん mailto:sage [2007/03/26(月) 21:14:43 ]
- >>447
Cellで?
- 449 名前:・∀・)っ-○◎● mailto:sage [2007/03/26(月) 21:48:56 ]
- RSX使わせてくれないから、まあそうなるかな
- 450 名前:デフォルトの名無しさん [2007/03/26(月) 23:23:18 ]
- >>442
GTSで4Mか。 GTXのSLIだとどれぐらいになるかな…。 また、理論ピークと、トリップ検索の性質を鑑みるに、まだ性能向上の余地はかなりありそう。 今後に期待だ。 まあカネも電力もバカみたいにかかるけど。 Woodcrest@3.0GHz×2でTripcode Explorer v1.2.3を動かすと10.3Mtrips/sらしいので、 Woodcrestを二機積んだマシンでGTXのSLIを使えばチョー最強?
- 451 名前:・∀・)っ-○◎● mailto:sage [2007/03/26(月) 23:25:58 ]
- (・∀・)
- 452 名前:デフォルトの名無しさん mailto:sage [2007/03/27(火) 10:26:11 ]
- >>450
電源が死にそうだね。つーか、熱対策か。
- 453 名前:・∀・)っ-○◎● mailto:sage [2007/03/28(水) 01:25:33 ]
- CPUはClovertownの50W版でよくね?
- 454 名前:デフォルトの名無しさん mailto:sage [2007/03/28(水) 03:45:24 ]
- 取り敢えず、8800GTXの動く環境はできた。
#CPUは1coreXeonだけど。 さて、来月から実験だ。
- 455 名前:デフォルトの名無しさん mailto:sage [2007/03/28(水) 18:10:27 ]
- ttp://sourceforge.net/project/showfiles.php?group_id=96847
brookgpuの更新が止まってるように見えるんだけど、 とりあえずダウンロードしてみた。 サンプルプログラムどこ? 仕様はわかったんだけど、動作イメージが掴めねえ。
- 456 名前:デフォルトの名無しさん mailto:sage [2007/03/28(水) 22:28:46 ]
- BrookはCVSで更新は続いてるよ。
で話は変わるがPeakStream Free Trial Download ttp://www.peakstreaminc.com/product/free_trial_download.php GPUとしてはFireStream,R580(?) ttp://www.peakstreaminc.com/product/peakstream_for_windows/technical_reqs.php Supported GPUs AMD Stream Processor ATI Radeon x1950 (Supported for evaluation purposes only)
- 457 名前:デフォルトの名無しさん mailto:sage [2007/03/28(水) 22:30:06 ]
- PeakStreamはCTMしようか
- 458 名前:デフォルトの名無しさん [2007/03/30(金) 00:30:52 ]
- >>455
ヒント:brook/prog の下 あとここの解説も分かりやすい。 ttp://www.mi.tj.chiba-u.jp/~hamano/brook/sample/sample.html
- 459 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:40:37 ]
- つか、外人が思い付きで作ったキモイ言語使うのはヤメロ。
nVidia様の作られた環境だけを支持したほうがいいぞ
- 460 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:46:40 ]
- 実質BrookGPUは、Cで記述したソースをnVIDIA様が作られたCg言語にコンバートするシステムなわけだが…。
- 461 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:52:59 ]
- >>459はCUDAのことを言ってるのだろう。
たしかにあれはいいと思うが、世の中全てがnVIDIAチップじゃないのが問題。 家の中でnVIDAだけに絞って開発するならいいが。
- 462 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:29:54 ]
- >>460
でもFolding@homeでそれ使ったらまともに動かなかったんだろう。 そのマクロ言語が悪いんじゃなくて、ビデオカードが向いてなかったんだろうけど。
- 463 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 06:58:08 ]
- >>460
CVSだとCg,HLSLに加えCTMが。
- 464 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 10:37:08 ]
- 現状だと
・キモイ新言語(CUDA,Brook,CTM?) ・ぶっちゃけ使いやすくないグラフィックス記述(グラフィックスAPI+シェーダ言語) しか選択肢が無い件。 汎用性汎用性とか言いながらグラフィックス記述でプログラミングしてるけど、 GPUのアーキテクチャにひっついたキモイ新言語がGPUの性能を一番引き出せるんじゃね? という不安が拭えない。
- 465 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 11:05:14 ]
- CUDAには数値演算ライブラリもついてきたんじゃなかったっけ?
それが使えるもんなら、自分で書いてたらバカ見るなぁ。
- 466 名前:デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:28:43 ]
- つうかCUDAでいいじゃん、あれ将来的に完全に整数演算できるぞ
今はおもちゃ用だから科学計算じゃ糞だけど。ゲームとか軽い計算ならできる。
- 467 名前:デフォルトの名無しさん mailto:sage [2007/04/01(日) 19:04:47 ]
- BrookGPUで満足しているが、
あれを使うと、簡単だけど細かい操作が出来ないから 並列コンピューティングの技術やアルゴリズムが殆ど使えない…。 結果、リードバックの速度とか、GPUのマイナスの部分ばっかりが出てダメダメになるな・・・
- 468 名前:デフォルトの名無しさん mailto:sage [2007/04/01(日) 19:09:44 ]
- >>467
X19XXではうまく動いているみたいだよね>Folding@home
- 469 名前:・∀・)っ-○◎● mailto:sage [2007/04/01(日) 19:48:11 ]
- てか、「ストリームプロセッサ」として売ってるものそのまんまじゃね
AMD Fusionにもあれがほぼそのまま搭載されるとか
|

|