GPGPU - 暇つぶし2ch

GPGPU ..

355:デフォルトの名無しさん
07/02/21 14:54:32
NVIDIA CUDA Homepage
URLﾘﾝｸ(developer.nvidia.com)

356:デフォルトの名無しさん
07/02/22 11:02:37
Vistaまだっぽいな。。

357:デフォルトの名無しさん
07/02/24 22:27:08
とりあえず動かしてみたいけどG80廉価版待ち

358:デフォルトの名無しさん
07/02/25 13:00:56
初歩的な質問です。
GPGPUにチャレンジしてみようと思い、BrookGPUを使ってるんですが
ループの並列化がイマイチどのようにすればいいかがわかりません。

例えば、ループの部分で前回回した処理結果に加算を行う処理をする場合
前後関係が出てくるので、GPGPUに適した並列化は出来ないと思うのですが、こういうのは何か解決方法があるのでしょうか？

359:デフォルトの名無しさん
07/02/25 14:02:00
int i;
float x[1024];
x[0]=1;
for(i=1; i<1024;i++){
x[i]=x[i-1]*i;
}
みたいなやつの事？
そもそも、この手のはGPGPUに向かない。

360:デフォルトの名無しさん
07/02/25 14:15:44
>>358
依存関係がなくなるように計算式を変更するか、
並列させる方向を変えるような工夫が必要。

でもって、そういう工夫は実はSSEを使ったベクタ化やOpenMPによる並列化にも適しているので、
ますますGPUを使うメリットが活き難くなる罠。

361:デフォルトの名無しさん
07/02/25 18:34:02
並列計算はいいんだけど
計算の中間結果を保持する為の
テンポラリバッファが大きくなって
すぐ頭打ちになりそうなイメージ

362:デフォルトの名無しさん
07/02/25 21:41:38
演算精度が悪すぎて使い物にならない印象しかないんだが…。

363:デフォルトの名無しさん
07/02/25 22:13:06
明日G80にダイブしてみるよ！
飽きたら速攻で売り払わないと

364:デフォルトの名無しさん
07/02/25 23:03:53
>>362
URLﾘﾝｸ(mypage.odn.ne.jp)
もうじき倍精度サポート
現状でも型としてはサポートしてるからコーディングは可能

365:デフォルトの名無しさん
07/02/26 22:06:57
>>359-360

for( i=0; i<height; i++ ){
for( j=0; j<width; j++ ){
a=img[i][j]+img[i-1][j]+img[i+1][j];
}
}

こんな感じのもGPGPUには向かないってこと？

366:デフォルトの名無しさん
07/02/26 22:15:27
その処理は、コンパイラが優秀ならばCPUでもGPUでも
まあまあ効率よく実行されそうだが。

367:デフォルトの名無しさん
07/02/26 23:57:20
>>365
その処理は問題ない。むしろ超得意なくらい。

368:デフォルトの名無しさん
07/02/26 23:58:42
>>365
それは前後の処理結果は関係ないでしょ。
imgに代入するならともかく、imgと言うデータがあらかじめあるのなら、そのままVRAMに転送すりゃいいわけだし。

369:デフォルトの名無しさん
07/02/27 12:16:50
>>365 を Cg で書くとどんな感じ？

370:デフォルトの名無しさん
07/02/27 12:25:46
今はCgよりCUDAの方が。。。
まぁ古いGPU(俺を含めて)の人には仕方ないが。

371:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/27 14:02:44
じゃあCUDAで書くとどうなるの？

373:デフォルトの名無しさん
07/02/27 14:32:25
>>371
手抜きするなーｗ
外側のループもはずせるだろ。

いや、面倒だから俺はやらないけどなｗ
VRAMは自動開放だからな…、俺もよくフリーズさせてしまう。正確にはフリーズじゃなくて単に低速化するだけなんだろうけど
プロセスも殺せなくなるのが嫌だな

374:デフォルトの名無しさん
07/02/28 01:06:47
Brookでやるからだよ。
頑張って自分でCgとか使ってゴリゴリ動的にメモリを管理するんだ。
って言うか、あれは隠蔽されすぎてて何やってるのかわからんし、パフォーマンスが出るような組み方ができないので
遅すぎる。BrookGPU使ってCPU処理より速い処理ってかけるの？どう頑張ってもReadBackである意味速度差がつけられちゃうよ。

375:デフォルトの名無しさん
07/02/28 01:17:19
何度見てもスレタイをゲプゲップと読んでしまう

376:デフォルトの名無しさん
07/02/28 02:16:30
ぐぷぐぷってよんでる

377:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/28 05:24:56
あ、ｽﾏｿ
単純ミス。。。

GPU側にfloatで値を渡してたから、2重に変換されてた・・・

379:デフォルトの名無しさん
07/02/28 14:07:17
GPUにint型をfloatで送っちゃった時点で、桁落ち発生するでしょ。

380:デフォルトの名無しさん
07/02/28 15:29:00
桁落ちするの？

381:デフォルトの名無しさん
07/02/28 21:34:28
assert((float)0x7FFFFFFF != (float)0x7FFFFFFE);

382:デフォルトの名無しさん
07/02/28 22:11:09
Brookもint型が扱えればな…。
floatとintだと、個人的にはfloatの方が高度なものだと思うんだけど
なんで、float扱えて、int型が扱えないのかなぁ・・・

383:デフォルトの名無しさん
07/02/28 22:47:15
>>377
キャストしてGPU側に送って、GPU側で更にint型にキャストじゃ駄目なん？
って、GPGPUの言語名に使ってるかわからんけど、大抵intは無理なんかな

384:デフォルトの名無しさん
07/03/01 16:20:02
ところで、おまいらAMDのフュージョンは期待してますか？

385:デフォルトの名無しさん
07/03/01 16:29:50
AMDはコンパイラが期待出来ないから駄目
ここは嫌でもIntelやnVIDIAと共同で第3機関を作り、命令セットの仕様を管理させた方が良い。

じゃなきゃ3D NOWの二の舞さ。
どうせIntelもGPUコアとの統合を考えてるんだろ？
そうなった場合、どうせどこかで命令セットが共通化するんだから(しなかったら終わってる)
最初からそういう機関を作っとけよ。

