[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 07/04 21:41 / Filesize : 200 KB / Number-of Response : 849
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/


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でレイトレったらすごい結果になるしw

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だけだけどw

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なのでインストールしただけw)

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
手抜きするなーw
外側のループもはずせるだろ。

いや、面倒だから俺はやらないけどなw
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
あれは殆どマイクロソフト主導じゃん
MSの戦うプログラマの人が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をプログラマに管理させたりしてw
まぁ、コンパイラが勝手にやってくれるんじゃないかな。
それ以外の場所は、一般的なクラスタリングシステムみたいにやってくれるって事はないと思われ
そういうことは研究されてるけど、まだまだ一般的なコンパイラ1発でやってくれる仕組みは完成しているとは言いがたい。
最適な粒度をコンパイル時に調べてくれるとかやっても、別環境で実行する場合変わるしなぁ。





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

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

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

398 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:27:13 ]
日本語でおk

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

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

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

400 名前:デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:58:53 ]
朝鮮語でおk

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】
http://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はソフト作る気にもならないのでライブラリ充実待ち。






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<200KB

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