- 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/
- 2 名前：デフォルトの名無しさん [2005/10/08(土) 23:18:48 ]
- ２
- 3 名前：デフォルトの名無しさん mailto:sage [2005/10/08(土) 23:23:53 ]
- メモリーに関してはだんだんスパコンのアーキに近づいてるからなぁ。
- 4 名前：デフォルトの名無しさん mailto:sage [2005/10/09(日) 03:46:05 ]
- ラデX1800のようにメモリレイテンシをあまり気にしなくていいというのは羨ましいな
- 5 名前：デフォルトの名無しさん [2005/10/09(日) 11:50:01 ]
- ShとBrook期待age
- 6 名前：デフォルトの名無しさん [2005/10/09(日) 13:11:52 ]
- CPU→GPU→CPUって経路でデータ流せるんだっけ?
- 7 名前：デフォルトの名無しさん mailto:sage [2005/10/09(日) 14:06:12 ]
- 出来なかったら、画面のキャプチャーとか出来ないだろ。
- 8 名前：デフォルトの名無しさん mailto:sage [2005/10/09(日) 17:05:54 ]
- 今現在、計算結果を持って帰るには一度フレームバッファに書いたのを吸い出すしかない。
今後改善されるとは思うけど、これじゃあ使えねぇよ。
でもXBOX360はメインメモリに直接アクセスする方法が用意されているらしい。
実用段階になったら、まずはトリップ計算機から誰か作ってよ。
- 9 名前：デフォルトの名無しさん mailto:sage [2005/10/09(日) 17:21:09 ]
- >>8
ソース公開してる奴ってどれ？＞計算機
ちとやってみたい
- 10 名前：デフォルトの名無しさん mailto:sage [2005/10/10(月) 14:05:01 ]
- これからはJavaやC#のようなオブジェクト指向言語をベースに
速度が重要な部分はシェーダー(GPGPU)でなんて流れになるのでしょうか？
- 11 名前：デフォルトの名無しさん mailto:sage [2005/10/10(月) 14:58:23 ]
- なりません
- 12 名前：デフォルトの名無しさん mailto:sage [2005/10/11(火) 14:13:56 ]
- GPGPUって過渡的なものであって、今後はXbox360/Cellに代表される
ヘテロジーニャスなマルチコアプロセッサの流れだろうな
- 13 名前：デフォルトの名無しさん mailto:sage [2005/10/11(火) 14:43:51 ]
- 360はホモ臭い
- 14 名前：デフォルトの名無しさん mailto:sage [2005/10/11(火) 15:22:02 ]
- あぁたしかに360はハードウェアアーキはホモだけど、ソフトウェアアプリで
ヘテロっぽく使うんだった.
- 15 名前：デフォルトの名無しさん mailto:sage [2005/10/11(火) 20:31:37 ]
- 小泉風に言えばGPUでできることはGPUに、CPUでなければいけないところはCPUでってこと？
- 16 名前：デフォルトの名無しさん mailto:sage [2005/10/11(火) 21:53:02 ]
- その言い方だと今までのアプローチとなんら変わらんがな
- 17 名前：デフォルトの名無しさん mailto:sage [2005/10/11(火) 22:59:09 ]
- OpenGLとかで流行ったBASICにできることは（ｒｙ、Cでなければ（ｒｙと変わらんね。
- 18 名前：デフォルトの名無しさん mailto:sage [2005/10/11(火) 23:55:23 ]
- それって>>10と同じじゃね？
- 19 名前：デフォルトの名無しさん [2005/10/12(水) 00:04:04 ]
- 未だにオブジェクト指向と速度を関連させる奴がいるのか。
- 20 名前：デフォルトの名無しさん mailto:sage [2005/10/12(水) 00:24:44 ]
- JavaやC#が速いとはあんまり思えないけどな
- 21 名前：デフォルトの名無しさん [2005/10/13(木) 21:17:35 ]
- age
- 22 名前：デフォルトの名無しさん mailto:sage [2005/10/13(木) 21:32:40 ]
- 情報が少なすぎて。。
- 23 名前：デフォルトの名無しさん [2005/10/15(土) 00:38:51 ]
- RGBA8bitの32ビットフォーマットのテクスチャに対し、
各位置のビットが1のピクセルの個数を数える、見たいな処理って出来ませんかね。
Rの3ビット目が1のピクセルは150個、みたいな感じで。
RGBA4種類の個数とかだったら簡単に出来るんですが、
各ビット合計32個のデータを取り出す方法がおもいつかない。。
- 24 名前：デフォルトの名無しさん mailto:sage [2005/10/15(土) 08:50:52 ]
- >>23
8bit パレット画像として扱うとかどう？
二アレスとサンプリングにして。
１回に１チャンネルしか処理できないけど。
- 25 名前：デフォルトの名無しさん mailto:sage [2005/10/15(土) 12:41:23 ]
- >>24
やっぱり複数回に分けて処理するしかないですかねー。
せっかくデータをまとめたんだから、1度に処理できないかと考えたけど無理か。
- 26 名前：デフォルトの名無しさん mailto:sage [2005/10/15(土) 14:27:28 ]
- bsf・・・はx86だしな
- 27 名前：デフォルトの名無しさん [2005/10/23(日) 20:29:04 ]
- 保守
- 28 名前：デフォルトの名無しさん [2005/10/24(月) 02:06:59 ]
- JavaとGPGPUのコラボ最強と思ってるのはたぶん漏れだけ
- 29 名前：デフォルトの名無しさん mailto:sage [2005/10/25(火) 01:53:53 ]
- GPUは基本的にストリームプロセッサだからCPUのような複雑な
分岐や少量のデータ処理を多数行うような仕事だと効率悪い。
現実は厳しいよ。
- 30 名前：デフォルトの名無しさん [2005/10/25(火) 15:42:06 ]
- そういう仕事をGPUに投げるのが間違い。
- 31 名前：デフォルトの名無しさん mailto:sage [2005/10/25(火) 23:21:53 ]
- >>29
大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが
- 32 名前：デフォルトの名無しさん mailto:sage [2005/10/25(火) 23:39:54 ]
- C++とGPGPUこれ最強
- 33 名前：デフォルトの名無しさん mailto:sage [2005/10/26(水) 01:58:39 ]
- >>1
語りたい事もないのに糞スレ立てるな
- 34 名前：デフォルトの名無しさん mailto:sage [2005/10/26(水) 02:11:17 ]
- GPUってなんの計算をしてくれるのよ。
- 35 名前：デフォルトの名無しさん mailto:sage [2005/10/26(水) 08:52:24 ]
- ようはSIMD
- 36 名前：デフォルトの名無しさん mailto:sage [2005/10/31(月) 01:05:14 ]
- >>34
いまならシェーダーさえ書けばどんな計算だってしてくれる
向き不向きはあるが、膨大な量の単純計算繰り返しなら
最新のCPUよりもGPUのほうが早い
- 37 名前：デフォルトの名無しさん mailto:sage [2005/10/31(月) 01:16:46 ]
- 向き不向きなんてレベルじゃない。
かなりのレベルの並列性が無いとダメだし、入出力もかなり限定された形でしか出来ん。
どんな計算でもなんてとても言えん。
が、条件にはまる物ならばパフォーマンスの高さに驚く。
- 38 名前：デフォルトの名無しさん mailto:sage [2005/10/31(月) 01:28:46 ]
- 結局GPGPUの使いどころとしては画像処理(2D)・映像処理・音声処理あたりに落ち着くんでしょうかね
もともとGPUの得意分野だし
- 39 名前：デフォルトの名無しさん mailto:sage [2005/10/31(月) 01:39:01 ]
- 物理演算はねーの？？
- 40 名前：デフォルトの名無しさん mailto:sage [2005/10/31(月) 21:15:21 ]
- GPU演算での精度はどれぐらいまで期待できるんでしょうかね？
- 41 名前：デフォルトの名無しさん [2005/10/31(月) 22:43:58 ]
- 丸めの方向を制御できなかったり、なんていう困った点もあるみたいよ＞GPGPU
- 42 名前：デフォルトの名無しさん mailto:sage [2005/11/08(火) 00:19:25 ]
- 保守
- 43 名前：デフォルトの名無しさん [2005/11/13(日) 01:46:21 ]
- age
- 44 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 15:32:56 ]
- 発想としては面白いし、昔からこういうハードを本来の目的以外に使うって話は好きなんだけど
(キャラクタ表示機能しかないマシンでビットマップ表示とかFM音源でPCM多重再生みたいな）
なんかあんまり現実的に聞こえないんだけど。。
ハイエンドなGPUなんてゲーマー以外もってないじゃん。
CAD用のGPUなんてもっと少数派だし。
そのくせ、3d表示で使ってる間は当然使えないわけだろうし。
だいいち各GPUの違いを吸収する負担は誰が負うのよ。
CPUのマルチコア化の流れを受けてのことなのかな。
昔のコプロみたいにCPUの中にそういうGPU的なアーキテクチャを組み入れていこう、
って展望でもあるのか？
- 45 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 16:05:04 ]
- 3D表示使わないアプリで使えば無問題だし、
最近じゃハイエンドじゃなくてもシェーダが動く。
GPUの違いはシェーディング言語そのものでバージョン管理と、
そのラッパーであるライブラリで十分埋まる。
- 46 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 20:08:06 ]
- >>44
とても現状を理解しての発言には思えない。
- 47 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 20:15:55 ]
- PhysXもそろそろ出るね
CPU以外のパワーを利用するのって
一時的かと思ってたけど時代の潮流かな
- 48 名前：デフォルトの名無しさん mailto:sage [2005/11/22(火) 18:01:21 ]
- staraxis.kazelog.jp/okiraku/2005/11/atiavivo_49a9.html
ATIのAVIVOエンコード機能は凄い!!
DVD映像5分（720x480）をDivXやwmvにエンコードするのが25秒で終わるとか早すぎ！！！
GPGPUを使った物らしいです
- 49 名前：デフォルトの名無しさん mailto:sage [2005/11/22(火) 22:17:01 ]
- いや、Theaterっていう専用チップが乗ってるよ
www.4gamer.net/news.php?url=/news/history/2005.09/20050920190000detail.html
- 50 名前：デフォルトの名無しさん mailto:sage [2005/11/25(金) 12:27:04 ]
- FAQ - GPGPU.org Wiki
www.gpgpu.org/wiki/FAQ
- 51 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:05:32 ]
- GPU GEMS2の日本語版が出たようだ
www.shader.jp/xoops/html/modules/wordpress/index.php?p=166
- 52 名前：デフォルトの名無しさん [2005/11/29(火) 00:06:17 ]
- sageたままだった・・・orz
- 53 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:09:53 ]
- AGPメモリにフレームバッファ確保できなかったっけ？
- 54 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:22:55 ]
- >>10
Javaチップ、Javaアクセラレータ
なんてものがあるしな。
考えられなくもないな
- 55 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:24:29 ]
- >>19
むしろVMと速度だな。
C言語の中の人は
オブジェクト指向を使うと速度が遅くなる
から使わない方がいいとか未だにいっているからね。
- 56 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:25:23 ]
- >>28
JavaのGUI, Swing APIやJava3D APIの3Dレンダリングの
部分だけGPUに任せられたらいいねえ。
- 57 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:29:20 ]
- >>31
それも微妙なところではあるが。
Java SE 5 Tigerからかなりの高速化が実現されているし
Java SE 6 Mustangからはさらに高速化する。
Javaアプリ初回起動だけVM上で動いて
２回目以降からはネイティブで動くってことがあるわけで。
Javaアプリを起動するたびにVMをいくつも起動するという
問題も解消されるし。
それとJavaは他の言語と比べレスポンス性能が
極端に遅いことからクライアントサイドでは普及が
一時停滞した。ところがJavaは代わりに
スループット性能が高いという利点があったりする。
他の言語が戦術的短距離走タイプであるのに対し、
Javaは戦略的マラソンランナータイプ、ってところだろうか。
- 58 名前：デフォルトの名無しさん [2005/11/29(火) 11:54:36 ]
- >>56
Java3DはOpenGLかDirect Xがバックエンドになっているんだが。
ちなみに、SwingをGPUに描画させるという考えは、Swingの
設計思想(全部Javaで描画)に反するから実現不可能。
- 59 名前：デフォルトの名無しさん [2005/11/29(火) 16:23:09 ]
- これってグラボ変えたら動かなくなるんでしょ？
グラボなんてドンドン新しいのが出るんだからそんなの使えネェじゃん。
- 60 名前：デフォルトの名無しさん [2005/11/29(火) 16:42:24 ]
- それを避けるための高級言語じゃないの？
- 61 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 17:11:03 ]
- 自作板の雑談と何も変わらんな
- 62 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 17:42:26 ]
- 大抵はグラボを変えても動きます
特に新しいものに変える場合は可能性は高いです
例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です
- 63 名前：デフォルトの名無しさん mailto:sage [2005/11/30(水) 00:55:00 ]
- ＞大抵はグラボを変えても動きます
大抵って？
＞例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です
MMXは、世に機能公開して広範なアプリを作らせた以上、
後継CPUでは完全互換を取って当たり前、という位置にいるわけだが、それと同等と？
MMXが出たのは１０年くらい前で、今でもまだ動くんだが、それと同等と？
- 64 名前：デフォルトの名無しさん mailto:sage [2005/11/30(水) 01:01:32 ]
- >>63
既にShaderはほぼ標準装備ですが何か？
- 65 名前：デフォルトの名無しさん [2005/11/30(水) 01:12:41 ]
- >>63
並列アルゴリズムの実装のために少しでも安くて速い計算リソースを使おうという研究なんで、
互換性を気にして「10年後に動かなかったらどうするんだよ」という向きには用は無い。
- 66 名前：デフォルトの名無しさん mailto:sage [2005/11/30(水) 01:25:58 ]
- そもそもGLSLはOpenGLドライバ側でコンパイルされてGPUのコードに変換されるものだから
原則的にはGPUが変わっても動くと考えても問題ない。
(バグや仕様で動かない可能性は100%否定できないが)
ARBあたりから互換性のないシェーダー言語が出てきて、
どっかのGPUメーカーが今のGLSLをサポートしなくなるということがあれば問題になるが
ここまできてARBやGPUメーカーが今の仕様を完全放棄するのは難しいと思われ
- 67 名前：デフォルトの名無しさん mailto:sage [2005/12/01(木) 19:23:35 ]
- 今までのGPUは後方互換をほぼ意識しないで拡張してきたからこれだけの性能が出たのだと思う。
今後もちゃんと動くかはかなり疑問に感じる。（GPGPUが一過性のような気がする。
＃最近のボードでも過去のDXは動くけど、ネーティブに動いてるわけではなくて、ドライバ辺りのエミュレートだったと思う。
- 68 名前：デフォルトの名無しさん [2005/12/01(木) 20:10:14 ]
- まぁ一過性というのはそのとおりでGPUは通過点でしかないだろうね。
今はいろいろ試して、問題点を出したり適応範囲を模索したりしてる段階。
それを元にハードウェアも含めてだんだん方向性が決まってくるわけで。
- 69 名前：デフォルトの名無しさん mailto:sage [2005/12/01(木) 21:17:17 ]
- GPUに本当に有用なアーキテクチャがあるならコプロと同じ運命をたどるでしょ。
リレースイッチをブザー代わりに使うような技術に発展性があるわけがない。
- 70 名前：デフォルトの名無しさん [2005/12/11(日) 06:22:53 ]
- age
- 71 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 05:47:10 ]
- >>69
浮動小数点演算はコプロというか専用エンジンが無いとどうしようも無いぞ。
それはCELLとかも同じ。
- 72 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 19:53:50 ]
- 整数演算もできるようになるのはいつ？
- 73 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 21:27:15 ]
- >>71
意味わからん。話が噛み合ってないな。
どうでもいいけど、コプロがない時代はPCは浮動小数点演算ができなかった、
とでも思ってるのかなw
- 74 名前：デフォルトの名無しさん [2005/12/14(水) 16:26:15 ]
- マシンに本物のFPU積んだ時には、嬉しくって毎日レイトレしてたな。
- 75 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:41:40 ]
- コプロ積んでもBASICが全く速くならなかった時には、orzだったな。
- 76 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 20:19:33 ]
- >>69
しかしブザーが出回るまでの間は有用だし生き延びるだろうさ。
- 77 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 09:48:59 ]
- コプロ無しの少数演算って遅すぎだろ
- 78 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 09:56:39 ]
- それよりGPGPUの話をしよう
- 79 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 14:40:11 ]
- 先生！誰もわかってないので話すことがありません！
- 80 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 18:07:10 ]
- GPGPUは手段であって、目的じゃないからな。
なにか高速に計算したいものがあって、その手段としてGPGPUが良ければ使う。
目的がないのにGPGPUやろうぜとか言われても盛り上がらん。
手段のために目的を探すのはアホだしな。
- 81 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 18:47:17 ]
- 目的がないから手段も学ぶ必要ないもんな・・・・
日本発のGPGPUを使ったDivXエンコーダーとか作れれば盛り上がるのだろうが。
- 82 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 20:29:41 ]
- GPGPU = Game Programming Gems(ﾌﾟ
- 83 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 03:24:22 ]
- >>47
GRAPEは専用プロセッサのままなので他では使われないね。
コプロにしたほうが広がりやすい気がするけど帯域が問題なのかな。
www.itmedia.co.jp/news/articles/0405/28/news048.html
そして東工大のOpteronグリッドにはClearSpeedのSIMDアクセラレータが乗る
www.itmedia.co.jp/news/articles/0410/07/news039.html
japan.cnet.com/news/ent/story/0,2000047623,20075021,00.htm
- 84 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 15:18:34 ]
- Scoutって一番興味あるんですが、まだ公開はされていないんですか?
Los Alamos National Labsのサイトに行ってもPDFの論文にしかリンク貼ってない。
- 85 名前：デフォルトの名無しさん [2005/12/21(水) 01:05:14 ]
- >>84
Brook for GPU じゃだめなの？
- 86 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 13:29:13 ]
- Vista時代で、常に3D使うようになったらGPGPUも終わりな気がするのは
俺だけかな。
- 87 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 17:50:35 ]
- AeroGlassをEnableにすれば大丈夫じゃない？
- 88 名前：86 mailto:sage [2005/12/22(木) 18:09:05 ]
- AeroGlassをEnableにすると、常にシェーダーが使われているわけだから
GPGPUには使えないのではないかと思ったんだけど。
- 89 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 20:22:33 ]
- >>86
GPGPUって科学技術計算等の激しく重い演算用だろ？
普通のアプリ走らせてる横でやる必要もないと思うが。
- 90 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 20:29:13 ]
- 聞きたいのは二つのシェーダー使うアプリを同時に使用できるかと言うこと。
できるのならWindowsがGPU使っていてもGPGPUできるだろう。
もしできないのであったら、GPGPUするときはAeroGlassをオフにしなければならない。
>>89が言うことももっともだが、いちいちそんなことが必要になるなら価値は少し下がる。
- 91 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 00:15:44 ]
- GPUにもコンテキストスイッチは存在するんじゃね？
- 92 名前：87 mailto:sage [2005/12/23(金) 00:16:23 ]
- ごめん、英語間違ってますた…disableだ…＿|￣|○
- 93 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 00:34:05 ]
- VistaではGPUが仮想化されて、DirectXのデバイスロストが無くなる。
GPGPUとAeroGlassの併用も可能と思われ。
- 94 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 18:37:14 ]
- >>90
GUIは(ゲームなどの描画と違って)四六時中描画してるわけではない。
- 95 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 05:54:47 ]
- >>90
多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
GPGPUの唯一の価値＝速度だから、あんまりそういう用途には向いてないような・・・
- 96 名前：デフォルトの名無しさん [2005/12/26(月) 19:08:48 ]
- 計算用に、もう一枚刺す。
- 97 名前：84 mailto:sage [2005/12/26(月) 19:49:18 ]
- >>85
いや、なんか紹介記事見てたら、簡単そうで。
C*の情報がないので言語仕様がわからないけど。
Vista時代には、PCI-ExpressにGPUどんどん追加していける仕様にするのでは。
x1でもパフォーマンス出るように工夫する必要があるけど。
- 98 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 21:46:14 ]
- >多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
CPUはそれなりに現実的にマルチタスクできてるんだから
GPUだけできない理由は何もないような。
ドライバがそこらへんに対応してれば。
- 99 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 16:55:05 ]
- >>98
並列性が高い分、タスクスイッチに伴うペナルティコストが、CPUに比べて
馬鹿にならないと思われ。
- 100 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 17:07:20 ]
- 並列動作可能なら、CPU側のタスクに合わせてタスクスイッチする必要はないんじゃない？
OS分の描画やりながら、遊んでるユニットでGPGPUの計算するとかできんの？
|
 |