386:デフォルトの名無しさん
07/03/01 17:39:38
そうなるよりチップセットにプログラマブル演算機能があった方がいいな。
メインメモリへ近いしCPUである程度処理して
並列化できる処理ではCPUがそのメモリアドレスを投げて
結果をCPUに戻すかGPUなどのバスに転送させる。
定数時間で出来る処理ならメモリ転送の代わりにできる。

387:デフォルトの名無しさん
07/03/01 17:45:11
チップセットにCPUくっつけたらいいんじゃね？

388:デフォルトの名無しさん
07/03/01 17:51:27
>>387
すでにAMDのCPUはメモリに直接つながってるからその状態では。

389:デフォルトの名無しさん
07/03/02 00:22:20
>>385
> じゃなきゃ3D NOWの二の舞さ。

AMD64はよくがんばったと思わないか?

390:デフォルトの名無しさん
07/03/02 00:29:55
あれは先にIA64が大コケして自爆しただけ。

391:デフォルトの名無しさん
07/03/02 00:48:26
IA-64はよくｶﾞﾝｶﾞｯﾃﾙお

Itanium2プロセッサベースのサーバ上で動作するアプリケーションの数が1万種類を超えた
URLﾘﾝｸ(www.itmedia.co.jp)
Itaniumベースのサーバが急成長を続けており71.5%成長で11億ドル市場
URLﾘﾝｸ(journal.mycom.co.jp)
Itanium搭載サーバ、売上ベースのシェアが国内RISCサーバの6割相当に拡大
URLﾘﾝｸ(www.rbbtoday.com)
Montecito搭載、HP Integrity SuperdomeがTPC-Cで世界記録
URLﾘﾝｸ(www.tpc.org)

392:デフォルトの名無しさん
07/03/02 01:12:33
>>389
あれは殆どマイクロソフト主導じゃん
ＭＳの戦うプログラマの人がAMD64自体の開発に関わってたし

後は、あれはあくまでx86命令の拡張で、今までのCPUの延長線上のものだが
今回のフュージョンは、アーキ的には全然比べ物にならないくらいの大改造だから…

393:デフォルトの名無しさん
07/03/03 03:45:34
CPUコアに統合されれば、GPGPUの最大の問題点であるReadBackの遅さが解決するな。
そもそも、CPUの命令に自然に溶け込む形みたいなので、GPGPUとか意識せずとも、勝手にコンパイラがやってくれそうな気もする。

394:デフォルトの名無しさん
07/03/04 00:53:22
粒度はどんなのになるんだ？
現行GPUでいうところ quad とか batch とかにあたるもの。

395:デフォルトの名無しさん
07/03/04 01:06:43
自分でループ展開して並列化して、各GPUをプログラマに管理させたりしてｗ
まぁ、コンパイラが勝手にやってくれるんじゃないかな。
それ以外の場所は、一般的なクラスタリングシステムみたいにやってくれるって事はないと思われ
そういうことは研究されてるけど、まだまだ一般的なコンパイラ1発でやってくれる仕組みは完成しているとは言いがたい。
最適な粒度をコンパイル時に調べてくれるとかやっても、別環境で実行する場合変わるしなぁ。

396:デフォルトの名無しさん
07/03/04 12:47:40
いや、俺が知りたいのは、それぞれのユニットがプログラムカウンタを持つのか、コプロセッサ命令でシェーダアレイコントローラに命令するのか、ということなんだ。
全部のユニットにプログラムカウンタがあったら、そりゃサブプロセッサが沢山載ったマルチコアでしかないじゃん。
コプロセッサ命令になるにしても、拡張命令で１度に１つのユニットに１命令送るだけじゃ意味ないから、適当なグルーピングが必要だと思うんだけど。
x86ISAの拡張ってんだから、後者ではあるんだろう。
で、その粒度はどんなのになるんだろうな、と。
>395 の話題も面白そうだけど、他のプロセスなりスレッドとのユニットの取り合いとかも考えるとやってらんないね。

397:デフォルトの名無しさん
07/03/04 15:14:04
偉そうな口調で頓珍漢な事言ってる人は、出て行って欲しい。
んがぁ、無理なんだよね。

ひろぽんは、殺伐とした方が情報の濃度が上がるとか言うけど、
白痴や馬鹿が沢山いるのに、そりゃああり得ない話。
頓珍漢なこと言ってると理解出来るレベルの人にとっては、
その情報って情報価値を持たない情報だったりするし。

398:デフォルトの名無しさん
07/03/04 15:27:13
日本語でおｋ

399:デフォルトの名無しさん
07/03/04 15:28:36
ウォッカはストロワヤが一番。やっぱりウォッカはロシアだね。
スレ違いスマソ。
自分の、これはダメかもわからんねは、
バイクで50キロぐらいで2車線目を走っていた。
するといいきなり目の前に1車線目に止まっていた車が右に、
フルブレーキするまもなく追突（前輪あたり）
10m程飛ばされて頭、ほんとにてっぺんからアスファルトに直撃。
その瞬間首が変な方向に、ぐにっとなった時。

結果は頭を支点にそのまま背中をまたアスファルトに直撃。
シボンヌ・・・、と思ったら生きてる。
その瞬間、車に腹が立って立ち上がり走っていってボンネットの上に飛び乗った。
運転手ポカーン、
んで警察に行って、病院行って、CT撮って診察の時。
他に痛い所は？と先生。
タンクで金タマ打って少し痛い。と言うと
顔色を変えてそれはいかんな、チョット見せて
（看護婦ちょっとはにかんだ様な顔でカーテンを引く）
先生、漏れの金玉をうねうねコロコロして。
ん～、大丈夫でしょう。しばらくすると痛みも引きます。
と言いながらカルテにカキコしてるのを見ると
　
　　睾丸hit　　　　

これはだめかもわからんね・・・

400:デフォルトの名無しさん
07/03/04 15:58:53
朝鮮語でおｋ

401:デフォルトの名無しさん
07/03/04 22:07:30
>>397
流れ的に俺のことなんだろうが、フロントエンドにしか興味ないのか？

