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/ 296 名前：デフォルトの名無しさん mailto:sage [2006/08/27(日) 18:12:14 ] ATIのGPUがFolding@homeに参戦 slashdot.jp/articles/06/08/27/0239247.shtml こういうのが本命かな 297 名前：デフォルトの名無しさん [2006/09/09(土) 15:59:23 ] ttp://channel9.msdn.com/wiki/default.aspx/Accelerator.HomePage Accelerator provides a high-level data-parallel programming model as a library that is available for all .Net programming languages. The library translates the data-parallel operations on-the-fly to optimized GPU pixel shader code and API calls. Future versions will target multi-core cpus.. 298 名前：デフォルトの名無しさん mailto:sage [2006/09/10(日) 01:35:24 ] >>297 ぱっと見ではプログラム中の一部の処理をピクセルシェーダに置き換えられるようにしただけに見えるんだが どうも要領を得ないので読み直すか 299 名前：デフォルトの名無しさん mailto:sage [2006/09/11(月) 00:48:37 ] ttp://www.shader.jp/xoops/html/modules/wordpress/index.php?p=326 300 名前：デフォルトの名無しさん mailto:sage [2006/09/20(水) 11:11:02 ] www.gpgpu.org/ が見えないんだけど、どうしちゃったんだろ？ 301 名前：デフォルトの名無しさん [2006/09/26(火) 19:47:06 ] journal.mycom.co.jp/articles/2006/08/01/siggraph01/004.html DX10では今までと比べ物にならんほど汎用性が増すみたいだね。 302 名前：デフォルトの名無しさん mailto:質問age [2006/09/28(木) 22:51:28 ] 浮動小数点数のバッファに1.0より大きな値を記録する事は出来ないのでしょうか。 試してみたら1.0で飽和されてしまって。 303 名前：デフォルトの名無しさん mailto:sage [2006/09/29(金) 08:49:41 ] シェーダー言語使ってるかどうかとか、情報少なすぎ。 どっかで8bitとかのフォーマットに変換されてたりするんじゃないか？ 304 名前：302 mailto:sage [2006/09/29(金) 12:27:41 ] >>237を元にしてD3DFMT_R32Fを使いテクスチャを2枚にして ps_1_1 tex t0 tex t1 add r0, t0, t1 してます。 結果が1.0以下になる演算では小数で解が得られているので 8bitに変換されているというより1.0で飽和しているという印象を受けました。 305 名前：302 mailto:sage [2006/09/29(金) 16:04:33 ] ps_2_0 dcl t0 dcl_2d s0 dcl_2d s1 texld r0, t0, s0 texld r1, t0, s1 add r0, r0, r1 mov oC0, r0 にしたら上手くいっているようです。 2枚のテクスチャを加算するピクセルシェーダのコードはこれで間違いないでしょうか。 306 名前：デフォルトの名無しさん mailto:sage [2006/09/30(土) 01:13:47 ] 俺の持っているのは DX9 のだが、マニュアルの [DirectX Graphics] - [リファレンス] - [シェーダ リファレンス] - [ピクセルシェーダ 1_X] - [レジスタ ps_1_X] と [DirectX Graphics] - [リファレンス] - [シェーダ リファレンス] - [ピクセルシェーダ 2_0] - [レジスタ ps_2_0] のテンポラリレジスタのところでレジスタ精度を見てみると、ps 2.0 は浮動小数点数だが、ps 1.1 は D3D8CAPS.MaxPixelShaderValue を上限とする小数部 8bit の固定小数点数の可能性があることがわかる。 君の持っているカードもわからないのに、何故具合が悪かったかなどわかりようもないが、305 のコードは合ってる。 307 名前：デフォルトの名無しさん [2006/11/09(木) 19:24:06 ] pc.watch.impress.co.jp/docs/2006/1109/kaigai316.htm 308 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 08:31:59 ] >>307 これで、おれのようなへっぽこコード書きでも使えるようになった。 309 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 12:33:04 ] Geforce8800GTXのSLIで1TFlopsが30万円くらいだしすげーよな。 はやく開発環境ほすぃ 310 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 15:54:43 ] ここまでくると、もうGPGPUとは呼べないよね。 311 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 17:01:11 ] 今までシェーダーでやってた人が馬鹿みたい メモリー周りはどうなってるのかな？ 312 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 17:11:54 ] そんなことよりもなぁ、演算プロセッサボードで作ってた連中が不憫で不憫でw 313 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 17:14:11 ] あーもう要らないね、GPU内で全部計算できるし、転送しなくてすむし。 グラフィック以外の計算にも使えそうなキガスルがどうだろう。 314 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 17:17:43 ] >>313 フーリエ変換に使えないか、調査予定。巧くすれば、プロセッサボード屋に払う分をこっちの仕事にできそうな希ガス。 315 名前：デフォルトの名無しさん mailto:sage [2006/11/11(土) 18:13:55 ] GPU内でDSP的でない処理がモリモリできるのであれば、 メインメモリとの転送量も少なくできるかな。 もしそうなら、x16じゃなくてx1レーンに沢山のっけてもいいかも。 できるかどうか知らんけど妄想。 316 名前：デフォルトの名無しさん mailto:sage [2006/11/12(日) 18:44:29 ] Cで扱えるようになるっていうのは、ハードウェア的な新機能なの？ 旧型のGPUも、ドライバーで扱えるようになるのかな？ 317 名前：デフォルトの名無しさん mailto:sage [2006/11/12(日) 19:10:51 ] GPUのアーキテクチャーが大きく変わったことでCでプログラミングできるような 構造となった。だからコンパイラー付き よって旧型チップじゃ使えないよ。 318 名前：デフォルトの名無しさん mailto:sage [2006/11/12(日) 20:08:45 ] なるほど・・・、THX ドライバ側っつーか、ライブラリ側でかなーり頑張れば旧GPUも対応出来そうな感じもするんだけどなぁ。 もちろんパフォーマンス的なものが変わってくるだろうけど。 319 名前：デフォルトの名無しさん mailto:sage [2006/11/12(日) 20:36:07 ] 無理。 320 名前：デフォルトの名無しさん mailto:sage [2006/11/12(日) 20:54:48 ] これってやっぱ単精度なんだよね？ 321 名前：デフォルトの名無しさん mailto:sage [2006/11/13(月) 14:13:59 ] ちゃんと嫁よ プロセッサ内蔵してそこが実行してるんだから旧も新もあるか。 322 名前：デフォルトの名無しさん mailto:sage [2006/11/14(火) 23:08:50 ] >>320 （独自）Cコンパイラ使えます けどdouble使えません 単精度浮動小数演算器に桁上げ回路？くっつけて できないのかねぇ？ ソフト的にやったら性能ガタ落ちだろうし。 323 名前：デフォルトの名無しさん mailto:sage [2006/11/14(火) 23:37:33 ] www.4gamer.net/news/history/2006.11/20061113170123detail.html CUDAの詳細どぞ。 324 名前：デフォルトの名無しさん mailto:sage [2006/11/15(水) 10:26:20 ] ほんと今までグラフィック屋さんでもないのにCgいじくってひーひー言ってたのがｳﾞｧｶみたい… まぁ、8800は素直にすげーと思うけど 325 名前：デフォルトの名無しさん mailto:sage [2006/11/15(水) 11:06:38 ] これもGPGPUですか？ www.itmedia.co.jp/news/articles/0611/14/news102.html 326 名前：デフォルトの名無しさん mailto:sage [2006/11/15(水) 19:37:40 ] ソフトウェアレンダとハードウェアレンダの境目が取っぱらわれるわけでもないのかな? とりあえずこの傾向が進めば、GPUの扱いは Cバス用のPC-9801-16に乗ったMC68kみたいになるわけだな。 327 名前：デフォルトの名無しさん mailto:sage [2006/11/15(水) 20:08:42 ] ソフトレンダはdoubleで計算してるからねぇ。 floatでレイトレったらすごい結果になるしｗ 328 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 18:17:32 ] Mpegのエンコードにおける、動きベクトルの算出に GPUが使えたらと考えています。 参考になるようなサイト等ありましたら教えてください。 329 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 04:54:51 ] GPGPUなMP3エンコーダー作ってください 330 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 08:20:07 ] www.kvraudio.com/forum/viewtopic.php?t=153073 こんなのきたよ GPGPUでサウンド用DSP的なことをやるみたい。 この場合はDelayだけだけどｗ 331 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 10:23:22 ] オフセットしてaddするだけやん！ 332 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 13:11:45 ] CUDAがでてきたから来年にはGPGPUの状況も変わるかもね。 333 名前：デフォルトの名無しさん mailto:sage [2006/12/06(水) 00:15:51 ] うちの大学で、GPUでレイトレやってる人がいる・・・・ 334 名前：デフォルトの名無しさん mailto:sage [2006/12/06(水) 21:37:13 ] レイトレなんて久しぶりに聞いた単語だ。 335 名前：デフォルトの名無しさん mailto:sage [2006/12/06(水) 23:46:12 ] >>333 一昨年俺がやったぜ GeForce6シリーズなら十分 SM2.0だとループができないから 6800GT初売りに予約して買った。 研究費だけどね。 今だと、海外もボコスカ論文出てるから 新規性アピールするのむずいかな。 あ、研究とは言ってないのか 336 名前：デフォルトの名無しさん mailto:sage [2006/12/07(木) 13:15:17 ] ごめん、GPUじゃなくて、PPUっぽい・・・ 337 名前：デフォルトの名無しさん mailto:sage [2006/12/07(木) 14:57:30 ] GPUPPURか d.hatena.ne.jp/gpuppur/ 最近進捗ないけどどうなんだろうね。 338 名前：デフォルトの名無しさん mailto:sage [2006/12/07(木) 23:02:24 ] ファミコンのPPUを演算に使うのは難しそうだけどな。 339 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 00:54:33 ] ソフト的に倍精度の研究やってる俺がきました 2007年後半にハード的に実装されるみたいですねー 340 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 21:46:48 ] >>337 レイトレーシングでStanford bunnyとかレンダリングできるけど、遅い。 341 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 00:59:27 ] >>339 あの，大変申しにくいのですが 今年のSIGGRAPHのポスターでドンピシャなのが… Extended-Precision Floating-Point Numbers for GPU Computation cs.allegheny.edu/~thall/ 悪気はないんです，担当教官から言われるよりはよっほどマシだと思いますし． 頑張ってください 342 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 01:36:50 ] >>342 俺ｵﾜﾀ＼(＾o＾)／ 343 名前：デフォルトの名無しさん mailto:sage [2006/12/12(火) 01:48:58 ] 読んできました。 難しい内容じゃないし誰かがやっててもおかしくないですよね 近々中間発表があるのでそれまでになんとかしないと・・・ 情報提供ありがとうございましたm(_ _)m 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 の話題も面白そうだけど、他のプロセスなりスレッドとのユニットの取り合いとかも考えるとやってらんないね。

---

---

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

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