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/ 285 名前：デフォルトの名無しさん mailto:sage [2006/08/04(金) 18:49:12 ] GPUはあと3年もすればコプロセッサという名前になります。 286 名前：デフォルトの名無しさん mailto:sage [2006/08/04(金) 19:35:23 ] AMDにそんな業界を作り変える力は無いぞｗ 287 名前：デフォルトの名無しさん [2006/08/04(金) 22:00:29 ] intelとnVidiaはどうするんだろう？ 288 名前：デフォルトの名無しさん mailto:sage [2006/08/05(土) 02:36:55 ] Intelは業界１位のグラフィックスチップメーカー＆CPUメーカー nVIDIAは業界１位の単体グラフィックスチップメーカー AMDは、グラフィックスチップ部門を持たないメーカー＆２位のCPUメーカー ATiは、業界２位の単体グラフィックスチップメーカー どう考えても、AMDとATiが組んだところでそんな業界の仕組みを変えれるとは思えない。 ２位同士が組んでどうやって１位同士が確立しているシステムを潰すってんだ。 289 名前：デフォルトの名無しさん mailto:sage [2006/08/05(土) 20:00:12 ] 最終的にはIntelがそういう流れを決定付ける。 290 名前：デフォルトの名無しさん [2006/08/15(火) 22:50:30 ] まあな 291 名前：デフォルトの名無しさん mailto:sage [2006/08/16(水) 02:06:00 ] GPGPUで動画のエンコードとか聞いたけどさ そういう前後の依存関係が関係する処理ってGPUで出来るの？ 一旦、処理した内容をメインメモリに戻して、その結果を元に次の処理って事をしないといけないと思うんだけど・・・。 292 名前：デフォルトの名無しさん mailto:sage [2006/08/16(水) 02:51:53 ] 動画圧縮における「前後フレームとの依存関係」と アルゴリズムにおける「データの依存関係」は違う。 293 名前：デフォルトの名無しさん mailto:sage [2006/08/27(日) 04:43:49 ] GPGPU的Hello Worldとして何から手をつければいい？ ちなみに現時点でGPGPUについては概要しか知らないんだが。 294 名前：デフォルトの名無しさん mailto:sage [2006/08/27(日) 07:27:52 ] ハロワルは視覚的にわかるものが好ましいから 適当なテクスチャデータ→GPU→ピクセルズーム→メインメモリ→BMP出力 こんな感じでどうよ？ 295 名前：デフォルトの名無しさん mailto:sage [2006/08/27(日) 15:29:09 ] >>293 www.gpgpu.org/developer/#tutorial www.gpgpu.org/w/index.php/Brook#Installing_Brook このスレで Hello World の話題が出たことあるんだから、それを踏まえた上での質問をして欲しいものだが。 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コアとの統合を考えてるんだろ？ そうなった場合、どうせどこかで命令セットが共通化するんだから(しなかったら終わってる) 最初からそういう機関を作っとけよ。

---

---

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

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