402:デフォルトの名無しさん
07/03/04 22:14:46
ネットワークのスレとかにも現れる
「おまえらバカばっかりだな」系の人だろ

もちろん具体的な議論はしません

403:デフォルトの名無しさん
07/03/05 15:18:23
>>401
何処の人か分からないけど、ごめん。
イント、フロートでごちゃごちゃ言ってた人のこと。

404:デフォルトの名無しさん
07/03/05 18:45:01
それも多すぎてわからん。

405:デフォルトの名無しさん
07/03/05 23:09:11
【キーワード抽出】
対象スレ： GPGPU
キーワード：イント

403 名前：デフォルトの名無しさん[sage] 投稿日：2007/03/05(月) 15:18:23
>>401
何処の人か分からないけど、ごめん。
イント、フロートでごちゃごちゃ言ってた人のこと。

抽出レス数：1

406:デフォルトの名無しさん
07/03/05 23:32:35
イント人もびっくり

407:未来人
07/03/07 16:29:31
GPUってCPUに取り込まれて無くなってたよ。
CPUは、FPUとSPUとGPUで構成されてたよ。

408:デフォルトの名無しさん
07/03/07 20:51:05
>>396
「何時の時代の人だ（と言ってもたかだか数年前だが・・）」的な
ことを今更「俺が知りたいのは」とか書くから荒れる。勉強しろ。

409:デフォルトの名無しさん
07/03/08 01:13:12
>>408
url か検索ワードくらい教えてくれ。
英語でなんて表現したらたどり着くのか見当も付かん。

410:デフォルトの名無しさん
07/03/08 03:00:48
【Penryn】次世代モバイルCPU雑談ｽﾚ 3【Nehalem】
ｈｽﾚﾘﾝｸ(notepc板:537番)

537 名前：[Fn]＋[名無しさん][sage] 投稿日：2007/03/07(水) 17:10:43 ID:o4rB4JJN
GPUだからコプロセッサではない。
同様にデュアルコアだからデュアルCPUではない。
たしかに正しい。
でもこの視野の狭さがアホな言動につながるのです。
プログラムから見るとどう見える?
概念レベルではどう見える?
そんな視点は一切ない。

411:デフォルトの名無しさん
07/03/08 05:54:39
GPGPUの研究発表を聞いた
CPUのみに比べて若干早くなっている程度
たぶんプログラミングレベルが低いのもあるんだろう
コストパフォーマンスについて聞いたら
「将来的には」を連発してた
CPUよりコストパフォーマンスの伸びが良い予定らしい

412:デフォルトの名無しさん
07/03/08 06:29:53
だってさ、1度でもGPGPUでコーディングした人ならわかるでしょ。
GPUを活かせる箇所が少ない事に…。
GPUといえども、1つあたりのストリームプロセッサの能力はCPUに比べて鼻くそだし、ReadBackのコストも馬鹿みたいにかかるんだから
並列化できなけりゃ意味がない・・・。そんな都合の良いループ部分が現状のコードや計算式見てそんなにあるか？

413:411
07/03/08 06:57:00
早起きなのか徹夜かどうかはさておき、さっそくどうも。

うちのソースは機械系で有限要素的なので割とあるんだな。
PS2の時に1GFlops程度出たけどP4のSSEにトータルで負けた。
CellとGPGPUは期待してるけど過剰期待は禁物だと思ってる。
いちおうGeForce8800買ってみるよ。
Cellはソフト作る気にもならないのでライブラリ充実待ち。

414:デフォルトの名無しさん
07/03/08 07:33:26
私のところも並列できる応用は色々ある。
実際、ClearSpeedやXTrillionのようなアクセサレータボードで速度が出ている。
それらに較べれば、コストはGPGPUなら桁違いに掛からないわけで。
#CELLも評価対象になってるけどね。

415:デフォルトの名無しさん
07/03/08 09:02:04
ムダ毛対策にもGPUによる並列処理が効果的らしい。

416:デフォルトの名無しさん
07/03/08 11:01:34
>>415
全身大やけどしました

417:デフォルトの名無しさん
07/03/21 18:20:19
>>412
動画のエンコードだと1つのキーフレームを1つのストリームプロセッサに
担当させることによって、簡単に並列化できる。

418:デフォルトの名無しさん
07/03/22 17:50:05
標準的なグラボは
VRAM128M
ストリームプロセッサは64基

１コアあたり2Mしか使えん。(それ以前に128M丸々使えるわけが無い)
丸々割り当てるのは辛いんじゃないか？

419:デフォルトの名無しさん
07/03/23 02:50:52
メモリ容量は768MBを想定してたから確かに128Mの場合は辛いなぁ。
GPU側のメモリを使いきるごとにCPU側のメモリに渡すというやり方で
なんとかなりそうな気はするけど。

420:デフォルトの名無しさん
07/03/23 03:07:17
完全にCUDA世代のグラボ前提の話になってるな
まだ遠い話だ・・・

421:デフォルトの名無しさん
07/03/23 07:20:12
URLﾘﾝｸ(fah-web.stanford.edu)
GPGPU遅いとかいうのはnVIDIAのG7x前提だからだったんだね・・・

ATIのR580速いや・・・
Cellの倍の実パフォーマンス・・・

1台あたりは
PS3 30GFLOPS
GPU 60GFLOPS

422:デフォルトの名無しさん
07/03/23 10:07:36
そのCellもフルパワー出てるかわからないけどね

423:デフォルトの名無しさん
07/03/23 10:43:06
>>421
俺、G7xに限らず、G80でも試したが、結果は似たようなもんだったぞ。
ぶっちゃけGPGPUは、もはや言葉だけが先行した流行りモノに過ぎない気が・・・

実際、BrookGPUとか使えばC使える人なら簡単にGPGPU出来るようになったのに
誰も使ってないし、使ってる人は割りと失望してる人が多い・・・

424:デフォルトの名無しさん
07/03/23 12:59:13
G80持ってる人ここのヤツ試してくれん
URLﾘﾝｸ(gpgpu.jp)
URLﾘﾝｸ(gpgpu.up.seesaa.net)
URLﾘﾝｸ(gpgpu.up.seesaa.net)

