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/ 344 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 22:05:03 ] すみませんお聞きしたいことが nvidiaのCg言語はATIのチップ上でも動くのでしょうか？ GPUプログラミングをやってみたいと思っているのですが 手持ちがATIしかなくて 345 名前：デフォルトの名無しさん mailto:sage [2007/01/15(月) 20:05:39 ] >>344 ATIのチップでやったことないけど、できたと思う。 NVIDIA SDKでも落としてサンプルを走らせてみたらいいと思うよ 346 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 01:49:39 ] >>345 ありがとうございます。試してみますー 347 名前：デフォルトの名無しさん [2007/02/20(火) 09:13:53 ] CUDA使ってる人居ません？ 興味があって、GF88GTSのメモリが少ないやつを無理して買ってきたんですけど コンパイラが手に入らない・・・orz もしかして、ベータテスターや関係者じゃないと、まだ配ってもらえない？ 348 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 09:19:58 ] 落としてないから知らないが、CUDA Toolkit Version 0.8に コンパイラ入ってないの？ ＞The Toolkit includes standard FFT and BLAS libraries, a C-compiler for the NVIDIA GPU and a runtime driver. って書いてあるけど。 349 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 10:24:16 ] GPUで汎用コンピューティングを行うスレ pc10.2ch.net/test/read.cgi/tech/1167989627/16 developer.nvidia.com/object/cuda.html 350 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 15:34:52 ] >>347 お、動いたら感想よろしく。 351 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 17:10:05 ] 昨日か一昨日くらいにCUDAコンパイラのパブリックベータが始まった。 誰でも落とせるようになったはず 352 名前：347 mailto:sage [2007/02/21(水) 12:08:21 ] 情報THXです！ でも、うちx64のVistaマシンなので…orz まだ開発環境は32bit版しか出てないみたいで、ドライバに強く依存するらしく32bitアプリ側からは64bitドライバが見えないようです。 ドライバが入ってないというメッセージが出て、インストールすら出来ない…orz 早く64bitバージョンでませんかねぇ・・・。 353 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 13:34:37 ] >>352 英語版のnVIDIAのサイトからGO! 日本語版のサイトのvistaドライバのページは何故かNot Fount 多分最新のドライバ入れれば、有効になると思われ。 Vistaでは試してないけど、XPのx64でCUDA SDKは使えたから・・・(ただしグラボがGF66なのでインストールしただけｗ) 354 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 14:51:53 ] Supports Linux and Windows XP operating systems とかいてあるからVistaはまだ無理なのかも 355 名前：デフォルトの名無しさん [2007/02/21(水) 14:54:32 ] NVIDIA CUDA Homepage developer.nvidia.com/object/cuda.html 356 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 11:02:37 ] Vistaまだっぽいな。。 357 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:27:08 ] とりあえず動かしてみたいけどG80廉価版待ち 358 名前：デフォルトの名無しさん [2007/02/25(日) 13:00:56 ] 初歩的な質問です。 GPGPUにチャレンジしてみようと思い、BrookGPUを使ってるんですが ループの並列化がイマイチどのようにすればいいかがわかりません。 例えば、ループの部分で前回回した処理結果に加算を行う処理をする場合 前後関係が出てくるので、GPGPUに適した並列化は出来ないと思うのですが、こういうのは何か解決方法があるのでしょうか？ 359 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 14:15:44 ] >>358 依存関係がなくなるように計算式を変更するか、 並列させる方向を変えるような工夫が必要。 でもって、そういう工夫は実はSSEを使ったベクタ化やOpenMPによる並列化にも適しているので、 ますますGPUを使うメリットが活き難くなる罠。 361 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 18:34:02 ] 並列計算はいいんだけど 計算の中間結果を保持する為の テンポラリバッファが大きくなって すぐ頭打ちになりそうなイメージ 362 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 21:41:38 ] 演算精度が悪すぎて使い物にならない印象しかないんだが…。 363 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 22:13:06 ] 明日G80にダイブしてみるよ！ 飽きたら速攻で売り払わないと 364 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:03:53 ] >>362 mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html もうじき倍精度サポート 現状でも型としてはサポートしてるからコーディングは可能 365 名前：デフォルトの名無しさん [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:15:27 ] その処理は、コンパイラが優秀ならばCPUでもGPUでも まあまあ効率よく実行されそうだが。 367 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:57:20 ] >>365 その処理は問題ない。むしろ超得意なくらい。 368 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:58:42 ] >>365 それは前後の処理結果は関係ないでしょ。 imgに代入するならともかく、imgと言うデータがあらかじめあるのなら、そのままVRAMに転送すりゃいいわけだし。 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 手抜きするなーｗ 外側のループもはずせるだろ。 いや、面倒だから俺はやらないけどなｗ 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 あれは殆どマイクロソフト主導じゃん ＭＳの戦うプログラマの人が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をプログラマに管理させたりしてｗ まぁ、コンパイラが勝手にやってくれるんじゃないかな。 それ以外の場所は、一般的なクラスタリングシステムみたいにやってくれるって事はないと思われ そういうことは研究されてるけど、まだまだ一般的なコンパイラ1発でやってくれる仕組みは完成しているとは言いがたい。 最適な粒度をコンパイル時に調べてくれるとかやっても、別環境で実行する場合変わるしなぁ。 396 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 12:47:40 ] いや、俺が知りたいのは、それぞれのユニットがプログラムカウンタを持つのか、コプロセッサ命令でシェーダアレイコントローラに命令するのか、ということなんだ。 全部のユニットにプログラムカウンタがあったら、そりゃサブプロセッサが沢山載ったマルチコアでしかないじゃん。 コプロセッサ命令になるにしても、拡張命令で１度に１つのユニットに１命令送るだけじゃ意味ないから、適当なグルーピングが必要だと思うんだけど。 x86ISAの拡張ってんだから、後者ではあるんだろう。 で、その粒度はどんなのになるんだろうな、と。 >395 の話題も面白そうだけど、他のプロセスなりスレッドとのユニットの取り合いとかも考えるとやってらんないね。 397 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:14:04 ] 偉そうな口調で頓珍漢な事言ってる人は、出て行って欲しい。 んがぁ、無理なんだよね。 ひろぽんは、殺伐とした方が情報の濃度が上がるとか言うけど、 白痴や馬鹿が沢山いるのに、そりゃああり得ない話。 頓珍漢なこと言ってると理解出来るレベルの人にとっては、 その情報って情報価値を持たない情報だったりするし。 398 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:27:13 ] 日本語でおｋ 399 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:28:36 ] ウォッカはストロワヤが一番。やっぱりウォッカはロシアだね。 スレ違いスマソ。 自分の、これはダメかもわからんねは、 バイクで50キロぐらいで2車線目を走っていた。 するといいきなり目の前に1車線目に止まっていた車が右に、 フルブレーキするまもなく追突（前輪あたり） 10m程飛ばされて頭、ほんとにてっぺんからアスファルトに直撃。 その瞬間首が変な方向に、ぐにっとなった時。 結果は頭を支点にそのまま背中をまたアスファルトに直撃。 シボンヌ・・・、と思ったら生きてる。 その瞬間、車に腹が立って立ち上がり走っていってボンネットの上に飛び乗った。 運転手ポカーン、 んで警察に行って、病院行って、CT撮って診察の時。 他に痛い所は？と先生。 タンクで金タマ打って少し痛い。と言うと 顔色を変えてそれはいかんな、チョット見せて （看護婦ちょっとはにかんだ様な顔でカーテンを引く） 先生、漏れの金玉をうねうねコロコロして。 ん〜、大丈夫でしょう。しばらくすると痛みも引きます。 と言いながらカルテにカキコしてるのを見ると 　 　　睾丸hit　　　　 これはだめかもわからんね・・・ 400 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:58:53 ] 朝鮮語でおｋ 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】 ｈttp://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基 １コアあたり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 姫野ベンチ その２ 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うめぇｗｗｗｗとか言ってるの俺だけ？ 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にもあれがほぼそのまま搭載されるとか 470 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 20:01:33 ] >>467 BrookGPUが細かい事出来ないのは同意だけど 元々各シェーダーユニットを管理して並列化を効率化する事は出来ないぞ。 ベクトルプロセッサだから、そういうものだ。 うん、綺麗に管理できると良いんだけどなぁ…。 471 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:15:30 ] いやだからCUDA使えってあれなら俺等が求める 世界を追求できる。とりあえず、Geforce8600買ってみろ 472 名前：デフォルトの名無しさん mailto:sage [2007/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はなぜ？ってな感じで。 ttp://www.theinquirer.net/default.aspx?article=38598 実際にはG80とCUDAならFolding程度なら可能なんかな？ G80ないんで何ともいえないけど。 473 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:33:30 ] R580でやってるfoding程度はG71でも可能だがパフォーマンスが出なかった G80ではどうなんだろうな 474 名前：・∀・）っ-○◎● mailto:sage [2007/04/01(日) 22:36:24 ] CellでPCの数百倍ってちょっと信じがたいんだけど レジスタ本数が重要とかってこたないよな？ nVIDIAのシェーダってレジスタ少ないんじゃなかったっけ 475 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:36:41 ] >>472 おれもそうだけど、まだG88を買ってるやつがほとんどいないんじゃないかな。 おもちゃとしてはちと高いし、入れるとうるさいだろうし。 >>347がOS 32bitに載せ替えてくれればいいんだけど、それまでは皆次世代廉価版 待ちなんだろう。 476 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:57:37 ] >>347 つかおまえ、金はあるが知識無さ過ぎだろ？Linux入れろベンチ取るぐらいの駄コード書くのに 何64bitとOSにこだわり持ってるんだ？お前なら、RE買うのお金がないのですがとか言いそうで恐いけどなw 477 名前：・∀・）っ-○◎● mailto:sage [2007/04/01(日) 23:17:02 ] 俺なんかXeon買う金ないからPS3買ったくらいだｗｗ はやくRSX使いたいｗｗｗ 478 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:30:37 ] おれはNXT買う金がなくてRCX買ったよ 479 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:30:53 ] >>477 そのRSXって、要はG7XXXだろ。あんまり使い途ないんじゃないかなあ。 X11周りを作り替えるってんならありがたい話だが、あんたそういうのできる人だっけ？ 480 名前：・∀・）っ-○◎● mailto:sage [2007/04/01(日) 23:38:23 ] 出来ない人。 むしろ描画のHWアクセラレーションが利かないのが痛いの。 欧州ギークならなんとかしてくれる・・・と思いたい 481 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:12:15 ] >>480 Linux板で人の話を聞かずに無駄金使ったな。 482 名前：・∀・）っ-○◎● mailto:sage [2007/04/02(月) 00:21:37 ] GPU使えないって言ってもフレームバッファは使えるし X立ち上げて普通に使う（FireFoxでWebブラウズしたり）分には特に問題ない。 意外と使えるんでびっくり。 まあ現状でもCellマシンとしては十分元は取れてると思う。 General Processing出来る専用コプロセッサが7個 （ユーザーモードでは使えるのは6個）あるし。 今使えなくてもアップデートで使えるようになる可能性もあるし。 483 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:25:34 ] まともにニコ動が見れないWebブラウズなんかいみねーよ 484 名前：・∀・）っ-○◎● mailto:sage [2007/04/02(月) 00:28:07 ] Flashが見れないのはPPC Linux用Flashプレイヤーが提供されてないからで PS3のせいじゃないだろ 485 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:41:12 ] >>482 わかってないね。 Linux板で言ってたのは、鯖機のつもりで使えば、何の不満もないだろってことだよ。 コンソールはおまけ。おまけがそのうち化けるかもしらんけど。 486 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 01:25:25 ] 取り敢えず仕事用にHPの中古EWS調達して8800GTXのボード入れているけど、五月蝿いとは思わないなぁ。 487 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 02:37:17 ] 立ち読みしたPS3 Linux雑誌によるとnVIDIAはPS3 Linux用ドライバ作る気零らしい。 署名しかないのか。。。？ 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の場合、整数だけで座標を演算した方が速いと思う。 それにしても比較するのは酷な環境。 589 名前：デフォルトの名無しさん mailto:sage [2007/04/24(火) 23:45:07 ] ところで時間計測はどのように行ってます？ 590 名前：536 mailto:sage [2007/04/24(火) 23:49:26 ] いや、10msはXeon3.4GHz(>568-569参照)。 そう言えば、Celeronの速度は忘れてた。 591 名前：588 mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/04/24(火) 23:56:58 ] 何言ってるか分りにくいか。 ix %= width みたいな除算が重たいから取り除くって話ね。 593 名前：536 mailto:sage [2007/04/25(水) 00:41:07 ] >>591-592 あー、それは敢えてCUDAサンプルの出力を見て合わせた。 最初は条件分岐でやったけど、確か大して時間変わらなかったように記憶している。 >>589 CUDAのサンプルの時間測定をそのまま使ってたんで、今調べたらgettimeofday()だった。 594 名前：588 mailto:sage [2007/04/25(水) 03:13:43 ] 積に比べれば遥かに重いんだけど、流石にXeonでは誤差か。 けどGPUがサイズを二の累乗に限定していたのはこういうところにもあるはずで、 例えばwidthとheightが二の累乗に限定出来れば ix %= width; を ix &= (width-1); にして除算が排除出来る。 Celeronではかなり効果あるんじゃないかなあ。 595 名前：デフォルトの名無しさん [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 01:01:48 ] つか、ゲッパチ買ってきたんだけどCUDA糞じゃん 普通の文字列処理とかできねーじゃん。汎用GPUプログラミングとかいっておいて なーんもできねーじゃんゴミだだまされた。明日nvidiaに電凸しよう。 597 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 01:26:43 ] >>595のは、ちょっと例が悪かったです。 ごめんなさい(汗 ただ、他にifを使う部分は、やっぱり数式に直すしかないんですかね？ 598 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 01:42:26 ] >>597 悪いってレベルじゃねぇぞｗ で、結局そこはCPU側に出すか もしくは数式的に直せるのであればそうするしかないな。 CUDAは知らん。 >>596 はいはい。 使いこなせないだけですね。 文字列処理って何ですか？ 文字列を数値化すれば、形態素解析であろうが、文字列マッチングであろうが 置換であろうが、余裕ですよ。 599 名前：デフォルトの名無しさん [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 07:50:49 ] >>597 効率がどうなるかは知らんが、そういう用途ならCUDAの方が楽じゃない? 601 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 09:55:56 ] >>601 まず、後者の場合、reduceを使う void reduce sum(reduce float res<>){ res=res+5; } こんな感じ 前者の場合。 イテレーターを使うんだと思うんだけど、ちょっと俺にもわからん。 603 名前：602 mailto:sage [2007/04/27(金) 09:57:59 ] って、うわ・・・ 後者も間違ってる。。sumの問題じゃなかったのね。 すまん。 その場合普通に kernel void (out float o<>){ o=o+5; } でいいじゃん。 604 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 10:35:23 ] >>601 void reduce func(reduce float i<>, out float o<>){ o=i; i=i+1.0; } 後者は何が言いたいのかわからん。 普通で 605 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:19:43 ] お前らCUDAやりなさい。 ところで、CgがあるのにCUDAを出す意義って？ nVIDIAは言語の乱立を自重汁 606 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:46:51 ] Cgはシェーダー言語。HLSLのベースになった時点であるいていど成功。 CUDAはプログラミング言語。 607 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:49:41 ] >>606 はあプログラミング言語ねえ 608 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 03:02:44 ] >>595 conditional move とか select とか、そういう類の命令を持つ CPU とか GPU があるのね。 だから３項演算子とか>599のようなことで問題なし。 そんなことを気にするよりも、まずは動くものを作ってこことかどっかに投げないと、何が聞きたいのかわからんというか、何を答えても的外れになりそうな気分になって答えられない。 609 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 13:22:28 ] BrookGPUって、intは使えないよね？ データがint型で、ストリームに送る前にキャストしても返ってくる値がおかしいから困る・・・。 こういうのってどうすればいいんだ？ 610 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 08:20:49 ] 桁落ちが原因だろ。＞値がおかしくなる。 落ちない範囲に収めるor諦める 611 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 18:01:20 ] コーヒーブレイク ttp://www.forum-3dcenter.org/vbulletin/showthread.php?p=5449565#post5449565 ttp://www.forum-3dcenter.org/vbulletin/showthread.php?p=5450755#post5450755 R600のリークスライドなんですが、SuperScalar,SIMD,VLIW等 並列実行のキーワードが並んでます。 詳しい人、どうなんでしょうこのGPU。 612 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 00:36:29 ] 電気馬鹿食いDQNカードだぞ？ 613 名前：デフォルトの名無しさん [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 13:36:48 ] >>613 それは計算量少なすぎ。 明らか転送のネックの方が大きいだろｗ 615 名前：613 mailto:sage [2007/05/04(金) 13:40:38 ] >>614 CPUの時も、streamReadとstreamWriteだけやるようにしてみました。 それでもCPU:16秒でした^^; 616 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 14:10:15 ] >>615 それはつまり、GPUの処理時間は2秒ということだね。 ……だからなに? 617 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 14:20:32 ] 転送時間を差し引いても、演算速度がCPUよりGPUの方が遅いって話だろ そんなの冷静に評価してるやつはみんな言ってるじゃん たまに『GPUはCPUの数十倍』とか夢見たいな話してる脳内お花畑さんが居るがｗ 618 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 14:49:27 ] BrookGPUはデバッカはついてるのかな？ ブレークポイント設定してステップ実行とか出来るの？ 今、主にHLSLで組んでいるんだけど GPUデバッグがやりずらくて困ってるんけど 同じかな？ 619 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 15:11:56 ] >>618 BrookGPUって、単なるコンバータだよ。 結局Cgのデバッグ作業になるが・・・。 Cgは、nVIDIAがそういうツールを提供してる。 620 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 15:39:12 ] >>613 大量にデータを送り込めば数で勝るGPUは高速 しかし、BrookGPUのstreamは2048くらいしか要素を確保出来ない。 その程度では、GPUコア全てを使い切れないので、CPUの方が高速。 これの意味はもう分かるよな？ さっさと、CUDAでも覚えるんだ。 621 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 15:44:08 ] BrookGPUなんて海外じゃもう糞確定してるって見方が大半だよ。GPGPUで 最先端いってるやつらに、BrookGPUwって感じで笑われるしなぁ。 622 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 15:50:31 ] BrookGPUはお遊び言語なのは知ってるけど じゃあ、何が良い言語なんだ？ CUDA出る前からGPUは騒がれてたんだから、CUDA以前から扱いにくくともCPUよりちゃんと速度が出るのはあるんだろうね？ SHとか使ったが、あれは、ちょっとなぁ・・・ 623 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 15:58:54 ] 実際に海外の優秀なやつはら暇つぶし程度にしかいまのところやってないよ 速度云々は別にどうでもいいって感じだよ。ただできましたって感じだよね 624 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 15:59:51 ] …おい 誰も何でつっこまんの？ 行列演算させずに、１次元計算させてどうするんだ。 まずは、GPUに計算させる前に、Gridにデータを落としこむべきだろ。 Gridにデータを落とし込むような価値の無い計算ならば、するな。 本当にレベル低いな、おい… 625 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 16:03:56 ] >>624 何マジレスしてるんだよw？ 626 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 16:17:52 ] 行列に落とし込むくらいだったら、CPUに演算させた方が・・・ｗ たまに出てくるGPGPUで有効な例とする for(i=0;i<SIZE_N;i++){ out[i]=in[i]+1; } こういう処理を否定してちゃあ、世間のジャーナリストは嘘つきだなｗ 627 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 18:55:00 ] ttp://mumei24.run.buttobi.net/cgi-bin/upload.cgi?mode=dl&file=971 DLパス:gpu トーラスをランバートのシェーディング（ｃｇ）で表示するだけのプログラムなのですが どうも動かないです。OPENGLです。 誰か助けてください。 628 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 00:11:23 ] >>611 リンク先は流し読みしただけだけど。 SuperScalarやらSIMDやらは今更な感じがする。 今までってSuperScalarじゃなかったんだっけ？ 少なくともSIMDだったよな。 VLIWはちょっと気になるな。 GPUに既存のCPUのアーキテクチャでやられたヤツを色々持ち込むのはいいんだけど、 効率（性能）が向上するかは未知数だし、 GPGPU的に使いやすいかは別問題だったりするし、 どうなるんだろうね。 と、思ったことを適当に書いておく。参考にならんな。 629 名前：デフォルトの名無しさん mailto:sage [2007/05/07(月) 01:27:32 ] GPUはSPMDだろ。 まぁCUDAで言えばWarpはSIMDだが、いずれにしてもGridレベルのSPMD。 630 名前：デフォルトの名無しさん mailto:sage [2007/05/09(水) 18:24:24 ] 627ですが…反応ないですか 631 名前：デフォルトの名無しさん mailto:sage [2007/05/09(水) 22:08:54 ] >>630 激しくスレ違い。 ここはコンピュータグラフィックス関連のスレじゃないよ。 632 名前：デフォルトの名無しさん mailto:sage [2007/05/10(木) 19:04:59 ] …スレ違いなんですか 他スレの方が汎用コンピューティングとあったのでこちらで聞いたのですが 633 名前：デフォルトの名無しさん mailto:sage [2007/05/10(木) 22:31:23 ] GPUスレと勘違いしてないか？ GPGPUスレだぞ。汎用的にGPUを使おうってスレで、本来のグラフィックス処理がらみはスレ違い。 634 名前：デフォルトの名無しさん mailto:sage [2007/05/11(金) 00:05:44 ] OpenGLスレとかその辺かな。 635 名前：デフォルトの名無しさん mailto:sage [2007/05/13(日) 22:58:51 ] このスレッドの人ってあかでみっくぽすとの人が多いのかな 636 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 01:27:35 ] 中途半端に賢い人が多いんだよ 637 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 07:05:44 ] >>611 ttp://techreport.com/reviews/2007q2/radeon-hd-2900xt/index.x?pg=3 float MAD serial以外は、概ね速い。 638 名前：デフォルトの名無しさん mailto:sage [2007/05/17(木) 02:43:02 ] 最近シェーダを学び始めた者です。 調べた結果、自分の中で結論出たようなものなのですが、 最後の確認として質問させてください。 シェーダで、32bit整数を扱うことは可能でしょうか？（ベクトル型で） もし可能であれば、シェーダモデルやベンダ拡張等問いません。 GPGPUな目的で学習していますので、このスレで質問させて頂きました。 よろしければご教授お願いします。 639 名前：デフォルトの名無しさん mailto:sage [2007/05/18(金) 11:28:03 ] Cgでint4が出来れば扱えるんじゃない 640 名前：デフォルトの名無しさん mailto:sage [2007/05/18(金) 22:35:37 ] CUDAは、さっさとXP x64とVistaに対応するべきだ。 俺、この2つのデュアルブートだから、せっかく8シリーズ買ったのに・・・。 これのために買ったのになぁ・・・orz 641 名前：デフォルトの名無しさん mailto:sage [2007/05/19(土) 00:02:18 ] >>639 ありがとうございます。 試してみます。 642 名前：デフォルトの名無しさん mailto:sage [2007/05/19(土) 21:48:38 ] ATI RADEON X800 XTで Ｃｇの中でforやらbreakが使えないみたいなエラーが出たんだけど これってどこで確かめれるの？ 643 名前：デフォルトの名無しさん mailto:sage [2007/05/19(土) 23:25:09 ] >>640 ゲフォ8800なんて買う変態がXP 32bitにするわけがないからなぁ。 本当に本腰入れたいんならVista&XP×32bit&64bit全部入りだろうけど。 とりあえずコンパイルしてエミュで動かしてみたが速度とかどうってより operatorやらtemplateやらが通るのに吹いた 644 名前：デフォルトの名無しさん mailto:sage [2007/05/20(日) 01:18:59 ] >>643 CUDAのこと? あれ、だってコンパイルにはgcc使ってるもの。 645 名前：デフォルトの名無しさん mailto:sage [2007/05/20(日) 14:17:03 ] あーそりゃそうだな 646 名前：デフォルトの名無しさん mailto:sage [2007/05/26(土) 21:56:13 ] ねねCUDAで if(input == 'a'){ ... } else if( input == 'b'){ ... } て処理書きたいんだけどどうやって書けばいいか教えてください 647 名前：デフォルトの名無しさん mailto:sage [2007/05/26(土) 21:58:16 ] 無理 648 名前：デフォルトの名無しさん mailto:sage [2007/05/26(土) 22:57:06 ] なんだとぉ ふざけるんじゃねーよ教えてくれよマジ切れするぞ ゆとり世代は沸点低いんだよ忘れたのか？ 649 名前：デフォルトの名無しさん mailto:sage [2007/05/26(土) 23:35:02 ] ＞ゆとり世代は沸点低いんだよ忘れたのか？ ちょっと地面に穴掘って埋まってきたら? 圧力掛かると沸点高くなるっしょ。 650 名前：デフォルトの名無しさん mailto:sage [2007/05/26(土) 23:56:46 ] >>649 なめてんのかコラいいかげんにさっさと教えろよ 651 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 00:00:20 ] マジレスしてやるよ CUDA SDKにはエミュついてるから、自分で試しヤガれ コンチクショー 652 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 00:23:39 ] だから無理だって言ってるだろ。 GPUには、条件分岐するキーワードは無い。 予めCで分岐してから、各処理を呼び出すしかない。 653 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 00:38:12 ] じゃあ abcdefjを128bitのhexとかに予め変換してとか小細工しても strstr()なんかを作ることは無理なのか？ 654 名前：デフォルトの名無しさん [2007/05/27(日) 11:33:06 ] >>653 もちっと、じぶんのあたまでよくかんがえてからしつもんしよう。 ぺたっ　（もうすこしがんばりましょう） 655 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 11:34:31 ] >>654 わかんねーからきいてるんだろうが こちとら時間ねーだんよささっと情報晒せ 656 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 12:11:24 ] 時間ないなら諦めたら? 657 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 12:12:27 ] >>656 悪かった取り乱してしまった。すまいと反省している。 ね？ね？ヒントでいいかなんか情報くださないな 658 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 12:56:58 ] なかなか釣れませんね 659 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 01:34:39 ] あのー誰か教えてよぉもう2日もがんばってるけど できないよ 660 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 08:32:29 ] >>659 そもそもなぜGPUでstring処理を行いたいのでしょうか？？ いくらCUDAでGPUを汎用プログラミング用途に使えるようになったと 言っても、やはりGPUが得意とするのは大量の単精度浮動小数点データ に対する演算だと思うのですが。 661 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 13:59:24 ] 余計なお世話だろ 662 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 14:36:51 ] すみませんでした 663 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 00:38:24 ] >>660 1024bitとかまぁもっと長いbit列の処理をさせた場合 現状どの程度優位（もしくは無意味か）データが採りたいんですよ。 だれか具体的にいくらって数値出していただけるならうれしいのですが そんなもん自分でやれっていわれるのはまちがいないのでCUDAで どうやって作ればいいのかちょっと聞いてみたかったんですよ。 未だにできないでうーむってうなってますよw 664 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 01:00:22 ] >>663 CUDA SDK付属のエミュでまずは作れ。 そしたら実機で回してみせるよ。 665 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 01:02:10 ] >>663 CUDA SDK付属のエミュでまずは作れ。 あうあう？うーんうーん？エミュってどこにあるの それいってくださいよーもー 666 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 01:08:06 ] まずはダウソしてインスコしてビルド汁 話はそれからだ developer.nvidia.com/object/cuda.html 667 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 01:22:09 ] 64bitじゃ無理じゃーん どうしろっていうんだorz 668 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 02:35:44 ] 俺もXP x64とVistaのデュアルブートだから無理だったんだよな・・・prz 669 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 07:54:50 ] >>667 欲張って64bitのマシンを買うからだ 670 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 09:40:38 ] 大丈夫、漏れは64bit機で32bitRedHat入れている。 #勿論、CUDAは問題なく動く。 671 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 23:27:42 ] grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/note048.html jp.arxiv.org/pdf/astro-ph/0703100 実用の計算で150Gflopsなら立派なもんだね。 負け惜しみで発熱に文句付けてるけど、 1年半すればミドルレンジ、3年後にはノースのおまけになるのがGPU。 残念ながらGrapeはお終い。 672 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 23:32:08 ] 演算アクセラレータボードを作っている会社も危ない状況ですね。 某社のボードなんか100万とかする挙句に開発環境がそれの倍以上だもんなぁ。 673 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 23:52:47 ] ねぇねぇubuntu x64環境でどうやってCUDAするの？ toolとcudaいれたけどVideoのドライバがインスコできない なんで？ 674 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 23:59:43 ] >>674 日本語の参考書が出るまで、あんたにはCUDAは使えない。 日本語の参考書が出たらまたどうぞ。 676 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 00:26:47 ] >>671 いやさすがに3年後でmGPUにはならないでしょ… 677 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 01:30:32 ] >>674 エラーメッセージにダメな原因がはっきりと書いてあると言うのに、 これでも文章の意味が分かりませんか。はぁーーーーー。 # 日本の英語教育がよくないのか、それとも674氏特有の問題なのか。 ネイティブスピーカーが何を言っているのかなかなか分からない私で すが、文字として書かれていれば、これくらいの文章は普通に理解で きないものですかねぇ。 なんだかんだ言っても実質的に世界標準言語は英語なわけで、GPGPU とか言い出す前に、まずは中学・高校レベルの英文は読めるようになる 必要があると思います。 # それができないなら、675氏の言う通りだと思います。 678 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 01:34:26 ] いや、日本語の参考書が出てもダメでしょ。 679 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 03:14:22 ] >>671のサイトのはGRAPEの製作者のところなので 自分たちのシステムの優位性をアピールしたいんだろうが その人たちですら、性能面でのGPUの優位性はもはやみとめざるを得ないと言う事だろうな。 しかしまぁ、CUDAの実行環境の話もそうだけど さっさとGPGPUの環境整えてくれ。Vistaやx64非対応ってやる気あんのかと 680 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 03:16:42 ] 一般人は、エラーメッセージの内容を信用しないって所があるんじゃね？ 多分、そのメッセージが日本語でも同じ。 理由は、Windowsのような、全くもって何の解決にもなってないようなエラーを吐く環境に鳴れたせいかと。 アプリケーションの強制終了の時のエラーダンプを、アプリケーションの作者に送っても殆ど無意味だし。 ブルースクリーンのエラーメッセージをコンピュータのサポートに送っても無意味だからなぁ 681 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 23:10:00 ] おいハードディスク買ってきたから32bitOS入れるから 教えてくれるよね？ 682 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 14:26:11 ] 環境は今からそろえるつもりとして、はじめるとしたらCUDAとCgどちらがいいですか？ 683 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 14:33:49 ] 両方やれば? 684 名前：デフォルトの名無しさん [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 16:17:50 ] GPUチップを認識できてないとそうなった希ガス。 nvcc動かすだけなら大丈夫だと思うけど。 686 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 02:02:23 ] エミュ用のディレクトリのを実行した？ 687 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 12:43:44 ] サンプル動いたぉ 688 名前：おしえてちゃん mailto:sage [2007/06/03(日) 14:27:02 ] gpgpu志向のプログラム作ろうとしてます。 ですがいきなり分からないことが、出てきました。 点を二つ作り、その点の大きさをgl_PointSizeを使って 大きくしたら、点が重なりました。その重なった部分の混合色は どのようにつくられるのですか？ 1,(vertex + fragment シェーダでの処理を一単位と考えて) 二度シェーダプログラムを呼んで色の混合を作る。 2,（上と同じ考えで）一度で処理する。 3,そのほか 同じカーネルに、複数の色を叩き込むということなので、 その色の混合処理の方法がわからないのです。 一体どれなんでしょうか？ 689 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 18:14:52 ] あまりGPGPU指向の話じゃないねぇ 690 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 19:24:42 ] ちょいCUDAで質問 とりあえずCUDAの手順として デバイス初期化 メモリ初期化（host,dev) 計算 終了処理 という感じになっているが、なんでkernelの関数呼び出す時こんな キモい呼び出しになってるの？すっげーキモくて違和感ありありなんだが testKernel<<< grid, threads, mem_size >>>(d_idata, d_odata); こんなアフォな呼び出ししたくねーよw 691 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 19:55:22 ] その呼び出しのどの部分がキモいのか具体的にお願いします。 692 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 20:43:48 ] 逆にそれだけで済んでしまうところが肝なんだが。 693 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 21:10:34 ] 今エミュだけだからよーわからんのだけど __device__と__global__って再帰呼び出し禁止だけど ２つの関数交互に呼ぶのはOKなのかなぁ？ エミュだとOKに見えるのだが実機だと動かなそうだがうーん 694 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 22:12:09 ] ソース上げてくれたらテストするよ。 695 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 23:13:18 ] __device__ hogeから__device__hoge1を呼び出せないのは痛いなぁ。 inline展開できない場合は処理不可能なのかぁうーむ。これにはちと まいったな 696 名前：デフォルトの名無しさん mailto:sage [2007/06/07(木) 23:58:14 ] なぁなぁ Geforce8800GTXでCUDAするとき sharedメモリいくらになるの？ 各ブロックはいくらになるの？ その辺の情報がいまいちよーわからんのだが 697 名前：デフォルトの名無しさん [2007/06/08(金) 07:41:27 ] CUDAが未だにVistaやx64に対応できないのは何か理由があんの？ もうかなり経つよね。 698 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 00:43:57 ] GPGPU完全死亡 pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm 699 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 02:23:44 ] >>698 こんなのセルと大してかわらへん 並列度が低すぎる 700 名前：・∀・）っ-○◎● mailto:sage [2007/06/11(月) 03:08:05 ] IA命令セットと互換ってのがみそだろ。 どうせSSEだろうけど。 701 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 07:00:21 ] で、どれだけ広まるのよ？一般に。 GPU以上に広まる可能性はあるのけ？ 702 名前：・∀・）っ-○◎● mailto:sage [2007/06/11(月) 07:04:13 ] そもそもGPUじゃないし ただGPUで出来るGeneral Processingのおいしい部分は全部持ってっちゃうと思う。 x86のコードがそのまま動く意味は大きい。 703 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 07:04:20 ] しかも2009年まで出てこなんじゃ インテルお得意のキャンセルされるかもしれないしね 704 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 18:39:47 ] CPUコアがいくら増えたところでGPUの性能が落ちる訳じゃないし。 706 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 19:57:52 ] GPGPUよ、短い命であった。 707 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 22:43:50 ] そう、CPUのコアが増えたところで GPGPUを使えば更に速くなるわけで、どっちか切り捨てるとかそういうものじゃないでしょ。 使えるものは使うと速くなるんだから。この場合は　だけどｗ 708 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 23:07:43 ] 例えば今まで CPU10 + GPU25 = 35 で処理できていたことが CPU20 + GPU25 = 45 で処理できるならそれはいい。 なんで CPU20 = 20にGPU切り捨てる必要があるんだ 709 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 23:15:13 ] しかも、CPUよりはGPUの方が安い罠。 710 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 23:18:20 ] 30コアのCPUがいきなり一万円台で買えるとは思えないが。 よっぽど一世代前の高級GPUのほうが安く買えるかも。 711 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 23:41:11 ] PCI-Expressに挿せる超高速コプロならなんでも売れると思うけどね。 GPUでも糞INTELの石でもなんでもいいけどね 712 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 23:46:48 ] そうは言ってもClearSpeedはベンチマークスコア上げるのには 有効だが実用面ではちょっと。 713 名前：デフォルトの名無しさん mailto:sage [2007/06/11(月) 23:51:48 ] あれは期待外れだった。糞高いコンパイラだけで性能出せないんじゃ……ねぇ。 714 名前：デフォルトの名無しさん mailto:sage [2007/06/12(火) 07:29:59 ] 「Larrabeeが登場したら、ハイパフォーマンスコンピューティングのベンチマークを 総なめにする可能性がある」とある業界関係者は期待を語る。 Larrabeeのターゲットアプリケーションは、一目見てわかる通り、GPUがGPGPU でターゲットにし始めている領域と完全に重なる。つまり、LarrabeeはIntelによる GPGPUの動きに対する回答だ。IntelとGPUベンダーは、ハイパフォーマンスな 浮動小数点演算性能が必要な並列コンピューティングの領域で、真っ向から ぶつかることになる。 715 名前：デフォルトの名無しさん mailto:sage [2007/06/12(火) 14:02:27 ] LarrabeeはSSL対応レイヤ3スイッチのアクセラレータや 重めのアプリケーションサーバにも向いているような気がする。 値段次第だけど。 716 名前：デフォルトの名無しさん mailto:sage [2007/06/15(金) 05:53:00 ] R600のプログラム形態はSPIのStorm-1に近いかも知れん。 717 名前：デフォルトの名無しさん mailto:sage [2007/06/15(金) 06:11:31 ] ttp://journal.mycom.co.jp/articles/2007/02/15/isscc1/ >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 名前：デフォルトの名無しさん mailto:sage [2007/06/15(金) 19:06:16 ] GPGPUでGrapeオワタと思たらメニーコアでGPGPUオワタ 719 名前：デフォルトの名無しさん [2007/06/19(火) 20:26:20 ] GPGPUを使った類似画像検索とか面白そうだが どこもやってないのかな？ 720 名前：デフォルトの名無しさん mailto:sage [2007/06/19(火) 21:52:03 ] 画像のパターン検索？ならやってた人がいたと思う 721 名前：デフォルトの名無しさん mailto:sage [2007/06/19(火) 23:10:03 ] まぁそういう用途はGPGPUよりもこういうほうが面白そうだけどスレ違いか ttp://www.k2.t.u-tokyo.ac.jp/vision/M-SIMD_architecture/index-j.html 722 名前：・∀・）っ-○◎● mailto:sage [2007/06/20(水) 00:57:06 ] DirectX10でGPUを汎用整数プロセッサとして使うサンプルある？ 723 名前：デフォルトの名無しさん [2007/06/20(水) 01:19:03 ] 今更R600って、…MSX Turbo-R？ 724 名前：部外者('A`)NEET ◆xayimgmixk mailto:sage [2007/06/20(水) 11:57:32 ] あれは、R800だろ。 725 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 16:44:13 ] SEGA の体感ゲームだっけ? 726 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 01:21:12 ] R3000じゃなかったっけ？ ジオメトリエンジンついてるんだよな？ 727 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 05:39:54 ] ttp://www.dailytech.com/article.aspx?newsid=7772 NVIDIA Announces Tesla General Purpose Processor Platform ttp://pc.watch.impress.co.jp/docs/2007/0621/nvidia.htm NVIDIA、G80ベースのHPC向けGPU「Tesla」 〜PCI Expressカードタイプから1Uラックまで >Teslaのソフトウェアプラットフォームは同社の汎用プログラミングモデル >「CUDA (Compute Unified Device Architecture)」を利用。 >CUDAにはGPU用のCコンパイラが含まれており、 >Cプログラムに若干の修正を加えるだけで、 >CUDAコンパイラが処理をCPUとGPUに振り分けられる。 728 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 06:05:30 ] 新しいGPGPU ttp://www.gpucomputing.eu/index3.php?lang=en&page=_library1.php&id=3 ttp://www.gpucomputing.eu/index3.php?lang=en&page=_demo4.php&id=3 729 名前：ktkr! mailto:age!age! [2007/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 ttp://developer.nvidia.com/object/cuda.html ....ちょ、x64とかVistaは? 730 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 11:50:15 ] お、情報THX。 早速見てみなくちゃだわ。 731 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 12:15:19 ] もう完全にCUDAはやる気ないんじゃない？ うちはXP x64とVistaのデュアルブートだから、完全にアウト。 732 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 12:17:27 ] >>731 大丈夫、TesraがあるからCudaは終わらない。 733 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 14:56:23 ] こりゃあrapidmindの勝ちかな 734 名前：デフォルトの名無しさん [2007/06/26(火) 15:51:35 ] x86_64 でXPとかビスタなんて使ってるやついたのか？ 735 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 15:54:31 ] GPGPU用途に限ればLinuxでもいいのか。 CUDAカーネルの5秒制限も払拭されることだし。 736 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 18:51:32 ] 残念。Larabeeの一人勝ち。 737 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 19:15:32 ] CUDAの分野とかから考えて、Vistaとx64を避ける意味がわからん。 特にVistaでは、GPUの仮想化をサポートしてるんで、まさにGPGPUの為の実装みたいなもんなのに・・・ 738 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 20:32:02 ] Larrabeeは2009-2010登場のでGPU軍勢が散々広まってしまった後だ。 それにGPUは3世代進歩する。 専用ライブラリやランタイムが必要ならISAがx86である意味は薄い。 ましてや32コアを意識してプログラムを組めなんて気の遠くなることは・・・ Larrabeeだけこける。 GPU軍勢の影の総大将がMicrosoftであることは間違いない。 739 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 20:52:27 ] >>737 じゃあDirectX10.1が出る頃には対応するんじゃないか 740 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 21:11:16 ] PeakStreamを忘れないでください…と思ったけど買収されたしナァ 741 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:39:50 ] >>738 そんなばかなｗ GPU軍勢って、nVIDIAだけじゃん。 結局IntelとAMDの天下だよ。 742 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:46:43 ] ララビー来るまでにTeslaがどれだけ普及するかだなぁ。 取り敢えずCUDA1.0を788GTSで動かすかな。 743 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:58:45 ] 歴史的に見て、このプロセッサ(GPU)をCPUが取り込もうとして 失敗する事は殆ど無い。最終的にCPUに取り込まれるのは必然だと思われ。 性能云々の問題ではすまない。それで住むならMIPSは勝利していたはず。 キーとなるとは、いかにGPUを汎用的に使えるようにするか　だ。 GPUのメリットはぶっちゃけてしまえばコア数の差だ。これがもっと汎用的な事が可能なCPUもコアが増えるとなれば大変だ。 向き不向きで確かにGPUの並列化のほうが得策かもしれないが、その差が微々たる物であった時、はじめは部分的に使われても、最終的には全てを飲み込まれてしまう。 CUDAがx64やVistaに対応しないとか、馬鹿な所で詰まってる場合ではない。 今のメリット(先行)を生かさないと・・・。 本当に何を考えてるんだか・・・。 744 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 01:05:29 ] 先生！ 強い電波を観測しますた！！ 745 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 01:39:32 ] >>743 まー、さっさと対応して欲しいよね。 俺もCPUに取り込まれてx86になったら、人は流れると思う。 特定分野はわからんけど、それならそれでx64に対応しろよ。 何もかもが中途半端 746 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:10:44 ] と思ったがLarrabeeは全部のコアでフルx86が走るのか。 そうなると>LarabeeでもFusionでも使えるとなれば〜は無いな。 748 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:28:25 ] CPU/MCHどっちにくっついていようがオンボードVGAがシェーダー重視で肥大化して いったら、逆にS3（VIA）その他の弱小グラフィックスが再び脚光を浴びる。 （PCIeカードの）GPGPUは大学の研究室/個人レベルで使われるだろうが、それで終わる。 チップ自体の価格は大量生産を背景に競争力を持てるが、プログラミングコスト、電力 コストを考えると中〜大規模案件では採用されない。 Larrabeeは詳細不明、リリース次期から逆算すると現時点でテープアウトしてなさそう。 後藤記事によると「“練習版”、本格的な製品とは言えない」(業界関係者)。とのことで、 実用化への道は長い。 5年後を予想すると、HPCクラスタ界隈はOpteronやXeonやPowerPCが引き続き使われ、 クライアント環境でのベクトル演算/SIMDはSSEの進化で間に合う。 749 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:38:09 ] 639 ：Socket774 [sage] ：2007/06/18(月) 23:35:29 ID:j/fCz3TG it.nikkei.co.jp/business/news/release.aspx?i=162405 システム価格の安いｘ８６サーバーのクラスターシステムへの需要シフトが 継続するとＩＤＣではみています。 ２００６年におけるｘ８６サーバーは前年比４０．６％増で、４年連続で前年比プラス 成長となりました。国内ＨＰＣ市場におけるｘ８６サーバーの出荷金額構成比は、 過去最高の３６．６％に達しました。 ＲＩＳＣサーバーからｘ８６サーバーに民間企業のＨＰＣ需要がシフトしたとみられ、 民間企業向けの大規模クラスターシステムが好調でした。 678 ：Socket774 [sage] ：2007/06/27(水) 01:35:36 ID:Kgk8gcuA Sun，ペタフロップスを実現可能なSolaris機を披露へ techon.nikkeibp.co.jp/article/NEWS/20070626/134833/ Rangerには米AMD社のクアッド・コアを6576個以上搭載する。 当初のピーク性能は105TFLOPSだが，2007年中にピーク性能を 421TFLOPSに引き上げる計画である。 IBM社の次世代BlueGene，米Argonne研が導入へ techon.nikkeibp.co.jp/article/NEWS/20070626/134832/ 今回のBlue Gene/Pの演算性能は114TFLOPS。 2007年秋には3万2768個のプロセサから成るシステムになる。 各プロセサは，4個のCPUコアを1チップ上に集積した，いわゆる クアッド・コアである。 750 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:39:19 ] 670 ：MACオタ [sage] ：2007/06/26(火) 22:25:47 ID:E+b+TZBO Blue Gene/Pのプレスリリースす。 www-03.ibm.com/press/us/en/pressrelease/21791.wss 　　--------------------- 　　Four IBM (850 MHz) PowerPC 450 processors are integrated on a single Blue Gene/P 　　chip. Each chip is capable of 13.6 billion operations per second. 　　--------------------- 　・PPC450: Quad 850MHz PPC440 core with "Double Hummer" FP-APU 　・1 petaflops at 294,912-processor 　・up to 884,736-processor 　・optical rack-to-rack interconnect 671 ：MACオタ＠補足 [sage] ：2007/06/26(火) 22:35:03 ID:E+b+TZBO とりあえず884,736-processorの最大構成で2-PetaFlopsわ超えるす。同じPPC44xベースの コアが90nmバルクCMOSで2GHzを超えることが可能なことも証明されているすから(>>392参照)、 Blue Geneわ、このままの設計でも数年以内に5-PetaFlopsを超えるロードマップわ現実的す。 751 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:41:21 ] 変なの沸きすぎ 752 名前：・∀・）っ-○◎● mailto:sage [2007/06/27(水) 04:23:26 ] 俺Vista x64で8600GTだけどDirectXしかねーべ？ 753 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 05:29:45 ] Larrabeeってどうやって普及させるつもりなんだろうか。 754 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 11:13:19 ] 最終的にはCPUと統合らしいから 普通に次世代CPUとしてでしょ。 何となくチップセットに内蔵してきそうな気もする。 っていうか、単体で出さないでしょ？ｗ 科学技術分野に出すかも知れないけど、普及版は統合かと 755 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 12:35:48 ] 出るのは pcie gen 2 カードでだよ 価格は10万前後 756 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 15:31:56 ] つかストリームコンピューティングって市場がそもそもないだろ せいぜい研究機関とか大学で細々と使われるぐらいで 結局ソフトウェアが無ければ普及しない リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも 法線マップとかのイメージスペース技法の発明でそんなことはこの先起こらない 757 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 16:43:33 ] GPUじゃないけど一番敷居が低いのはやっぱりCell? 758 名前：536 mailto:sage [2007/06/27(水) 16:56:17 ] >>757 思いっきり高い敷居を跨ぐ為に、誰もが俺様ライブラリを作っている状態ですが。 759 名前：デフォルトの名無しさん [2007/06/27(水) 17:06:03 ] >>756 ＞つかストリームコンピューティングって市場がそもそもないだろ あるけど言わない。飯の種だから。 潜在的需要はいくらでもある。 ＞リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど ＞ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも それ以外にも、レンダリングパスが多くなりすぎるケースや、 ラスタ処理では不可能な処理や、誤魔化していた処理、 そういった高レベルの処理を入れていくと、ラスタライザでは限界がある。 光源が増え、シャドーが幾何級数的に増加したら、従来のラスタライザではどうしようもなくなる。 最終的にはレイトレとラジオシティを組み合わせたものしか生き残れない。 760 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 18:14:04 ] >>759 > 潜在的需要はいくらでもある。 そりゃ潜在需要がなけりゃ誰も新規にストリームプロセッサに投資なんてしない 俺が言いたいのはGPUに対する3Dゲームのような決定的な市場があるのかってこと 詐欺まがいのソフト作って無知相手に売ってもせいぜい売り上げは数百〜数千万円程度だろ > 光源が増え、シャドーが幾何級数的に増加したら、 > 従来のラスタライザではどうしようもなくなる。 またまたご冗談を 勘違いしやすいがシャドーマップってのもコヒーレントレイだからな ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば 圧倒的に後者の方が効率的だし、そもそも光源数とシャドーの増加量に比例して 負荷も比例するのはレイトレも同じ おまけにレイトレは動的シーンに致命的に弱い 俺はこの先もリアルタイム3DはGPUラスタライザで変態的テクニックを多用していくことに変わりないと考えるね 一次レイと一次シャドーレイだけで息切らしてるようなリアルタイムレイトレは期待できない 761 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:06:27 ] >>760 >そりゃ潜在需要がなけりゃ誰も新規にストリームプロセッサに投資なんてしない >俺が言いたいのはGPUに対する3Dゲームのような決定的な市場があるのかってこと それを教えてほしけりゃ自分で探しな〜 >詐欺まがいのソフト作って無知相手に売ってもせいぜい売り上げは数百〜数千万円程度だろ 確かに数億〜数百億のプロジェクトを仕切っているあなたにはたいした額ではないですね〜 でも会社としてはそういう態度で仕事に望まれると困るんですが・・・ つか通常のGPUで盛り上がっているし。 意見は貴重だけどよそでやってくれないかな〜？ 762 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:12:23 ] レイトレの話はさすがにスレ違いだけど、 「GPUに対する3Dゲームのような決定的な市場」があるのなら是非知りたいね。 763 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:36:03 ] 言う気無いならがんばるなよ。言わなきゃ論証にならないんだからさ。 764 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:41:30 ] >763 誰に言ってるの？ 765 名前：536 mailto:sage [2007/06/27(水) 20:15:23 ] 少なくとも漏れの周りでは高速に演算したいと言う要求が色々ある。 「面倒だから1Uサーバ機を100台単位で並べろ」ってのから「4core2CPUは高いからなんとかならんか?」まで千差万別。 前者の場合でも、「1U機にGPU入れればラック筐体単位で節約できる可能性がある」となれば興味を示すだろう。 (他社のアクセラレータボードに較べて)安いことは充分刺激になっているよ。 766 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 21:57:15 ] スーパーコンピュータTop500、IBMが依然トップ。日本勢はトップ10圏外に www.itmedia.co.jp/news/articles/0706/27/news099.html プロセッサ別で見ると、Intelプロセッサ搭載システムが57.8％を占めた。 前回の52.5％よりもわずかに増えている。次に多かったのはAMDで21％、 前回の22.6％からは減少した。IBMのPowerプロセッサは17％だった。 また、デュアルコアプロセッサ搭載システムが増えており、 IntelのWoodcrest搭載システムは前回の31台から205台に、 デュアルコアOpteron搭載システムは75台から90台に拡大した。 767 名前：デフォルトの名無しさん [2007/06/27(水) 23:16:43 ] >>760 ＞ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば 馬鹿じゃねーのか？シャドーレイなんて飛ばす必要ないぞ。 ＞負荷も比例するのはレイトレも同じ 大雑把に、レイトレの負荷はピクセル数に比例する。 光源数やシャドーの数には影響されない。 ＞おまけにレイトレは動的シーンに致命的に弱い そりゃ今はレンダリング速度が遅いだけだ。 1/60秒で描画できるようになったら、逆転する。 768 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 23:29:10 ] シャドーｗｗｗｗｗｗｗｗｗ 769 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 23:34:49 ] そうなんだよね、折角「ラスタスキャンだとデータ量が増える」からとベクタデータになった処理が、 「解像度が上がるとベクタデータは級数的に増える」からと結局ラスタデータになったりしているしね。 尤も、今や8000x8000なんて画像のフィルタリング処理がオンメモリでできるからこそだけれども。 770 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 00:11:21 ] >>767 > シャドーレイなんて飛ばす必要ないぞ。 素人か？1次レイ飛ばすだけでは影は出来ないってのも分からんのか？ 誰もラジオシティの話なんてしてねぇぞ > 大雑把に、レイトレの負荷はピクセル数に比例する。 > 光源数やシャドーの数には影響されない。 レイトレの負荷が解像度に比例するのは当たり前 光源数が増加してもレイトレは計算量が変わらないとでも思っているのか？ 確かにラスタライザはレイトレと比較すれば光源1個あたりのコストが高いが 現状最速のコヒーレントレイ技法であるDeferred Shadingを使えば RTRTが可能なほど高速なハード上では、それ以上に高速に動く（＝より高い複雑度のシーンを扱える） > 1/60秒で描画できるようになったら、逆転する。 ラスタライザが生成するコーヒレントレイの圧倒的な速度と効率性という前提がある以上 繰り返すがRTRTが可能なほど高速なハード上では、ラスタライザはより高速に動作する インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かるが 大方の研究者の云う通りレイトレそれ自体がラスタライザを消し去ることはあり得ない 771 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 00:13:13 ] レイトレーシングのスレはここですか？ 772 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 00:41:58 ] いちおうGPGPUネタではある。 773 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 05:06:41 ] ヲタゲーCGはもうお腹一杯。 もっと単純に、天文物理の多体問題を解くみたいな GRAPEや地球シミュレータとの比較で頼む。 774 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 07:00:51 ] Grapeは事実上の敗北宣言が出てたじゃん。 「価格辺り消費電力が大きい」とか微妙な逃げ口上つきで。 775 名前：デフォルトの名無しさん [2007/06/28(木) 12:27:32 ] >>770 ＞誰もラジオシティの話なんてしてねぇぞ 俺はしている。ラジオシティ使わずに、レイトレでソフトなライト処理は不可能だ。 776 名前：デフォルトの名無しさん [2007/06/28(木) 12:46:31 ] >>770 ＞RTRTが可能なほど高速なハード上では、それ以上に高速に動く（＝より高い複雑度のシーンを扱える） とは限らない。 例えば、ラスタライザ型では膨大な量の半透明の処理を「完全」に正しく処理するのは非常に困難。 PowerVRのような方法を使えば完全にできるのだが、タイル(チャンク)を細かくしたらレイトレ型と同じだ。 第一、一次レイに限定していないし、それ以上で作られる品質をラスタライザ型で作るのは不可能。 ラスタライザ型で表現できる品質レベルで言えば、そりゃRTRTが可能なハードで上で、 それ以上に高速に動くのはあたりまえ。そんなことは小学生でもわかるわ。 人間が考えうる高品質の画像を作っていく上で、無限の計算力があるなら、 ラスタライズ型の処理なんてあり得ない。 所詮、計算力が十分になるまでの、その場しのぎ、誤魔化しの手法にすぎないんだよ。 RTRTが可能になれば、ラスタライザは死滅する。パレットによるタイリング手法が死滅したようにね。 777 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 13:48:46 ] 非リアルタイムのアニメ映画でさえもRTはそれほど使われてないんだが・・・ 778 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 14:45:23 ] とりあえずレイトレしなくてもいいからオフラインレンダラ並の アンチエイリアスできるようになってから話しろよ 779 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 15:23:10 ] >>777 その通り スキャンラインラスタライザは現在でも多数のオフラインCGで使用されている まぁ>>776みたいな信者はオノレの信じたいことだけを信じる現実の見えない典型的な馬鹿だから せいぜい海外の論文でも崇拝しながらRTRTをこのまま妄信し続けてもらいたいね Larrabeeが出たら是非RTRTを実装してもらいたい もっとも同時期の最新GPU上で動く最新デモの足元にも及ばんだろうが 品質の面でも解像度の面でもな 780 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 15:28:11 ] > 無限の計算力があるなら この前提も妄想だな そもそも現在の半導体のドミナントデザインたるCMOSは 20nmプロセス前後で限界を迎えるという事実をお忘れか？ 781 名前：デフォルトの名無しさん [2007/06/28(木) 16:02:26 ] >>780 忘れてないよ。でも、技術の発達により、膨大な計算量が扱える方向に進むのだから、 究極的にはどこを目指すかという点で、無限の計算力があるときどうなるかを考えることは無意味ではない。 ３０年後のＣＰＵのスペックはどのレベルか考えてみるのもいい。 １００コア程度なら２０１０年前後で投入してくるだろうし。 782 名前：デフォルトの名無しさん [2007/06/28(木) 16:07:50 ] >>779 ＞品質の面でも解像度の面でもな 鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、 ポリゴンラスタライズ型が勝てるとでも思ってるの？ 想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。 783 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 16:13:04 ] > 鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、 > ポリゴンラスタライズ型が勝てるとでも思ってるの？ > 想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。 「鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングする」ことなんてのはまさに 「想定している品質や分野を意図的に制限す」ることだわな 自己矛盾にすら気付かん馬鹿ですね 相手するだけ時間の無駄か 784 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 16:24:45 ] だいだい反射や屈折等のインコヒーレントレイに関しては>>770で 「インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かる」と言っているだろう レイトレとラスタライザが「完全に」同調してレンダリングできる時点で コヒーレントレイをレイトレで処理するなんてのは馬鹿馬鹿しいにも程がある まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより 高速に描画できるとでも思っているのか？ 785 名前：デフォルトの名無しさん [2007/06/28(木) 16:34:55 ] >>783 ＞「想定している品質や分野を意図的に制限す」ることだわな だから、それを言っているのだが。 矛盾ではなく、そういう例を出しているのが読めない馬鹿か？それとも意図的に誤読しているのか？ 本気で俺が「制限すること」でないと思って書いていると思うなら、お前は読解力がない。 786 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 16:56:42 ] >>785 横レスだけどそんな皮相的な反応されても・・・ 「意図的に制限すれば何とでもいえる」を批判の言葉として用いているということは、 「より制限の緩い、一般的な用途でRTの方が優秀である」という主張を内包している としか思えないわけだけど、 「鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングする」という、 これまた意図的に制限された状況を持ち出しているのが矛盾だということ。 という流れなんじゃない？ Ice Age のスタッフがRTサイコーって言ってたよとか、そういう実分野での応用に ついて検証するしかないんじゃないかな。 787 名前：デフォルトの名無しさん [2007/06/28(木) 17:20:19 ] >>786 ＞「より制限の緩い、一般的な用途でRTの方が優秀である」という主張を内包している ＞としか思えないわけだけど、 そうではなく、膨大な計算量が使える環境で、 どのシーンにも使える究極の品質を目指すならＲＴ以外は論外って事。 ポリゴンラスタライズ型は、計算量が乏しい環境で、 上手く誤魔化す程度の品質においてアドバンテージがあるだけだ。 現状の計算機環境、要求品質でポリゴンラスタライズ型を否定しているわけではない。 が、そう遠くない将来、ＧＰＵもポリゴンラスタライズも死滅する。コプロがＣＰＵに取り込まれたように。 788 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 17:55:12 ] 「膨大な計算量」を何に使うかはデザイナやアーティストが決めるんじゃないかな。 789 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 18:08:20 ] >>787 俺の質問に答えろよ > まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより > 高速に描画できるとでも思っているのか？ 一連のお前の発言からすると、コヒーレントレイはレイトレで描画してもラスタライザで描画しても 『数学的に完全に等価である』という大前提をお前は知らない/理解していないようだな 純粋に両者のアルゴリズムの本質(nature)により、コヒーレントレイの描画で レイトレがラスタライザを速度で上回ることなど （お前がいくら期待しようが）あり得はしないんだよ あるとすれば、それは非本質的な部分がボトルネックになっているに過ぎない ゆえにコヒーレントレイの描画でレイトレがラスタライザを駆逐することなど起こりはしない お前の「そう遠くない将来、ＧＰＵもポリゴンラスタライズも死滅する」という主張は 全くもって希望的観測に基づいたドグマだ 重要なのはいかに同時期の市場情勢や需要に適合するかであって シンプルで正確な技術が必ずしもスタンダードとはならないことは歴史が証明している 790 名前：デフォルトの名無しさん [2007/06/28(木) 18:40:09 ] >>789 ＞> まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより ＞> 高速に描画できるとでも思っているのか？ だから、俺はそんなことは言ってないだろ。 コヒーレントレイに限るなら、想定している品質や分野を意図的に制限しているといっているだけだ。 ＞シンプルで正確な技術が必ずしもスタンダードとはならないことは歴史が証明している シンプルで正確な技術がどっちのことを言っているのか知らんが、 将来のポリゴンラスタライズについても同様のことが言えるな。 ＲＴＲＴのゲームも出てきていることだし、 ＣＰＵパワーの使い道としても俺はＲＴＲＴの今後の発展に期待する。 どっちが残るかなんて歴史が証明すればいいし、今拘る気はない。 ＧＰＵとラスタライズが死滅する方が新しい発展があって面白そうだから、 俺が勝手に思っているだけでいいよ。 791 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 18:45:20 ] ttp://www.hc.ic.i.u-tokyo.ac.jp/~kaki/SIGGRAPH2002/Panel_RT_vs_RAS.html 792 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 19:52:56 ] GPUとラスタライザが死滅するほうが新しい発展があるって思える根拠に興味が 793 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 19:56:39 ] 思ってるだけでいいならだらだらと書き下すなと 794 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 20:22:54 ] GPUの応用研究で食おうと思ってたらLarrabeeが出て人生オワタような必死さですね 795 名前：デフォルトの名無しさん [2007/06/28(木) 20:29:52 ] 別にLarrabeeなり、CPUベースのレイトレなり、新しいものに期待をかけるのはいいと思うが、 なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。 GPUがなくなるとかラスタライズが死滅するとかは妄想に過ぎんかもしれんが、 そこに新しい技術の種があるかもしれないのに。 本当に死滅するならそれはそれでいいし、死滅しないとしてもそういう別のベクトルが 頑張るのはいいことだと思うぞ。妄想が原動力ならそれでもいいじゃないか。 796 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 20:31:27 ] ＞なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。 「Intel にとって良いことは、コンピュータ業界にとって良いことだ」から 797 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 20:34:42 ] >>795 2chで吠えてないで結果を出せってことだろ。 798 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 20:42:01 ] LarrabeeもTeslaもPCI-Eカードの時点で終わってる CPUに統合されない限り可能性はない 799 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 20:56:15 ] 今現在結果を出そうとすることすら叶わないLarrabeeへの皮肉ですか 800 名前：デフォルトの名無しさん [2007/06/28(木) 21:10:20 ] このスレを一通り眺めて思ったこと。 CPUも互換性を考えなければすっげ早くなるのだろうか。 801 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:17:40 ] >>800 それなんてCell？ 802 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:21:15 ] CPUに統合されても可能性はない 803 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:22:24 ] 誰かが20nmの壁を書いていたけれど、それを忘れてないと書きつつ100コアとか書いちゃうのが信じられない。 そしてまさしくその壁と戦っている人達が、実際にGPGPUにもLarrabeeにも興味を持っているわけなのだが。 804 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:33:56 ] >>798 メモリ事情を考えろ pc.watch.impress.co.jp/docs/2007/0131/kaigai332.htm media.arstechnica.com/news.media/larrabee-pci.gif 805 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:38:58 ] つか俺的には何FLOPSとかどうでもいいからメモリのレイテンシを改善しろと言いたい。 お前ら何年間横這いなんだよ、と。 806 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 21:58:53 ] >>805 急に言われてもメモリも困る。 ちゃんとプリフェッチされるようなコードを書けば良い。 807 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 22:07:50 ] コードについて以外のことについてぐだぐだ書くのはやめろよ。 板違いだ。 自作板にでもスレッド立ててやれば良いだろ。 808 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 22:14:10 ] >>807 最近多いよな こういう多分野にまたがって統合的にものが考えられない奴 809 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 22:25:33 ] >>808 どっかのいいかげんなwebサイト仕込みのネタをの適当に口まねするのが 「総合的にものを考える」ことかよｗ　アホくさ。 810 名前：デフォルトの名無しさん mailto:sage [2007/06/28(木) 23:49:45 ] スレのびすぎ 811 名前：デフォルトの名無しさん mailto:sage [2007/06/29(金) 00:43:52 ] で、GPGPUで犬を洗えるようになるのか? 812 名前：デフォルトの名無しさん mailto:sage [2007/06/29(金) 00:48:03 ] >>804 考えた amb.sakura.ne.jp/hanyou/img-box/img20070611224306.jpg 813 名前：デフォルトの名無しさん [2007/06/29(金) 01:41:37 ] >>803 １００コアの話はインテルのロードマップのことだろ。あっちでは数百コアって書いてあったけど。 814 名前：デフォルトの名無しさん mailto:sage [2007/06/29(金) 12:21:39 ] >>812 CSIが細くて笑った。 データの入りと出だけだから問題ないの･･･か？ 815 名前：・∀・）っ-○◎● mailto:sage [2007/06/30(土) 00:37:10 ] 要するにNUMAでしょ CPU間のCSIはコヒーレントバス的に使って、たまに他のノードのメモリにアクセスする感じでは。 816 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 12:03:02 ] ものすっごい初歩的な質問なのですが for(int i=0;i<1024*1024;i++){ 何か作業 } の、何か作業をGPUに任せるのって プログラム側からシェーダに対して どういうコードを描けばいいのですか？Cgで 817 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 14:40:47 ] >>816 つ[cuda] 818 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 15:05:34 ] CUDA使えるGPUではないので無理です ナニを読んだりググれば出てきますか？ 819 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 15:58:30 ] Cgで普通のグラフィックのプログラム書いた経験はある？ 820 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 16:19:54 ] 今やろうとしているのが、まさにCgで普通のグラフィックプログラムやろうとしてるのですが どうもわからなくて はじめにどこ見ればいいですか？ 821 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 16:33:15 ] >>820 まずは鏡を見て「俺はなんて馬鹿なんだろう」と気付くことから始めよう。 822 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 16:33:58 ] そうですね、バカだと思います 823 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 16:52:22 ] もう来ません＞＜ 824 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 17:03:34 ] ぼくもやりたーい 　　　　　　　　　　　　　　　　　┌─┐ 　　　　　　　　　　　　　　　　　｜も.｜ 　　　　　　　　　　　　　　　　　｜う　| 　　　　　　　　　　　　　　　　　│来│ 　　　　　　　　　　　　　　　　　│ね│ 　　　　　　　　　　　　　　　　　│え .| 　　　　　　　　　　　　　　　　　│よ .| 　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ　　│ !!.│ 　　　　　　　　　　　　　　　　　└─┤　　　　ﾌﾟﾝﾌﾟﾝ 　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　 （　`Д） 　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U 〜 〜　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎−>┘◎ 825 名前：デフォルトの名無しさん [2007/06/30(土) 21:31:04 ] GPGPU.ORG 826 名前：デフォルトの名無しさん mailto:sage [2007/06/30(土) 23:58:24 ] 普通のグラフィックプログラムでループを1000回も回すことがあるのか ちょっと興味あるな 827 名前：デフォルトの名無しさん [2007/07/01(日) 01:37:45 ] 1000回じゃなくて百万回では？ 828 名前：デフォルトの名無しさん mailto:sage [2007/07/01(日) 04:45:32 ] 数百万ループって・・・ どんだけ広い空間を定義する気なんだ・・・ 829 名前：デフォルトの名無しさん mailto:sage [2007/07/01(日) 04:52:17 ] 別に広さの問題ではないと思うけど 830 名前：デフォルトの名無しさん mailto:sage [2007/07/01(日) 05:32:31 ] >>826 単に1024×1024のテクスチャの各ピクセルに対して同じ「何か作業」をしたいだけだろ 831 名前：デフォルトの名無しさん mailto:sage [2007/07/01(日) 17:03:08 ] そんな低レベルというか基本中の基本のことを他人に聞く ような神経が考えられない。ゆとりか？ 832 名前：デフォルトの名無しさん mailto:sage [2007/07/01(日) 21:10:16 ] 基本中の基本は どこを調べたら出てくるんですか＞＜ 833 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 11:02:30 ] >>832 >825 834 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 16:33:11 ] ジャパニーズで教えてください＞＜ 835 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 16:40:38 ] つ[excite翻訳] 836 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 17:10:10 ] 英語読めないとかどんな低学歴… 837 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 19:29:34 ] NVIDIA最強 pc.watch.impress.co.jp/docs/2007/0702/kaigai369.htm 838 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 19:35:27 ] >837 お前個人は貧弱だけどな 839 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 19:44:34 ] 一人一人は小さな火だが 840 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 19:44:39 ] なんでわかった？ 841 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 20:31:55 ] なんだよ、お前らみんな英語読んでやってるってのかよ！ このバカバカマンコ！！！！ お前らなんかチンコの皮をチャックに挟んでしんじゃえ！！！ 早く、GPUでのプログラミング教えろよ！ 842 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 21:44:38 ] 英語が嫌ならDirect3Dの日本語ドキュメントとかでHLSLとか勉強して、それをグラフィックス以外の用途に使えばいいやん 843 名前：デフォルトの名無しさん mailto:sage [2007/07/02(月) 23:32:53 ] ゲフォ8600とか買ってCUDAするのがよろしいかと 844 名前：デフォルトの名無しさん mailto:sage [2007/07/03(火) 10:33:42 ] 8600GTSなら3万弱、8600GTなら1万円台中頃かな。 最早CUDA以外を勧める理由がないよ。 845 名前：デフォルトの名無しさん [2007/07/03(火) 12:59:22 ] CUDAで使えるjava処理系だせや>えぬびでぃあ 846 名前：デフォルトの名無しさん mailto:sage [2007/07/03(火) 14:19:49 ] >>844 x64やVistaに対応していないし、しそうにもない現状を考慮してもか？ 流石に痛すぎるだろ・・・。 847 名前：デフォルトの名無しさん mailto:sage [2007/07/03(火) 14:35:40 ] >>846 需要があれば出すでしょ。現状、TeslaはLinuxをメインにしているようだからね。 #Linuxならx64もあるわけで。 848 名前：デフォルトの名無しさん mailto:sage [2007/07/03(火) 21:52:20 ] >>837 AMD K10最強 www.amd.com/us-en/Processors/ProductInformation/0,,30_118_13223,00.html?redir=CPBM01

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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