07/02/20 15:34:52
>>347
お、動いたら感想よろしく。
351:デフォルトの名無しさん
07/02/20 17:10:05
昨日か一昨日くらいにCUDAコンパイラのパブリックベータが始まった。
誰でも落とせるようになったはず
352:347
07/02/21 12:08:21
情報THXです！
でも、うちx64のVistaマシンなので…orz
まだ開発環境は32bit版しか出てないみたいで、ドライバに強く依存するらしく32bitアプリ側からは64bitドライバが見えないようです。
ドライバが入ってないというメッセージが出て、インストールすら出来ない…orz
早く64bitバージョンでませんかねぇ・・・。
353:デフォルトの名無しさん
07/02/21 13:34:37
>>352
英語版のnVIDIAのサイトからGO!
日本語版のサイトのvistaドライバのページは何故かNot Fount
多分最新のドライバ入れれば、有効になると思われ。
Vistaでは試してないけど、XPのx64でCUDA SDKは使えたから・・・(ただしグラボがGF66なのでインストールしただけｗ)
354:デフォルトの名無しさん
07/02/21 14:51:53
Supports Linux and Windows XP operating systems
とかいてあるからVistaはまだ無理なのかも
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 氏のいうことはあまり信用できないな。
566:デフォルトの名無しさん
07/04/19 21:34:20
>>556-558
ItaniumやXbox360 GPUのプレディケーションって奴では？
XBOX360なら48 shader
分岐待ちしてるのと、演算にリソース使うの
どっちが良いんだろう？
まぁ、R520系のように分岐ユニット（？）をつければ良いのかな・
567:デフォルトの名無しさん
07/04/19 21:42:32
G70系のように比較的大きい粒度だと小さいレジスタですんでたのが
R520系では小さい粒度のためG70系に比して大きいレジスタを搭載している。
NVIDIAはどうか知らないがAMDは更に小さくするんじゃないかな？粒度
568:536
07/04/20 18:36:53
取り敢えずCUDAのサンプルと同等の処理をgccでコンパイルして較べてみた。
3.4GHzXeonで66ms掛かる処理が8800GTXで0.23ms。
#サンプルはsimpleTexture。
こういうサンプルだと確かに速いね。
#いかん、Xeonの方はsse使ってないやw
569:536
07/04/20 19:28:19
で、Xeonでsse使ったら(ベクタ化してないけど)44msにはなった。
でも、200倍近く。これなら取り敢えず、実験でお金が貰えそうだw
570:デフォルトの名無しさん
07/04/21 05:44:09
>>568
ども。
Xeon Quad DPのコア当たり性能が仮にNetburst Xeon 3.4GHzの倍だとしても、
x 2 x 4 x 2 でもまだ、10倍以上か。
double演算エミュレーションのサンプルみたいのはあるのかな？
571:デフォルトの名無しさん
07/04/21 06:18:08
コード示さんとわからん。
572:536
07/04/21 08:21:24
GPU側はCUDAのサンプル、CPU側はそれを移植したもの。
どうしても見せろってことなら後で載せるよ。
#どうせだからこのPCでもコンパイルしてタイムを計ってみるか。
573:536
07/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:デフォルトの名無しさん
07/04/23 19:42:27
>>573
おいおい、そのCPU用のコードはいくらなんでも冗談だろ？
575:536
07/04/23 19:49:31
>>574
何か問題でも?
getData()はCUDAのサンプルの出力からの類推ででっち上げたから問題があるとしたらその辺かな?
transform()に関してはCUDAのサンプルのロジックそのままだからそれについては何もコメントできないけど。
576:デフォルトの名無しさん
07/04/23 20:21:04
>>575
CUDAで実行した場合に transformKernel() 内のすべてのロジックを
各画素について糞真面目に計算してるとでも思ってるのか？
そのCPUコードじゃGPUと対等じゃないよ。
577:デフォルトの名無しさん
07/04/23 20:37:55
普通に考えて、width, height, thetaのみに依存する（入力ストリーム全体に対して不変の）
ロジックは先に計算してGPUの定数レジスタに格納する、くらいの最適化はしてるだろうね。
DirectXのHLSLシェーダをアセンブリにコンパイルしたときのpreshaderみたいに。
578:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/04/23 21:58:44
gcc、それくらいの最適化は任せられなかったっけ？
気持ちが悪いから、可読性が落ちないなら、速い方にするけど。
>>573にもう一度回してもらうのが一番手っ取り早いか。
580:デフォルトの名無しさん
07/04/23 22:24:02
>>579
sinf, cosfは外部のライブラリ関数で、Cコンパイラはその処理内容を知る立場にないから、
for文の中にある関数の呼び出し回数を勝手に減らすような最適化は普通しないと思うよ。
インライン関数だったらそういう最適かも可能だけど。
581:536
07/04/23 23:00:41
うい、流れは理解した。
明日にでも試してみる。
>>580
gccはsinf()はインライン展開しないようだね。
このテストじゃないけれど、iccはsincos同時に求める専用関数に置き換えるくらいのことはする。
iccの方は現在手元にないから水曜日になるけどテストしてみま。
582:デフォルトの名無しさん
07/04/23 23:33:10
>>581
投げてばっかりで悪いけど、よろしく。
8600でも買おうかと思ってたけど、unitが半分のはずが1/4しかないんでちょっと萎えてる状態。
583:デフォルトの名無しさん
07/04/24 06:46:36
CUDAって、Vistaにまだ対応してないよね？
あと、XPはx64にも対応してないけど、これってネイティブな64bitモードで動かないってだけ？
俺メインマシンがVistaとXP x64とのデュアルブートだから、CUDAの導入に踏み切れない・・・。
対応してるなら、早速グラボ買って来るんだが・・・
584:デフォルトの名無しさん
07/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
07/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
07/04/24 18:31:54
>>583
この辺は参考にならない?
URLﾘﾝｸ(forums.nvidia.com)
587:デフォルトの名無しさん
07/04/24 20:27:32
>>585
どうもです。10msそこそこってのはCeleron1.2GHzですか？
getData（テクスチャフェッチ）はGPUが非常に得意な部分だからそこでかなり差が付いてるかもね。
588:デフォルトの名無しさん
07/04/24 23:38:13
Celeron 1.2GHzならメモリが遅過ぎでしょう。
あとCeleronの場合、整数だけで座標を演算した方が速いと思う。
それにしても比較するのは酷な環境。
589:デフォルトの名無しさん
07/04/24 23:45:07
ところで時間計測はどのように行ってます？
590:536
07/04/24 23:49:26
いや、10msはXeon3.4GHz(>568-569参照)。
そう言えば、Celeronの速度は忘れてた。
591:588
07/04/24 23:55:05
あとこれCPUにもよるだろうけど、繰り返さなくていいなら
if ( unsigned(width-1-ix) < width && unsigned(height-1-iy) < height )
return data[iy * width + ix];
else
return 0.0f;
の方が速いよな。
本当はループの外で判定出来るからもっと速くなるけど
とりあえずこの程度は予測分岐で賄えるだろうと怠慢。
592:デフォルトの名無しさん
07/04/24 23:56:58
何言ってるか分りにくいか。
ix %= width
みたいな除算が重たいから取り除くって話ね。
593:536
07/04/25 00:41:07
>>591-592
あー、それは敢えてCUDAサンプルの出力を見て合わせた。
最初は条件分岐でやったけど、確か大して時間変わらなかったように記憶している。
>>589
CUDAのサンプルの時間測定をそのまま使ってたんで、今調べたらgettimeofday()だった。
594:588
07/04/25 03:13:43
積に比べれば遥かに重いんだけど、流石にXeonでは誤差か。
けどGPUがサイズを二の累乗に限定していたのはこういうところにもあるはずで、
例えばwidthとheightが二の累乗に限定出来れば
ix %= width;
を
ix &= (width-1);
にして除算が排除出来る。
Celeronではかなり効果あるんじゃないかなあ。
595:デフォルトの名無しさん
07/04/27 00:55:48
上の方でも条件分岐が必要な処理に関して質問があがってたのですが
イマイチ、ぴんと来ないので質問させてください。
遂に昨日8シリーズを手に入れたのですが、とりあえずは簡単に使えるBrookGPUでDCTを実装して試そうと思ったんです。
で、DCTで係数kiとして
kiの値は
ki=1/√2 (i=0)
ki=1 (i≠0)
って処理がありますが、
具体的には、こういう部分はどのように書けばいいのでしょうか？
ifが使えないとなると、せっかくforループを使わずにGPUに投げられるのに、ループ回してCPUでiの値を確認しなくてはいけなくなると思うんですが・・・
初歩的な質問で申し訳ないのですが、この辺具体的な話がイメージ出来なくて困っています。
596:デフォルトの名無しさん
07/04/27 01:01:48
つか、ゲッパチ買ってきたんだけどCUDA糞じゃん
普通の文字列処理とかできねーじゃん。汎用GPUプログラミングとかいっておいて
なーんもできねーじゃんゴミだだまされた。明日nvidiaに電凸しよう。
597:デフォルトの名無しさん
07/04/27 01:26:43
>>595のは、ちょっと例が悪かったです。
ごめんなさい(汗
ただ、他にifを使う部分は、やっぱり数式に直すしかないんですかね？
598:デフォルトの名無しさん
07/04/27 01:42:26
>>597
悪いってレベルじゃねぇぞｗ
で、結局そこはCPU側に出すか
もしくは数式的に直せるのであればそうするしかないな。
CUDAは知らん。
>>596
はいはい。
使いこなせないだけですね。
文字列処理って何ですか？
文字列を数値化すれば、形態素解析であろうが、文字列マッチングであろうが
置換であろうが、余裕ですよ。
599:デフォルトの名無しさん
07/04/27 06:51:15
>kiの値は
>ki=1/√2 (i=0)
>ki=1 (i≠0)
単純になら、ki=1-(1-1/√2)*(i==0)
i==0の時だけループからはずすのも手だし、
テクスチャを係数テーブルにするほうが普通じゃ。
600:デフォルトの名無しさん
07/04/27 07:50:49
>>597
効率がどうなるかは知らんが、そういう用途ならCUDAの方が楽じゃない?
601:デフォルトの名無しさん
07/04/27 09:50:02
BrookGPUで各ユニットで共通の変数を利用したい場合ってどうすればいいのでしょうか？
例えば、
for(int i=0; i<128; i++)
out[i]=i;
や
for(int i=0; i<128; i++)
out[i]=out[i]+5;
このようなパターンです。
602:デフォルトの名無しさん
07/04/27 09:55:56
>>601
まず、後者の場合、reduceを使う
void reduce sum(reduce float res<>){
res=res+5;
}
こんな感じ
前者の場合。
イテレーターを使うんだと思うんだけど、ちょっと俺にもわからん。
603:602
07/04/27 09:57:59
って、うわ・・・
後者も間違ってる。。sumの問題じゃなかったのね。
すまん。
その場合普通に
kernel void (out float o<>){
o=o+5;
}
でいいじゃん。
604:デフォルトの名無しさん
07/04/27 10:35:23
>>601
void reduce func(reduce float i<>, out float o<>){
o=i;
i=i+1.0;
}
後者は何が言いたいのかわからん。
普通で
605:デフォルトの名無しさん
07/04/29 00:19:43
お前らCUDAやりなさい。
ところで、CgがあるのにCUDAを出す意義って？
nVIDIAは言語の乱立を自重汁
606:デフォルトの名無しさん
07/04/29 00:46:51
Cgはシェーダー言語。HLSLのベースになった時点であるいていど成功。
CUDAはプログラミング言語。
607:デフォルトの名無しさん
07/04/29 00:49:41
>>606
はあプログラミング言語ねえ
608:デフォルトの名無しさん
07/05/02 03:02:44
>>595
conditional move とか select とか、そういう類の命令を持つ CPU とか GPU があるのね。
だから３項演算子とか>599のようなことで問題なし。
そんなことを気にするよりも、まずは動くものを作ってこことかどっかに投げないと、何が聞きたいのかわからんというか、何を答えても的外れになりそうな気分になって答えられない。
609:デフォルトの名無しさん
07/05/02 13:22:28
BrookGPUって、intは使えないよね？
データがint型で、ストリームに送る前にキャストしても返ってくる値がおかしいから困る・・・。
こういうのってどうすればいいんだ？
610:デフォルトの名無しさん
07/05/03 08:20:49
桁落ちが原因だろ。＞値がおかしくなる。
落ちない範囲に収めるor諦める
611:デフォルトの名無しさん
07/05/03 18:01:20
コーヒーブレイク
URLﾘﾝｸ(www.forum-3dcenter.org)
URLﾘﾝｸ(www.forum-3dcenter.org)
R600のリークスライドなんですが、SuperScalar,SIMD,VLIW等
並列実行のキーワードが並んでます。
詳しい人、どうなんでしょうこのGPU。
612:デフォルトの名無しさん
07/05/04 00:36:29
電気馬鹿食いDQNカードだぞ？
613:デフォルトの名無しさん
07/05/04 13:22:12
これからGPGPUに入門しようと思って、手始めに3Kのテキストデータの文字列に+1するだけの単純コードで実験してみた。
BrookGPUが簡単だったので、こいつを使った。
kernel void func(float i<>, out float o<>){
o=i+1.0;
}
//streamRead(in1,inc1);
//func(in1,in1);
//streamWrite(in1,inc1);
for(i=0; i<2048;i++){
inc1[i]=inc1[i]+1;
}
//GPU:18秒
//CPU:9秒
…全然だめじゃん。GPGPUって
環境は、Athlon64 X2 4200+,GF8600GTS
これより式を複雑にしたら、もっとスーパースカラーなCPUがより有利になるでしょ。
GPUは、和積演算だけは、同時実行出来るんだっけ？
614:デフォルトの名無しさん
07/05/04 13:36:48
>>613
それは計算量少なすぎ。
明らか転送のネックの方が大きいだろｗ
615:613
07/05/04 13:40:38
>>614
CPUの時も、streamReadとstreamWriteだけやるようにしてみました。
それでもCPU:16秒でした^^;
616:デフォルトの名無しさん
07/05/04 14:10:15
>>615
それはつまり、GPUの処理時間は2秒ということだね。
……だからなに?
617:デフォルトの名無しさん
07/05/04 14:20:32
転送時間を差し引いても、演算速度がCPUよりGPUの方が遅いって話だろ
そんなの冷静に評価してるやつはみんな言ってるじゃん
たまに『GPUはCPUの数十倍』とか夢見たいな話してる脳内お花畑さんが居るがｗ
618:デフォルトの名無しさん
07/05/04 14:49:27
BrookGPUはデバッカはついてるのかな？
ブレークポイント設定してステップ実行とか出来るの？
今、主にHLSLで組んでいるんだけど
GPUデバッグがやりずらくて困ってるんけど
同じかな？
619:デフォルトの名無しさん
07/05/04 15:11:56
>>618
BrookGPUって、単なるコンバータだよ。
結局Cgのデバッグ作業になるが・・・。
Cgは、nVIDIAがそういうツールを提供してる。
620:デフォルトの名無しさん
07/05/04 15:39:12
>>613
大量にデータを送り込めば数で勝るGPUは高速
しかし、BrookGPUのstreamは2048くらいしか要素を確保出来ない。
その程度では、GPUコア全てを使い切れないので、CPUの方が高速。
これの意味はもう分かるよな？
さっさと、CUDAでも覚えるんだ。
621:デフォルトの名無しさん
07/05/04 15:44:08
BrookGPUなんて海外じゃもう糞確定してるって見方が大半だよ。GPGPUで
最先端いってるやつらに、BrookGPUwって感じで笑われるしなぁ。
622:デフォルトの名無しさん
07/05/04 15:50:31
BrookGPUはお遊び言語なのは知ってるけど
じゃあ、何が良い言語なんだ？
CUDA出る前からGPUは騒がれてたんだから、CUDA以前から扱いにくくともCPUよりちゃんと速度が出るのはあるんだろうね？
SHとか使ったが、あれは、ちょっとなぁ・・・
623:デフォルトの名無しさん
07/05/04 15:58:54
実際に海外の優秀なやつはら暇つぶし程度にしかいまのところやってないよ
速度云々は別にどうでもいいって感じだよ。ただできましたって感じだよね
624:デフォルトの名無しさん
07/05/04 15:59:51
…おい
誰も何でつっこまんの？
行列演算させずに、１次元計算させてどうするんだ。
まずは、GPUに計算させる前に、Gridにデータを落としこむべきだろ。
Gridにデータを落とし込むような価値の無い計算ならば、するな。
本当にレベル低いな、おい…
625:デフォルトの名無しさん
07/05/04 16:03:56
>>624
何マジレスしてるんだよw？
626:デフォルトの名無しさん
07/05/04 16:17:52
行列に落とし込むくらいだったら、CPUに演算させた方が・・・ｗ
たまに出てくるGPGPUで有効な例とする
for(i=0;i<SIZE_N;i++){
out[i]=in[i]+1;
}
こういう処理を否定してちゃあ、世間のジャーナリストは嘘つきだなｗ
627:デフォルトの名無しさん
07/05/04 18:55:00
URLﾘﾝｸ(mumei24.run.buttobi.net)
DLパス:gpu
トーラスをランバートのシェーディング（ｃｇ）で表示するだけのプログラムなのですが
どうも動かないです。OPENGLです。
誰か助けてください。
628:デフォルトの名無しさん
07/05/06 00:11:23
>>611
リンク先は流し読みしただけだけど。
SuperScalarやらSIMDやらは今更な感じがする。
今までってSuperScalarじゃなかったんだっけ？
少なくともSIMDだったよな。
VLIWはちょっと気になるな。
GPUに既存のCPUのアーキテクチャでやられたヤツを色々持ち込むのはいいんだけど、
効率（性能）が向上するかは未知数だし、
GPGPU的に使いやすいかは別問題だったりするし、
どうなるんだろうね。
と、思ったことを適当に書いておく。参考にならんな。
629:デフォルトの名無しさん
07/05/07 01:27:32
GPUはSPMDだろ。
まぁCUDAで言えばWarpはSIMDだが、いずれにしてもGridレベルのSPMD。
630:デフォルトの名無しさん
07/05/09 18:24:24
627ですが…反応ないですか
631:デフォルトの名無しさん
07/05/09 22:08:54
>>630
激しくスレ違い。
ここはコンピュータグラフィックス関連のスレじゃないよ。
632:デフォルトの名無しさん
07/05/10 19:04:59
…スレ違いなんですか
他スレの方が汎用コンピューティングとあったのでこちらで聞いたのですが
633:デフォルトの名無しさん
07/05/10 22:31:23
GPUスレと勘違いしてないか？
GPGPUスレだぞ。汎用的にGPUを使おうってスレで、本来のグラフィックス処理がらみはスレ違い。
634:デフォルトの名無しさん
07/05/11 00:05:44
OpenGLスレとかその辺かな。
635:デフォルトの名無しさん
07/05/13 22:58:51
このスレッドの人ってあかでみっくぽすとの人が多いのかな
636:デフォルトの名無しさん
07/05/14 01:27:35
中途半端に賢い人が多いんだよ
637:デフォルトの名無しさん
07/05/15 07:05:44
>>611
URLﾘﾝｸ(techreport.com)
float MAD serial以外は、概ね速い。
638:デフォルトの名無しさん
07/05/17 02:43:02
最近シェーダを学び始めた者です。
調べた結果、自分の中で結論出たようなものなのですが、
最後の確認として質問させてください。
シェーダで、32bit整数を扱うことは可能でしょうか？（ベクトル型で）
もし可能であれば、シェーダモデルやベンダ拡張等問いません。
GPGPUな目的で学習していますので、このスレで質問させて頂きました。
よろしければご教授お願いします。
639:デフォルトの名無しさん
07/05/18 11:28:03
Cgでint4が出来れば扱えるんじゃない
640:デフォルトの名無しさん
07/05/18 22:35:37
CUDAは、さっさとXP x64とVistaに対応するべきだ。
俺、この2つのデュアルブートだから、せっかく8シリーズ買ったのに・・・。
これのために買ったのになぁ・・・orz
641:デフォルトの名無しさん
07/05/19 00:02:18
>>639
ありがとうございます。
試してみます。
642:デフォルトの名無しさん
07/05/19 21:48:38
ATI RADEON X800 XTで
Ｃｇの中でforやらbreakが使えないみたいなエラーが出たんだけど
これってどこで確かめれるの？
643:デフォルトの名無しさん
07/05/19 23:25:09
>>640
ゲフォ8800なんて買う変態がXP 32bitにするわけがないからなぁ。
本当に本腰入れたいんならVista&XP×32bit&64bit全部入りだろうけど。
とりあえずコンパイルしてエミュで動かしてみたが速度とかどうってより
operatorやらtemplateやらが通るのに吹いた
644:デフォルトの名無しさん
07/05/20 01:18:59
>>643
CUDAのこと? あれ、だってコンパイルにはgcc使ってるもの。
645:デフォルトの名無しさん
07/05/20 14:17:03
あーそりゃそうだな
646:デフォルトの名無しさん
07/05/26 21:56:13
ねねCUDAで
if(input == 'a'){
...
}
else if( input == 'b'){
...
}
て処理書きたいんだけどどうやって書けばいいか教えてください
647:デフォルトの名無しさん
07/05/26 21:58:16
無理
648:デフォルトの名無しさん
07/05/26 22:57:06
なんだとぉ
ふざけるんじゃねーよ教えてくれよマジ切れするぞ
ゆとり世代は沸点低いんだよ忘れたのか？
649:デフォルトの名無しさん
07/05/26 23:35:02
＞ゆとり世代は沸点低いんだよ忘れたのか？
ちょっと地面に穴掘って埋まってきたら?
圧力掛かると沸点高くなるっしょ。
650:デフォルトの名無しさん
07/05/26 23:56:46
>>649
なめてんのかコラいいかげんにさっさと教えろよ
651:デフォルトの名無しさん
07/05/27 00:00:20
マジレスしてやるよ
CUDA SDKにはエミュついてるから、自分で試しヤガれ
コンチクショー
652:デフォルトの名無しさん
07/05/27 00:23:39
だから無理だって言ってるだろ。
GPUには、条件分岐するキーワードは無い。
予めCで分岐してから、各処理を呼び出すしかない。
653:デフォルトの名無しさん
07/05/27 00:38:12
じゃあ
abcdefjを128bitのhexとかに予め変換してとか小細工しても
strstr()なんかを作ることは無理なのか？
654:デフォルトの名無しさん
07/05/27 11:33:06
>>653
もちっと、じぶんのあたまでよくかんがえてからしつもんしよう。
ぺたっ （もうすこしがんばりましょう）
655:デフォルトの名無しさん
07/05/27 11:34:31
>>654
わかんねーからきいてるんだろうが
こちとら時間ねーだんよささっと情報晒せ
656:デフォルトの名無しさん
07/05/27 12:11:24
時間ないなら諦めたら?
657:デフォルトの名無しさん
07/05/27 12:12:27
>>656
悪かった取り乱してしまった。すまいと反省している。
ね？ね？ヒントでいいかなんか情報くださないな
658:デフォルトの名無しさん
07/05/27 12:56:58
なかなか釣れませんね
659:デフォルトの名無しさん
07/05/29 01:34:39
あのー誰か教えてよぉもう2日もがんばってるけど
できないよ
660:デフォルトの名無しさん
07/05/30 08:32:29
>>659
そもそもなぜGPUでstring処理を行いたいのでしょうか？？
いくらCUDAでGPUを汎用プログラミング用途に使えるようになったと
言っても、やはりGPUが得意とするのは大量の単精度浮動小数点データ
に対する演算だと思うのですが。
661:デフォルトの名無しさん
07/05/30 13:59:24
余計なお世話だろ
662:デフォルトの名無しさん
07/05/30 14:36:51
すみませんでした
663:デフォルトの名無しさん
07/05/31 00:38:24
>>660
1024bitとかまぁもっと長いbit列の処理をさせた場合
現状どの程度優位（もしくは無意味か）データが採りたいんですよ。
だれか具体的にいくらって数値出していただけるならうれしいのですが
そんなもん自分でやれっていわれるのはまちがいないのでCUDAで
どうやって作ればいいのかちょっと聞いてみたかったんですよ。
未だにできないでうーむってうなってますよw
664:デフォルトの名無しさん
07/05/31 01:00:22
>>663
CUDA SDK付属のエミュでまずは作れ。
そしたら実機で回してみせるよ。
665:デフォルトの名無しさん
07/05/31 01:02:10
>>663
CUDA SDK付属のエミュでまずは作れ。
あうあう？うーんうーん？エミュってどこにあるの
それいってくださいよーもー
666:デフォルトの名無しさん
07/05/31 01:08:06
まずはダウソしてインスコしてビルド汁
話はそれからだ
URLﾘﾝｸ(developer.nvidia.com)
667:デフォルトの名無しさん
07/05/31 01:22:09
64bitじゃ無理じゃーん
どうしろっていうんだorz
668:デフォルトの名無しさん
07/05/31 02:35:44
俺もXP x64とVistaのデュアルブートだから無理だったんだよな・・・prz
669:デフォルトの名無しさん
07/05/31 07:54:50
>>667
欲張って64bitのマシンを買うからだ
670:デフォルトの名無しさん
07/05/31 09:40:38
大丈夫、漏れは64bit機で32bitRedHat入れている。
#勿論、CUDAは問題なく動く。
671:デフォルトの名無しさん
07/05/31 23:27:42
URLﾘﾝｸ(grape.astron.s.u-tokyo.ac.jp)
URLﾘﾝｸ(jp.arxiv.org)
実用の計算で150Gflopsなら立派なもんだね。
負け惜しみで発熱に文句付けてるけど、
1年半すればミドルレンジ、3年後にはノースのおまけになるのがGPU。
残念ながらGrapeはお終い。
672:デフォルトの名無しさん
07/05/31 23:32:08
演算アクセラレータボードを作っている会社も危ない状況ですね。
某社のボードなんか100万とかする挙句に開発環境がそれの倍以上だもんなぁ。
673:デフォルトの名無しさん
07/05/31 23:52:47
ねぇねぇubuntu x64環境でどうやってCUDAするの？
toolとcudaいれたけどVideoのドライバがインスコできない
なんで？
674:デフォルトの名無しさん
07/05/31 23:54:34
ERROR: this .run file is intended for the
Linux-x86 platform, but you appear to be
running on Linux-x86_64. Aborting installation.
とか出るのですが原因が判りません。
675:デフォルトの名無しさん
07/05/31 23:59:43
>>674
日本語の参考書が出るまで、あんたにはCUDAは使えない。
日本語の参考書が出たらまたどうぞ。
676:デフォルトの名無しさん
07/06/01 00:26:47
>>671
いやさすがに3年後でmGPUにはならないでしょ…
677:デフォルトの名無しさん
07/06/01 01:30:32
>>674
エラーメッセージにダメな原因がはっきりと書いてあると言うのに、
これでも文章の意味が分かりませんか。はぁーーーーー。
# 日本の英語教育がよくないのか、それとも674氏特有の問題なのか。
ネイティブスピーカーが何を言っているのかなかなか分からない私で
すが、文字として書かれていれば、これくらいの文章は普通に理解で
きないものですかねぇ。
なんだかんだ言っても実質的に世界標準言語は英語なわけで、GPGPU
とか言い出す前に、まずは中学・高校レベルの英文は読めるようになる
必要があると思います。
# それができないなら、675氏の言う通りだと思います。
678:デフォルトの名無しさん
07/06/01 01:34:26
いや、日本語の参考書が出てもダメでしょ。
679:デフォルトの名無しさん
07/06/01 03:14:22
>>671のサイトのはGRAPEの製作者のところなので
自分たちのシステムの優位性をアピールしたいんだろうが
その人たちですら、性能面でのGPUの優位性はもはやみとめざるを得ないと言う事だろうな。
しかしまぁ、CUDAの実行環境の話もそうだけど
さっさとGPGPUの環境整えてくれ。Vistaやx64非対応ってやる気あんのかと
680:デフォルトの名無しさん
07/06/01 03:16:42
一般人は、エラーメッセージの内容を信用しないって所があるんじゃね？
多分、そのメッセージが日本語でも同じ。
理由は、Windowsのような、全くもって何の解決にもなってないようなエラーを吐く環境に鳴れたせいかと。
アプリケーションの強制終了の時のエラーダンプを、アプリケーションの作者に送っても殆ど無意味だし。
ブルースクリーンのエラーメッセージをコンピュータのサポートに送っても無意味だからなぁ
681:デフォルトの名無しさん
07/06/01 23:10:00
おいハードディスク買ってきたから32bitOS入れるから
教えてくれるよね？
682:デフォルトの名無しさん
07/06/02 14:26:11
環境は今からそろえるつもりとして、はじめるとしたらCUDAとCgどちらがいいですか？
683:デフォルトの名無しさん
07/06/02 14:33:49
両方やれば?
684:デフォルトの名無しさん
07/06/02 15:37:28
ねぇねぇねぇ
CUDAで
NVIDIA: could not open the device file /dev/nvidiactl (No such device or address).
とかでるんだけどさ、なんで？
NVIDIA-Linux-x86-1.0-9751-pkg1.tar.gzこれいれたんだけどさ。
いまカードはGeforce7950GTXなんだけどエミュで動かせるって聞いたけど違うのかな？
カード走って買ってこないとダメ？
685:デフォルトの名無しさん
07/06/02 16:17:50
GPUチップを認識できてないとそうなった希ガス。
nvcc動かすだけなら大丈夫だと思うけど。
686:デフォルトの名無しさん
07/06/03 02:02:23
エミュ用のディレクトリのを実行した？
687:デフォルトの名無しさん
07/06/03 12:43:44
サンプル動いたぉ
688:おしえてちゃん
07/06/03 14:27:02
gpgpu志向のプログラム作ろうとしてます。
ですがいきなり分からないことが、出てきました。
点を二つ作り、その点の大きさをgl_PointSizeを使って
大きくしたら、点が重なりました。その重なった部分の混合色は
どのようにつくられるのですか？
1,(vertex + fragment シェーダでの処理を一単位と考えて)
二度シェーダプログラムを呼んで色の混合を作る。
2,（上と同じ考えで）一度で処理する。
3,そのほか
同じカーネルに、複数の色を叩き込むということなので、
その色の混合処理の方法がわからないのです。
一体どれなんでしょうか？
689:デフォルトの名無しさん
07/06/03 18:14:52
あまりGPGPU指向の話じゃないねぇ
690:デフォルトの名無しさん
07/06/03 19:24:42
ちょいCUDAで質問
とりあえずCUDAの手順として
デバイス初期化
メモリ初期化（host,dev)
計算
終了処理
という感じになっているが、なんでkernelの関数呼び出す時こんな
キモい呼び出しになってるの？すっげーキモくて違和感ありありなんだが
testKernel<<< grid, threads, mem_size >>>(d_idata, d_odata);
こんなアフォな呼び出ししたくねーよw
691:デフォルトの名無しさん
07/06/03 19:55:22
その呼び出しのどの部分がキモいのか具体的にお願いします。
692:デフォルトの名無しさん
07/06/03 20:43:48
逆にそれだけで済んでしまうところが肝なんだが。
693:デフォルトの名無しさん
07/06/03 21:10:34
今エミュだけだからよーわからんのだけど
__device__と__global__って再帰呼び出し禁止だけど
２つの関数交互に呼ぶのはOKなのかなぁ？
エミュだとOKに見えるのだが実機だと動かなそうだがうーん
694:デフォルトの名無しさん
07/06/03 22:12:09
ソース上げてくれたらテストするよ。
695:デフォルトの名無しさん
07/06/03 23:13:18
__device__ hogeから__device__hoge1を呼び出せないのは痛いなぁ。
inline展開できない場合は処理不可能なのかぁうーむ。これにはちと
まいったな
696:デフォルトの名無しさん
07/06/07 23:58:14
なぁなぁ
Geforce8800GTXでCUDAするとき
sharedメモリいくらになるの？
各ブロックはいくらになるの？
その辺の情報がいまいちよーわからんのだが
697:デフォルトの名無しさん
07/06/08 07:41:27
CUDAが未だにVistaやx64に対応できないのは何か理由があんの？
もうかなり経つよね。
698:デフォルトの名無しさん
07/06/11 00:43:57
GPGPU完全死亡
URLﾘﾝｸ(pc.watch.impress.co.jp)
699:デフォルトの名無しさん
07/06/11 02:23:44
>>698
こんなのセルと大してかわらへん
並列度が低すぎる
700:・∀・）っ-○◎●
07/06/11 03:08:05
IA命令セットと互換ってのがみそだろ。
どうせSSEだろうけど。
701:デフォルトの名無しさん
07/06/11 07:00:21
で、どれだけ広まるのよ？一般に。
GPU以上に広まる可能性はあるのけ？
702:・∀・）っ-○◎●
07/06/11 07:04:13
そもそもGPUじゃないし
ただGPUで出来るGeneral Processingのおいしい部分は全部持ってっちゃうと思う。
x86のコードがそのまま動く意味は大きい。
703:デフォルトの名無しさん
07/06/11 07:04:20
しかも2009年まで出てこなんじゃ
インテルお得意のキャンセルされるかもしれないしね
704:デフォルトの名無しさん
07/06/11 07:22:53
てことは、一般には浸透しない可能性の方が大きいな。
Intelの資料にはLarrabeeだけで4CPU(?)構成の絵があったりするから
OSもそのまま走るのかも？
Tera Tera Teraには下記の記述がある。
LARRABEE ??TERATERA--SCALE SOLUTIONSOLUTION
Discrete high end GPU on general purpose platform
TeraFlopsof fully programmable performance
GPU ->16 cores @ ~2.0GHz, >150W
JPEG textures, physics acceleration, anti-aliasing, enhanced AI, Ray Tracing etc.
705:デフォルトの名無しさん
07/06/11 18:39:47
CPUコアがいくら増えたところでGPUの性能が落ちる訳じゃないし。
706:デフォルトの名無しさん
07/06/11 19:57:52
GPGPUよ、短い命であった。
707:デフォルトの名無しさん
07/06/11 22:43:50
そう、CPUのコアが増えたところで
GPGPUを使えば更に速くなるわけで、どっちか切り捨てるとかそういうものじゃないでしょ。
使えるものは使うと速くなるんだから。この場合は だけどｗ
708:デフォルトの名無しさん
07/06/11 23:07:43
例えば今まで
CPU10 + GPU25 = 35
で処理できていたことが
CPU20 + GPU25 = 45
で処理できるならそれはいい。
なんで
CPU20 = 20にGPU切り捨てる必要があるんだ
709:デフォルトの名無しさん
07/06/11 23:15:13
しかも、CPUよりはGPUの方が安い罠。
710:デフォルトの名無しさん
07/06/11 23:18:20
30コアのCPUがいきなり一万円台で買えるとは思えないが。
よっぽど一世代前の高級GPUのほうが安く買えるかも。
711:デフォルトの名無しさん
07/06/11 23:41:11
PCI-Expressに挿せる超高速コプロならなんでも売れると思うけどね。
GPUでも糞INTELの石でもなんでもいいけどね
712:デフォルトの名無しさん
07/06/11 23:46:48
そうは言ってもClearSpeedはベンチマークスコア上げるのには
有効だが実用面ではちょっと。
713:デフォルトの名無しさん
07/06/11 23:51:48
あれは期待外れだった。糞高いコンパイラだけで性能出せないんじゃ……ねぇ。
714:デフォルトの名無しさん
07/06/12 07:29:59
「Larrabeeが登場したら、ハイパフォーマンスコンピューティングのベンチマークを
総なめにする可能性がある」とある業界関係者は期待を語る。
Larrabeeのターゲットアプリケーションは、一目見てわかる通り、GPUがGPGPU
でターゲットにし始めている領域と完全に重なる。つまり、LarrabeeはIntelによる
GPGPUの動きに対する回答だ。IntelとGPUベンダーは、ハイパフォーマンスな
浮動小数点演算性能が必要な並列コンピューティングの領域で、真っ向から
ぶつかることになる。
715:デフォルトの名無しさん
07/06/12 14:02:27
LarrabeeはSSL対応レイヤ3スイッチのアクセラレータや
重めのアプリケーションサーバにも向いているような気がする。
値段次第だけど。
716:デフォルトの名無しさん
07/06/15 05:53:00
R600のプログラム形態はSPIのStorm-1に近いかも知れん。
717:デフォルトの名無しさん
07/06/15 06:11:31
URLﾘﾝｸ(journal.mycom.co.jp)
>Stream ProcessorはDPUの他、2つのマイコン(MIPS 4000Ec)を搭載している。
>一つはSystem MIPSと呼んでおり、管理用OSが動作している。
>もう一つはDSP MIPSと呼んでおり、ここでメインアプリケーションが動作し、DPUをマネージメントする。
>並列アーキテクチャを備えたDSPながら、データ処理ロジックの開発は極めて簡単だという。
>アプリケーションはシングルスレッドプログラミングで記述すればよく、複数のレーン間の協調や、
>分散して配置されているメモリのマネジメントについて考慮せずに開発ができるという。
>複数のレーンには同じ命令を配置するので、レーン間で因果関係は出ない(出ないように
>各レーンに割り当てるデータの切り方を考慮する必要がある)。
>また、メモリのマネジメントはコンパイラが自動的に行う。
>このため、マルチスレッドプログラミングが必要なマルチコアDSPよりも、
>アプリケーション開発が楽であるという。しかも、将来の製品展開によってレーンの数が増減した時にも、
>ほぼ同じアプリケーションを使い続けることができるというスケーラビリティを持っているという。
R600の場合command processorとUltra-Threaded Dispatch Processorを二つのMIPS
レーンをShaderと置き換えれば似てるかも知れんね。
ただしR600の場合そのレーンのブロックが4つある。
718:デフォルトの名無しさん
07/06/15 19:06:16
GPGPUでGrapeオワタと思たらメニーコアでGPGPUオワタ
719:デフォルトの名無しさん
07/06/19 20:26:20
GPGPUを使った類似画像検索とか面白そうだが
どこもやってないのかな？
720:デフォルトの名無しさん
07/06/19 21:52:03
画像のパターン検索？ならやってた人がいたと思う
721:デフォルトの名無しさん
07/06/19 23:10:03
まぁそういう用途はGPGPUよりもこういうほうが面白そうだけどスレ違いか
URLﾘﾝｸ(www.k2.t.u-tokyo.ac.jp)
722:・∀・）っ-○◎●
07/06/20 00:57:06
DirectX10でGPUを汎用整数プロセッサとして使うサンプルある？
723:デフォルトの名無しさん
07/06/20 01:19:03
今更R600って、…MSX Turbo-R？
724:部外者('A`)NEET ◆xayimgmixk
07/06/20 11:57:32
あれは、R800だろ。
725:デフォルトの名無しさん
07/06/20 16:44:13
SEGA の体感ゲームだっけ?
726:デフォルトの名無しさん
07/06/21 01:21:12
R3000じゃなかったっけ？
ジオメトリエンジンついてるんだよな？
727:デフォルトの名無しさん
07/06/21 05:39:54
URLﾘﾝｸ(www.dailytech.com)
NVIDIA Announces Tesla General Purpose Processor Platform
URLﾘﾝｸ(pc.watch.impress.co.jp)
NVIDIA、G80ベースのHPC向けGPU「Tesla」
～PCI Expressカードタイプから1Uラックまで
>Teslaのソフトウェアプラットフォームは同社の汎用プログラミングモデル
>「CUDA (Compute Unified Device Architecture)」を利用。
>CUDAにはGPU用のCコンパイラが含まれており、
>Cプログラムに若干の修正を加えるだけで、
>CUDAコンパイラが処理をCPUとGPUに振り分けられる。
728:デフォルトの名無しさん
07/06/21 06:05:30
新しいGPGPU
URLﾘﾝｸ(www.gpucomputing.eu)
URLﾘﾝｸ(www.gpucomputing.eu)
729:ktkr!
07/06/26 11:26:50
ktkr!
Linux
[Download x86, x86-64] CUDA Tookit version 1.0
Windows
[Download] CUDA Tookit version 1.0 for Windows XP (32-bit)
[Download] CUDA SDK version 1.0 for Windows XP (32-bit)
[Download] Windows Display Driver version 162.01 for CUDA Toolkit version 1.0
URLﾘﾝｸ(developer.nvidia.com)
....ちょ、x64とかVistaは?
730:デフォルトの名無しさん
07/06/26 11:50:15
お、情報THX。
早速見てみなくちゃだわ。
731:デフォルトの名無しさん
07/06/26 12:15:19
もう完全にCUDAはやる気ないんじゃない？
うちはXP x64とVistaのデュアルブートだから、完全にアウト。
732:デフォルトの名無しさん
07/06/26 12:17:27
>>731
大丈夫、TesraがあるからCudaは終わらない。
733:デフォルトの名無しさん
07/06/26 14:56:23
こりゃあrapidmindの勝ちかな
734:デフォルトの名無しさん
07/06/26 15:51:35
x86_64 でXPとかビスタなんて使ってるやついたのか？
735:デフォルトの名無しさん
07/06/26 15:54:31
GPGPU用途に限ればLinuxでもいいのか。
CUDAカーネルの5秒制限も払拭されることだし。
736:デフォルトの名無しさん
07/06/26 18:51:32
残念。Larabeeの一人勝ち。
737:デフォルトの名無しさん
07/06/26 19:15:32
CUDAの分野とかから考えて、Vistaとx64を避ける意味がわからん。
特にVistaでは、GPUの仮想化をサポートしてるんで、まさにGPGPUの為の実装みたいなもんなのに・・・
738:デフォルトの名無しさん
07/06/26 20:32:02
Larrabeeは2009-2010登場のでGPU軍勢が散々広まってしまった後だ。
それにGPUは3世代進歩する。
専用ライブラリやランタイムが必要ならISAがx86である意味は薄い。
ましてや32コアを意識してプログラムを組めなんて気の遠くなることは・・・
Larrabeeだけこける。
GPU軍勢の影の総大将がMicrosoftであることは間違いない。
739:デフォルトの名無しさん
07/06/26 20:52:27
>>737
じゃあDirectX10.1が出る頃には対応するんじゃないか
740:デフォルトの名無しさん
07/06/26 21:11:16
PeakStreamを忘れないでください…と思ったけど買収されたしナァ
741:デフォルトの名無しさん
07/06/26 22:39:50
>>738
そんなばかなｗ
GPU軍勢って、nVIDIAだけじゃん。
結局IntelとAMDの天下だよ。
742:デフォルトの名無しさん
07/06/26 22:46:43
ララビー来るまでにTeslaがどれだけ普及するかだなぁ。
取り敢えずCUDA1.0を788GTSで動かすかな。
743:デフォルトの名無しさん
07/06/26 22:58:45
歴史的に見て、このプロセッサ(GPU)をCPUが取り込もうとして
失敗する事は殆ど無い。最終的にCPUに取り込まれるのは必然だと思われ。
性能云々の問題ではすまない。それで住むならMIPSは勝利していたはず。
キーとなるとは、いかにGPUを汎用的に使えるようにするか だ。
GPUのメリットはぶっちゃけてしまえばコア数の差だ。これがもっと汎用的な事が可能なCPUもコアが増えるとなれば大変だ。
向き不向きで確かにGPUの並列化のほうが得策かもしれないが、その差が微々たる物であった時、はじめは部分的に使われても、最終的には全てを飲み込まれてしまう。
CUDAがx64やVistaに対応しないとか、馬鹿な所で詰まってる場合ではない。
今のメリット(先行)を生かさないと・・・。
本当に何を考えてるんだか・・・。
744:デフォルトの名無しさん
07/06/27 01:05:29
先生！
強い電波を観測しますた！！
745:デフォルトの名無しさん
07/06/27 01:39:32
>>743
まー、さっさと対応して欲しいよね。
俺もCPUに取り込まれてx86になったら、人は流れると思う。
特定分野はわからんけど、それならそれでx64に対応しろよ。
何もかもが中途半端
746:デフォルトの名無しさん
07/06/27 01:45:07
長文いってみようか。
性能ではなく普及台数の勝ち負け（プラットフォーム足り得るか）で言えばTeslaは間違いなく「負け」だな。
研究者は独りでｵﾅﾆｰしてﾊｧﾊｧできるだろうが、需要となるキラーアプリが無い限り一般消費者が飛びつくわけがない。
どっかのアホがPPUでレイトレとか風呂敷広げてたが、PPUと同じように普及せず終わる。
（つかそもそもTeslaは一般向けじゃねぇし）
GPUはGPUたる所以のラスタライザ周りのハードワイヤード機能が足枷となって
電力消費の観点からも性能は伸び悩むだろうが、Vistaや3Dゲームで元々GPUは需要があるだけに可能性はある。
ただ現状ではVistaは全く普及していないし、CUDA・CTMとベンダ毎に仕様が異なるから
2010年にLarabeeが登場する頃までは標準化も達成されずグダグダが続くだろう。
ってことでIntelとAMDが談合してx86にデータ並列のストリーム処理命令を新たに追加して終わりだな。
LarabeeでもFusionでも使えるとなれば勝ち決定。
747:デフォルトの名無しさん
07/06/27 02:10:44
と思ったがLarrabeeは全部のコアでフルx86が走るのか。
そうなると>LarabeeでもFusionでも使えるとなれば～は無いな。
748:デフォルトの名無しさん
07/06/27 02:28:25
CPU/MCHどっちにくっついていようがオンボードVGAがシェーダー重視で肥大化して
いったら、逆にS3（VIA）その他の弱小グラフィックスが再び脚光を浴びる。
（PCIeカードの）GPGPUは大学の研究室/個人レベルで使われるだろうが、それで終わる。
チップ自体の価格は大量生産を背景に競争力を持てるが、プログラミングコスト、電力
コストを考えると中～大規模案件では採用されない。
Larrabeeは詳細不明、リリース次期から逆算すると現時点でテープアウトしてなさそう。
後藤記事によると「“練習版”、本格的な製品とは言えない」(業界関係者)。とのことで、
実用化への道は長い。
5年後を予想すると、HPCクラスタ界隈はOpteronやXeonやPowerPCが引き続き使われ、
クライアント環境でのベクトル演算/SIMDはSSEの進化で間に合う。
749:デフォルトの名無しさん
07/06/27 02:38:09
639 ：Socket774 [sage] ：2007/06/18(月) 23:35:29 ID:j/fCz3TG
URLﾘﾝｸ(it.nikkei.co.jp)
システム価格の安いｘ８６サーバーのクラスターシステムへの需要シフトが
継続するとＩＤＣではみています。
２００６年におけるｘ８６サーバーは前年比４０．６％増で、４年連続で前年比プラス
成長となりました。国内ＨＰＣ市場におけるｘ８６サーバーの出荷金額構成比は、
過去最高の３６．６％に達しました。
ＲＩＳＣサーバーからｘ８６サーバーに民間企業のＨＰＣ需要がシフトしたとみられ、
民間企業向けの大規模クラスターシステムが好調でした。
678 ：Socket774 [sage] ：2007/06/27(水) 01:35:36 ID:Kgk8gcuA
Sun，ペタフロップスを実現可能なSolaris機を披露へ
URLﾘﾝｸ(techon.nikkeibp.co.jp)
Rangerには米AMD社のクアッド・コアを6576個以上搭載する。
当初のピーク性能は105TFLOPSだが，2007年中にピーク性能を
421TFLOPSに引き上げる計画である。
IBM社の次世代BlueGene，米Argonne研が導入へ
URLﾘﾝｸ(techon.nikkeibp.co.jp)
今回のBlue Gene/Pの演算性能は114TFLOPS。
2007年秋には3万2768個のプロセサから成るシステムになる。
各プロセサは，4個のCPUコアを1チップ上に集積した，いわゆる
クアッド・コアである。