姫野ベンチその２
URLﾘﾝｸ(gpgpu.jp)
brookbench ver.0.01
URLﾘﾝｸ(gpgpu.jp)

G80とG7xでそんなに違わないって>>423の発言が気になる。
G70とRV530で十倍近い差有るし・・

じつは、G80もG70同様遅いのかな？

425:デフォルトの名無しさん
07/03/23 13:31:21
上手く全てのコアを綺麗に動かせれば、当然差が出るけど
実際の場面で、汎用処理でそういうことをするのは難しい。

姫野ベンチのようなプログラムだと差が出るだろうけどな

426:デフォルトの名無しさん
07/03/24 22:24:06
いい加減ナントカシェーダという呼び方はやめなさい

427:デフォルトの名無しさん
07/03/25 02:00:17
既に定着してしまっているモノを変えたければ、
より多くの人に共感してもらえて説得力のある代替案を出さなきゃ。

428:デフォルトの名無しさん
07/03/25 02:08:48
David Kirk 「この命名はおかしいと自分も思う。Shader(プロセッサ)はプロセッサと呼ぶべきだと思う」
URLﾘﾝｸ(pc.watch.impress.co.jp)

429:デフォルトの名無しさん
07/03/25 02:46:49
nvidiaはストリームプロセッサと呼んでるじゃん

430:デフォルトの名無しさん
07/03/25 05:51:54
シェーダーって元々影処理専門だったんだっけ？

431:デフォルトの名無しさん
07/03/25 06:59:56
それはシェイドシェイダーユニットの役割ですね

432:デフォルトの名無しさん
07/03/25 14:44:57
shade (r)だから影erみたいなもんだろ。

433:デフォルトの名無しさん
07/03/25 17:09:13
元が3DCG用語だからな
それをgenericな用途に使おうとしてるんだから
呼び方に違和感が出てくるのはしかたあるまい

434:デフォルトの名無しさん
07/03/25 19:00:37
3DCGの範疇であるvertex shaderの時点でもうおかしいわけなんだが

435:デフォルトの名無しさん
07/03/25 19:44:42
ピクセル影er
頂点影er
プログラム可能な影er

436:デフォルトの名無しさん
07/03/25 22:56:05
CG用語のシェーダーっていうのは凄く広い意味を持ってるからややこしい。
基本的に与えられたデータを元にピクセル出力するためのプログラムは全てシェーダー。
頂点処理をするのもそうだし、毛を生やしたりするのもシェーダーと言ったりする。

437:デフォルトの名無しさん
07/03/25 23:08:12
「シェーダ」は元々はRenderManとかmental rayとかの用語でしょ

438:デフォルトの名無しさん
07/03/26 04:57:07
vertex shaderはピクセルの出力と全く関係ないような

439:デフォルトの名無しさん
07/03/26 09:44:43
CUDAを使ってトリップ検索させると速いですか？

440:デフォルトの名無しさん
07/03/26 09:46:56
そういうのには向いてません。

高速にcryptを実行するってのは前に試したけど
いい感じにかきなおせなかったわ。　

441:440
07/03/26 09:49:34
ちなみに、cryptの能天気な話は
URLﾘﾝｸ(www.gpgpu.org)
ここみてちょ。
ここに載ってるパワポは見た上で試したが…。

こいつら、分かってて書いてるんだろうけどさ・・・。

442:デフォルトの名無しさん
07/03/26 10:09:49
>>439
8800GTSで試したんだけど遅くはないけど激速じゃない。(4M程度)
コストパフォーマンスではC2Dよりちょっと分が悪い。
春に廉価版が出揃って、CUDAのバージョンが上がったらモノになるかな?

整数演算のイマイチ度については各方面から突き上げが激しいので
次アーキでは劇的に改善される可能性はなきにしもあらず。

>>440
俺はLUTで試したけど、MP内にてLoadネックで
並列度が頭打ちになってる感じ。>>440が試した結果をもすこし詳しくきぼん

443:デフォルトの名無しさん
07/03/26 10:59:36
■後藤弘茂のWeekly海外ニュース■
CPUとGPUの大きな違い
●汎用コンピューティングで近づくCPUとGPU
URLﾘﾝｸ(pc.watch.impress.co.jp)

444:デフォルトの名無しさん
07/03/26 19:18:04
>>442
C2DでもTrip-Monaで500k程度だから4Mでも十分じゃん

445:・∀・）っ-{}@{}@{}@
07/03/26 19:38:01
やきとり屋さんだよ

446:デフォルトの名無しさん
07/03/26 20:56:14
utripperはathlon64 2GHzで動かすよりCeleron 1.3GHzの方が速かったんだけどそんなもん？

447:・∀・）っ-○◎●
07/03/26 21:06:48
アレはキャッシュのレイテンシ依存だし

PS3で10Mうめぇｗｗｗｗとか言ってるの俺だけ？

448:デフォルトの名無しさん
07/03/26 21:14:43
>>447
Cellで？

449:・∀・）っ-○◎●
07/03/26 21:48:56
RSX使わせてくれないから、まあそうなるかな

450:デフォルトの名無しさん
07/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:・∀・）っ-○◎●
07/03/26 23:25:58
（・∀・）

452:デフォルトの名無しさん
07/03/27 10:26:11
>>450
電源が死にそうだね。つーか、熱対策か。

453:・∀・）っ-○◎●
07/03/28 01:25:33
CPUはClovertownの50W版でよくね？

454:デフォルトの名無しさん
07/03/28 03:45:24
取り敢えず、8800GTXの動く環境はできた。
#CPUは1coreXeonだけど。
さて、来月から実験だ。

455:デフォルトの名無しさん
07/03/28 18:10:27
URLﾘﾝｸ(sourceforge.net)
brookgpuの更新が止まってるように見えるんだけど、
とりあえずダウンロードしてみた。
サンプルプログラムどこ？
仕様はわかったんだけど、動作イメージが掴めねえ。

456:デフォルトの名無しさん
07/03/28 22:28:46
BrookはCVSで更新は続いてるよ。

で話は変わるがPeakStream Free Trial Download
URLﾘﾝｸ(www.peakstreaminc.com)

GPUとしてはFireStream,R580(?)
URLﾘﾝｸ(www.peakstreaminc.com)
Supported GPUs
AMD Stream Processor
ATI Radeon x1950 (Supported for evaluation purposes only)

457:デフォルトの名無しさん
07/03/28 22:30:06
PeakStreamはCTMしようか

458:デフォルトの名無しさん
07/03/30 00:30:52
>>455
ヒント：brook/prog の下
あとここの解説も分かりやすい。
URLﾘﾝｸ(www.mi.tj.chiba-u.jp)

459:デフォルトの名無しさん
07/03/30 00:40:37
つか、外人が思い付きで作ったｷﾓｲ言語使うのはヤメロ。
nVidia様の作られた環境だけを支持したほうがいいぞ

460:デフォルトの名無しさん
07/03/30 00:46:40
実質BrookGPUは、Cで記述したソースをnVIDIA様が作られたCg言語にコンバートするシステムなわけだが…。

461:デフォルトの名無しさん
07/03/30 00:52:59
>>459はCUDAのことを言ってるのだろう。
たしかにあれはいいと思うが、世の中全てがnVIDIAチップじゃないのが問題。
家の中でnVIDAだけに絞って開発するならいいが。

462:デフォルトの名無しさん
07/03/30 01:29:54
>>460
でもFolding@homeでそれ使ったらまともに動かなかったんだろう。
そのマクロ言語が悪いんじゃなくて、ビデオカードが向いてなかったんだろうけど。

463:デフォルトの名無しさん
07/03/30 06:58:08
>>460
CVSだとCg,HLSLに加えCTMが。

464:デフォルトの名無しさん
07/03/30 10:37:08
現状だと
・キモイ新言語（CUDA,Brook,CTM?）
・ぶっちゃけ使いやすくないグラフィックス記述（グラフィックスAPI＋シェーダ言語）
しか選択肢が無い件。

汎用性汎用性とか言いながらグラフィックス記述でプログラミングしてるけど、
GPUのアーキテクチャにひっついたキモイ新言語がGPUの性能を一番引き出せるんじゃね？
という不安が拭えない。

465:デフォルトの名無しさん
07/03/30 11:05:14
CUDAには数値演算ライブラリもついてきたんじゃなかったっけ?
それが使えるもんなら、自分で書いてたらバカ見るなぁ。

466:デフォルトの名無しさん
07/04/01 16:28:43
つうかCUDAでいいじゃん、あれ将来的に完全に整数演算できるぞ
今はおもちゃ用だから科学計算じゃ糞だけど。ゲームとか軽い計算ならできる。

467:デフォルトの名無しさん
07/04/01 19:04:47
BrookGPUで満足しているが、
あれを使うと、簡単だけど細かい操作が出来ないから
並列コンピューティングの技術やアルゴリズムが殆ど使えない…。

結果、リードバックの速度とか、GPUのマイナスの部分ばっかりが出てダメダメになるな・・・

468:デフォルトの名無しさん
07/04/01 19:09:44
>>467
X19XXではうまく動いているみたいだよね＞Folding@home

469:・∀・）っ-○◎●
07/04/01 19:48:11
てか、「ストリームプロセッサ」として売ってるものそのまんまじゃね
AMD Fusionにもあれがほぼそのまま搭載されるとか

470:デフォルトの名無しさん
07/04/01 20:01:33
>>467
BrookGPUが細かい事出来ないのは同意だけど
元々各シェーダーユニットを管理して並列化を効率化する事は出来ないぞ。
ベクトルプロセッサだから、そういうものだ。

うん、綺麗に管理できると良いんだけどなぁ…。

471:デフォルトの名無しさん
07/04/01 22:15:30
いやだからCUDA使えってあれなら俺等が求める
世界を追求できる。とりあえず、Geforce8600買ってみろ

472:デフォルトの名無しさん
07/04/01 22:26:58
上のほうにあるbrookの姫野ベンチ(>>424)でも
X1300とX1600で結果が変わらないって出てるから
その辺はBrookで変換した後、更に手作業の最適化が必要なんじゃないかな
Folding@Homeは素直にShaderの数がパフォーマンスに出てるし。（単に演算の規模が違うだけ？）
Brookだと、変換言語（？）もGLSLからCg、最近ではCTMもあるようだし。

そういえば、Inqの記事に何でnVIDIAにはGPGPUなソフトが出ねーんだ？的な記事が出てた
PS3にさえFolding@Homeがでて、ATIはとっくにやってるしnVIDIAはなぜ？ってな感じで。
URLﾘﾝｸ(www.theinquirer.net)

実際にはG80とCUDAならFolding程度なら可能なんかな？
G80ないんで何ともいえないけど。

473:デフォルトの名無しさん
07/04/01 22:33:30
R580でやってるfoding程度はG71でも可能だがパフォーマンスが出なかった
G80ではどうなんだろうな

474:・∀・）っ-○◎●
07/04/01 22:36:24
CellでPCの数百倍ってちょっと信じがたいんだけど
レジスタ本数が重要とかってこたないよな？
nVIDIAのシェーダってレジスタ少ないんじゃなかったっけ

475:デフォルトの名無しさん
07/04/01 22:36:41
>>472
おれもそうだけど、まだG88を買ってるやつがほとんどいないんじゃないかな。
おもちゃとしてはちと高いし、入れるとうるさいだろうし。

>>347がOS 32bitに載せ替えてくれればいいんだけど、それまでは皆次世代廉価版
待ちなんだろう。

476:デフォルトの名無しさん
07/04/01 22:57:37
>>347
つかおまえ、金はあるが知識無さ過ぎだろ？Linux入れろベンチ取るぐらいの駄コード書くのに
何64bitとOSにこだわり持ってるんだ？お前なら、RE買うのお金がないのですがとか言いそうで恐いけどなw

477:・∀・）っ-○◎●
07/04/01 23:17:02
俺なんかXeon買う金ないからPS3買ったくらいだｗｗ
はやくRSX使いたいｗｗｗ

478:デフォルトの名無しさん
07/04/01 23:30:37
おれはNXT買う金がなくてRCX買ったよ

479:デフォルトの名無しさん
07/04/01 23:30:53
>>477
そのRSXって、要はG7XXXだろ。あんまり使い途ないんじゃないかなあ。
X11周りを作り替えるってんならありがたい話だが、あんたそういうのできる人だっけ？

480:・∀・）っ-○◎●
07/04/01 23:38:23
出来ない人。
むしろ描画のHWアクセラレーションが利かないのが痛いの。
欧州ギークならなんとかしてくれる・・・と思いたい

481:デフォルトの名無しさん
07/04/02 00:12:15
>>480
Linux板で人の話を聞かずに無駄金使ったな。

482:・∀・）っ-○◎●
07/04/02 00:21:37
GPU使えないって言ってもフレームバッファは使えるし
X立ち上げて普通に使う（FireFoxでWebブラウズしたり）分には特に問題ない。
意外と使えるんでびっくり。

まあ現状でもCellマシンとしては十分元は取れてると思う。
General Processing出来る専用コプロセッサが7個
（ユーザーモードでは使えるのは6個）あるし。

今使えなくてもアップデートで使えるようになる可能性もあるし。

483:デフォルトの名無しさん
07/04/02 00:25:34
まともにニコ動が見れないWebブラウズなんかいみねーよ

484:・∀・）っ-○◎●
07/04/02 00:28:07
Flashが見れないのはPPC Linux用Flashプレイヤーが提供されてないからで
PS3のせいじゃないだろ

485:デフォルトの名無しさん
07/04/02 00:41:12
>>482
わかってないね。
Linux板で言ってたのは、鯖機のつもりで使えば、何の不満もないだろってことだよ。
コンソールはおまけ。おまけがそのうち化けるかもしらんけど。

486:デフォルトの名無しさん
07/04/02 01:25:25
取り敢えず仕事用にHPの中古EWS調達して8800GTXのボード入れているけど、五月蝿いとは思わないなぁ。

487:デフォルトの名無しさん
07/04/02 02:37:17
立ち読みしたPS3 Linux雑誌によるとnVIDIAはPS3 Linux用ドライバ作る気零らしい。
署名しかないのか。。。？

488:・∀・）っ-○◎●
07/04/02 06:50:53
GK「トップガンならやれる」

489:デフォルトの名無しさん
07/04/02 09:49:07
>>486
＞HPの中古EWS
それ、Netburst Xeon機だろ。
足下に2台あるけど、（ヘッポコカードとは言え）ビデオカードの音などまったく気にならない。
でも、「五月蠅くない」ってのとは違うだろう。
こんなの自宅で使いたくない。

>>487
今のところRMSの言の通りだね。
業者の非openなドライバに依存していると、いつかテメエの首が絞まる。

490:デフォルトの名無しさん
07/04/02 12:59:20
能力の低いopenドライバと能力の高いclosedドライバの
両方があったら俺は後者を使う。
使えなくなったときに移行すれば良いだけだし。

491:デフォルトの名無しさん
07/04/02 20:01:51
URLﾘﾝｸ(forums.vr-zone.com)
>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:デフォルトの名無しさん
07/04/02 23:18:57
ネタもとの日付が気になるが
Fusionにはたしかに、でかめのキャッシュかレジスタが必要でしょうな。
EDRAMとして使えばXbox360は軽く超えてしまうのか・・・

493:デフォルトの名無しさん
07/04/02 23:27:30
Fusionの話かと思ったが、Socket FのGPUの話け？

494:デフォルトの名無しさん
07/04/03 04:16:21
BrookGPUって、実行環境で環境変数設定しないといけないけど
あれって凄く不便なんだよなぁ・・
例えば自分の配布ソフトに組み込みたい時とか・・・

495:デフォルトの名無しさん
07/04/05 00:09:04
環境ごとにバッチファイルでも作ればよくね？

496:デフォルトの名無しさん
07/04/05 02:11:33
つかCUDA以外全部失敗とみなしてもいいほど糞だ。
オナニー言語とかマジ作るのやめてほしい見てると
イライラしてぶっ潰したくなってくるよ

497:デフォルトの名無しさん
07/04/05 13:38:48
Cgがあの有様なのに、今度はCUDAに期待しろとなｗ

498:デフォルトの名無しさん
07/04/05 20:22:18
8800を汎用計算で速度計測したサイトが見つからないんで、教えてほしい。

499:デフォルトの名無しさん
07/04/05 20:35:58
8800にあんまり魅力を感じないんだけど研究する価値ある？

500:デフォルトの名無しさん
07/04/05 22:25:28
>>499
CUDAが動くのが8800しかないから。
今更後戻りはしないだろうから、新世代毎にCUDAが使える
ビデオカードが増えてくるはず。

AMD X19XXはBrockGPUでも使い物になることがわかった(folding)
nVIDIAがどういう状態なのかわからないんで。

501:デフォルトの名無しさん
07/04/05 23:18:25
CUDA_SDK入れてみたけど、サンプルが動作確認的なのばかりで
パフォーマンスが目に見えるようなのが無くてちょっと寂しい。

502:デフォルトの名無しさん
07/04/06 00:06:01
ゲーム用途でなんだが
いわゆる、プロシージャル処理をGPUでやらせようっていう動きに
AMDは積極的のようですね。
GDCの内容もそれっぽい
R600のRubyのデモも雪原はプロシージャル生成らしい

URLﾘﾝｸ(ati.amd.com)(GDC07_AMD_Session).pdf
これの48ページ目の絵を良く覚えておいて
Ruby demoを見てみよう
URLﾘﾝｸ(youtube.com)

nVIDIAもトンボのデモでやってるっぽいけど
インパクトは・・

503:デフォルトの名無しさん
07/04/06 00:19:25
>>502
絵の話はよそでやってくれよ。

504:デフォルトの名無しさん
07/04/06 02:29:42
とりあえずBrookGPUがなぜユーザーに環境変数を設定させる方式にしてるのかが疑問だ
ライブラリの初期化のときにパラメータを与える方式にしない理由がわからん。

bgInit(BG_OPEGL);
みたいにさぁ

505:デフォルトの名無しさん
07/04/06 03:01:54
>498
自分でやれば、論文かけちゃうぞ。

>499
NVIDIAでは前のﾓﾃﾞﾙと構造が違うから、前との比較なんぞをやってしまえばこれもまた研究になると思う。

っていうかCUDAがあるのにBrookGPUを使う意味がわからん。
特定の処理に関しては楽なのか?

506:デフォルトの名無しさん
07/04/06 03:09:09
CUDAを使うにはGF8シリーズが必要だろ
BrookGPUなら、プログラマブルシェーダーを搭載していれば、主要なGPUで動く

507:デフォルトの名無しさん
07/04/06 07:26:06
GPGPUの壁の一つにそういった汎用性の問題があるよね。
ATIのいう業界標準のAPIに期待。

508:デフォルトの名無しさん
07/04/06 16:21:22
ATIの業界標準APIってなんだよｗ
標準にならないと、所詮CUDAと同じ

業界標準で言うと、nVIDIAのCgの方がマシ
あれはシェーダー搭載している主要グラボにほぼ対応している。
純粋なGPGPU用の言語ではないけどな。
んで、Cg用のコードを吐き出すBrookGPUがまだマシだとあきらめて使われてる理由でもある

509:デフォルトの名無しさん
07/04/06 23:19:25
汎用演算が今後広く普及したとしても、
nVIDIAとATiでなかよく一つの業界標準言語を作るのは無理だろうね。

MS（の強要）頼みかな。

510:・∀・）っ-○◎●
07/04/06 23:27:50
SPEのISAは普及しそうにありませんか？（本音：糞食らえ

511:デフォルトの名無しさん
07/04/07 00:11:12
Cgは一応MSも噛んでるな
しかもATiでも的でも使える。
CUDAもそんな感じにするんじゃないの？

512:デフォルトの名無しさん
07/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.

URLﾘﾝｸ(research.microsoft.com)

513:デフォルトの名無しさん
07/04/07 01:42:17
.NETかよ

514:デフォルトの名無しさん
07/04/07 10:21:45
Ge86発売日に意味もなく東京に行く出張入れることを成功したぜ。
上司になんでこんな時期に本社へ出張必要なのぉ？って怪しまれたが
気にしない。CUDAするために、２枚購入してくるぜ。

515:デフォルトの名無しさん
07/04/07 18:28:10
SLI　CUDAできるのかな？

516:デフォルトの名無しさん
07/04/07 18:38:50
出張期間延長で
通販にしとけばﾖｶﾀｰ
と嘆きつつPC一式調達してホテルでいじる>>514に乾杯!

517:デフォルトの名無しさん
07/04/07 20:41:43
URLﾘﾝｸ(www.kohgakusha.co.jp)
ここのソース試した人いる？

ＶＣでまともに動かないんだけど

518:デフォルトの名無しさん
07/04/08 03:18:39
もうすぐGF8600および8500が出る。
それからが本当にGPGPUが普及するかの正念場だな。
8800はヘビーユーザーだけの代物だったが、8600や8500は十分一般ユーザーの手に入る価格帯だし。
まぁ、その分ベンチは散々だが、所詮ローエンド

519:デフォルトの名無しさん
07/04/08 04:33:46
まぁ、このスレ何気に4割が俺の書き込みなんだよなぁ・・・。
その状況から言って、やっぱり寂しいものがあるよなぁ。。。

520:デフォルトの名無しさん
07/04/08 05:52:11
おまいさん>>131か？

521:デフォルトの名無しさん
07/04/08 09:09:30
毎日スレ更新してるのでバンバン書き込んでください＾－＾

522:デフォルトの名無しさん
07/04/08 11:04:36
まだ手を出すのは早いからな
デフェクトスタンダートが決まりつつあり
日本語ドキュが整備されつつあるぐらいでも
十分遅くない、経験的に

523:デフォルトの名無しさん
07/04/09 04:26:21
>>514-515
CUDAのforumに、GPUが非SLIで複数ささってれば全部使うよー、って書いてあった気がするんだけど、ソースを失念。

524:デフォルトの名無しさん
07/04/09 04:38:03
そんな(消費電力とスペースの)恐ろしいことはできないw

525:デフォルトの名無しさん
07/04/09 15:21:38
最近のGPUは前世代の2倍のパフォーマンスだけど消費電力も2倍って感じだからなw
ATIの新しいのはビデオカードだけで250Wとか酷すぎる。

526:デフォルトの名無しさん
07/04/09 15:46:29
8800GTXなんて、+12V電源を30A用意しろと書いてあるよ。
単純計算するとそれだけで360Wだ。
#実際、ボード上に+12V用6pin電源コネクタが二つもある。

527:デフォルトの名無しさん
07/04/13 03:40:49
CPUのように消費電力が通常の半分で値段が通常の1.5～2倍の
製品を出してくれれば、一般的な開発者もGPCPUの検討用に買ってみようか、
というやつが増えると思う。
次世代では両者とも検討してほしいところ。

・・・と思ったが、250Wやら300Wやらじゃ、半分でもNetbust「全盛期」かそれ以上だ。
んなもん、ゲームもしないのに買ってもアホらしいな。

528:デフォルトの名無しさん
07/04/13 11:08:03
計算終わった後に「チーン」って音しそうだな。

529:デフォルトの名無しさん
07/04/13 13:24:32
おい、CUDA SDK 0.81 あるぞ。

530:デフォルトの名無しさん
07/04/13 14:16:29
あるぞといわれても

531:時々書いてるこのスレの住人
07/04/13 14:32:29
取り敢えず拾った。

>>529
THX!

532:デフォルトの名無しさん
07/04/13 18:29:20
>>529
ｱﾘｶﾞﾀﾏｷﾝ ( ´∀｀)ﾉ⌒ω)Д`)ﾌﾞﾆｭ

533:デフォルトの名無しさん
07/04/15 13:13:41
けっこうCUDA使い＝8800使いがいるんだね。
簡単な結果でいいから、報告してくれないかな。

534:・∀・）っ-○◎●
07/04/15 13:21:27
おれCUTA使い

535:デフォルトの名無しさん
07/04/15 15:41:46
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

536:デフォルトの名無しさん
07/04/15 16:37:35
>>533
なんか適当なベンチマークないかね。
nVideaのサンプルは動作確認っぽいのばかりで動かしても面白くないのだけれど。
#つーか、私も作らないとなんだけどね(苦笑

537:デフォルトの名無しさん
07/04/15 16:44:08
SDK 0.8だと、どうしても一塊のデータをわっと処理するバッチ系の
サンプルしかなかったので、俺の場合まだまだ基本性能を評価する段階だった。
NVIDIA FORUMでは、「演算サーバみたいなもの組めねえぞｺﾞﾙｧ」なトピックがHotだった。
>>529は俺なんだが、今別の遊びをやってるのでCUDAしばらく棚上げだ。
他の誰かがほげってくれるのを待つ!

538:デフォルトの名無しさん
07/04/15 23:54:14
>>533同意
とりあえず>>424の姫野ベンチの結果が知りたいな

539:536
07/04/16 11:31:05
Linuxだから無理。
じゃないけどBrook入れてないからめんどい。

540:デフォルトの名無しさん
07/04/16 12:17:16
実行だけならBrook入れなくても
出来るよ。

541:デフォルトの名無しさん
07/04/16 23:48:51
>>533
つーか今CUDAって8800以外で使えるの？

542:デフォルトの名無しさん
07/04/18 18:04:18
ｹﾞﾌｫ廉価版出たけどあまりにも性能差が差別化されまくり。
それでも、エミュよりマシだと思えばいいのか。

543:デフォルトの名無しさん
07/04/18 20:24:05
8600が出ましたよ。

544:デフォルトの名無しさん
07/04/18 21:09:01
質問です。
ifやswitchなど条件分岐を一切使わずに汎用プログラミングを行うと言うのがかなり理解出来ないのですが
一般的にGPUでのプログラミングでは、この辺はどのようにしているのでしょうか？

例えば、GPGPUによる、動画のエンコーダーなどの分野は期待しているのですが
あの手の処理は、条件分岐の塊だと思うので、GPUではそれらが使えないとなると有効な実装方法が思いつきません。

545:デフォルトの名無しさん
07/04/18 22:05:46
>>544
分岐の分だけmain()を作る
今はもうレガシな手法になりつつあるが。
当然個々のフラグメントプログラムは
画一したフローを踏むことになる。

546:デフォルトの名無しさん
07/04/18 22:16:00
>>545
一瞬びっくり！という感じだけど、やっぱりわからない。
if文は普通にc++で書いて特定の箇所で飛ばすのに比べて、
mainたくさんというのは、どういうメリットがあるの？

547:・∀・）っ-○◎●
07/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:デフォルトの名無しさん
07/04/18 23:12:58
>>547
>>545の話はそういう話なのかい？
＞mainじゃなくてもサブルーチンでもいいけど
あんたのコードで//HogeHogeのところで別プロセス呼んでたりしたら、
普通は頭がおかしいコードだと思うよね。

549:・∀・）っ-○◎●
07/04/18 23:19:36
プログラムって基本的にループの塊なんで、

むしろループがプロセスの単位だと思ってくれ

550:デフォルトの名無しさん
07/04/18 23:24:46
いやさ、おれもコード書きのはしくれなんで、forkくらいは使うけど、
>>545のはGPUを使うときの独自の流儀の話をしてんじゃないの？ってこと。

551:・∀・）っ-○◎●
07/04/18 23:24:58
ちなみにGPUにプロセスの概念はない。GPU上でOSは動かないだろ。

552:・∀・）っ-○◎●
07/04/18 23:32:44
たとえばJPEGの量子化なんかだと、除算値を定数化できれば大幅に高速化できるわけで。
でもコンパイル時には不定なわけで。
でも除算値毎にEXE作ってたらアホらしいから、普通のCPUだと、動的に命令コード生成したり
する。一般人はこんな面倒なことやらないけど、トップガンの常套手段ね。

でもGPUだとそういうことできないから（CPU側でやれば可能かも）
モジュールを複数作ってパラメータにあったのをロードすると。
そんだけの話でしょう。

553:デフォルトの名無しさん
07/04/18 23:59:05
>>552
いちおう理解できたようだ。感謝。
でも>>547は関係ない話だろう。

554:デフォルトの名無しさん
07/04/19 00:13:38
スレが伸びてると思ったら糞団子かよ

555:デフォルトの名無しさん
07/04/19 00:46:37
トップガン(藁

556:デフォルトの名無しさん
07/04/19 00:50:39
分岐コストが高いなら、両方のルートを計算すればいいだけ。
そういう頭の使い方ができない香具師にはGPUを使いこなすのは難しい。

557:デフォルトの名無しさん
07/04/19 01:04:55
つまり下手鉄砲も数打ちゃ当たる？

558:・∀・）っ-○◎●
07/04/19 01:07:57
弾の数が勿体ない。
スループット落ちるじゃないか。

559:デフォルトの名無しさん
07/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に対する自信を見せた。

URLﾘﾝｸ(journal.mycom.co.jp)

560:・∀・）っ-○◎●
07/04/19 01:12:33
早い話がIntel版Cellだな

561:デフォルトの名無しさん
07/04/19 01:19:22
さすが団子ﾁｭｰさん＾＾

562:デフォルトの名無しさん
07/04/19 10:22:20
ダンゴの一言は重みがあるな

563:デフォルトの名無しさん
07/04/19 20:33:33
GPUで出来ることの幅が広がるのはうれしいけど
本来のGPU的の使用には向かなくなってるのかな？
例えば、これからコアもっとリッチに、粒度をもっと細かくしていくと
行き着く先はCell+だよね。で現状CellはGPUの代わりは出来ていない。

564:デフォルトの名無しさん
07/04/19 20:42:46
上の奴は何を言ってるんだ?
もっと勉強してこいと言いたい。

565:デフォルトの名無しさん
07/04/19 20:51:19
今のGPUがやっているような、パラレリズムの特徴を利用してメモリアクセスの
レイテンシーを隠ぺいできるような仕組みがないと、PUの利用効率が悪くなって
大きなファクターでの性能向上は難しいような気がする。

個人的には David Williams 氏のいうことはあまり信用できないな。

次ページ