トップページ⇒tech
994コメント306KB

GPGPU

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/10/08(土) 23:15:20
いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
GPGPUについて語りましょう

参考リンク

総本山? gpgpu.org
http://www.gpgpu.org/
GPUをCPU的に活用するGPGPUの可能性
http://pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/
0002デフォルトの名無しさん2005/10/08(土) 23:18:48
２
0003デフォルトの名無しさん2005/10/08(土) 23:23:53
メモリーに関してはだんだんスパコンのアーキに近づいてるからなぁ。
0004デフォルトの名無しさん2005/10/09(日) 03:46:05
ラデX1800のようにメモリレイテンシをあまり気にしなくていいというのは羨ましいな
0005デフォルトの名無しさん2005/10/09(日) 11:50:01
ShとBrook期待age
0006デフォルトの名無しさん2005/10/09(日) 13:11:52
CPU→GPU→CPUって経路でデータ流せるんだっけ?
0007デフォルトの名無しさん2005/10/09(日) 14:06:12
出来なかったら、画面のキャプチャーとか出来ないだろ。
0008デフォルトの名無しさん2005/10/09(日) 17:05:54
今現在、計算結果を持って帰るには一度フレームバッファに書いたのを吸い出すしかない。
今後改善されるとは思うけど、これじゃあ使えねぇよ。

でもXBOX360はメインメモリに直接アクセスする方法が用意されているらしい。
実用段階になったら、まずはトリップ計算機から誰か作ってよ。
0009デフォルトの名無しさん2005/10/09(日) 17:21:09
>>8
ソース公開してる奴ってどれ？＞計算機
ちとやってみたい
0010デフォルトの名無しさん2005/10/10(月) 14:05:01
これからはJavaやC#のようなオブジェクト指向言語をベースに
速度が重要な部分はシェーダー(GPGPU)でなんて流れになるのでしょうか？
0011デフォルトの名無しさん2005/10/10(月) 14:58:23
なりません
0012デフォルトの名無しさん2005/10/11(火) 14:13:56
GPGPUって過渡的なものであって、今後はXbox360/Cellに代表される
ヘテロジーニャスなマルチコアプロセッサの流れだろうな
0013デフォルトの名無しさん2005/10/11(火) 14:43:51
360はホモ臭い
0014デフォルトの名無しさん2005/10/11(火) 15:22:02
あぁたしかに360はハードウェアアーキはホモだけど、ソフトウェアアプリで
ヘテロっぽく使うんだった.
0015デフォルトの名無しさん2005/10/11(火) 20:31:37
小泉風に言えばGPUでできることはGPUに、CPUでなければいけないところはCPUでってこと？
0016デフォルトの名無しさん2005/10/11(火) 21:53:02
その言い方だと今までのアプローチとなんら変わらんがな
0017デフォルトの名無しさん2005/10/11(火) 22:59:09
OpenGLとかで流行ったBASICにできることは（ｒｙ、Cでなければ（ｒｙと変わらんね。
0018デフォルトの名無しさん2005/10/11(火) 23:55:23
それって>>10と同じじゃね？
0019デフォルトの名無しさん2005/10/12(水) 00:04:04
未だにオブジェクト指向と速度を関連させる奴がいるのか。
0020デフォルトの名無しさん2005/10/12(水) 00:24:44
JavaやC#が速いとはあんまり思えないけどな
0021デフォルトの名無しさん2005/10/13(木) 21:17:35
age
0022デフォルトの名無しさん2005/10/13(木) 21:32:40
情報が少なすぎて。。
0023デフォルトの名無しさん2005/10/15(土) 00:38:51
RGBA8bitの32ビットフォーマットのテクスチャに対し、
各位置のビットが1のピクセルの個数を数える、見たいな処理って出来ませんかね。
Rの3ビット目が1のピクセルは150個、みたいな感じで。

RGBA4種類の個数とかだったら簡単に出来るんですが、
各ビット合計32個のデータを取り出す方法がおもいつかない。。
0024デフォルトの名無しさん2005/10/15(土) 08:50:52
>>23
8bit パレット画像として扱うとかどう？
二アレスとサンプリングにして。
１回に１チャンネルしか処理できないけど。
0025デフォルトの名無しさん2005/10/15(土) 12:41:23
>>24
やっぱり複数回に分けて処理するしかないですかねー。
せっかくデータをまとめたんだから、1度に処理できないかと考えたけど無理か。
0026デフォルトの名無しさん2005/10/15(土) 14:27:28
bsf・・・はx86だしな
0027デフォルトの名無しさん2005/10/23(日) 20:29:04
保守
0028デフォルトの名無しさん2005/10/24(月) 02:06:59
JavaとGPGPUのコラボ最強と思ってるのはたぶん漏れだけ
0029デフォルトの名無しさん2005/10/25(火) 01:53:53
GPUは基本的にストリームプロセッサだからCPUのような複雑な
分岐や少量のデータ処理を多数行うような仕事だと効率悪い。
現実は厳しいよ。
0030デフォルトの名無しさん2005/10/25(火) 15:42:06
そういう仕事をGPUに投げるのが間違い。
0031デフォルトの名無しさん2005/10/25(火) 23:21:53
>>29
大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが
0032デフォルトの名無しさん2005/10/25(火) 23:39:54
C++とGPGPUこれ最強
0033デフォルトの名無しさん2005/10/26(水) 01:58:39
>>1
語りたい事もないのに糞スレ立てるな
0034デフォルトの名無しさん2005/10/26(水) 02:11:17
GPUってなんの計算をしてくれるのよ。
0035デフォルトの名無しさん2005/10/26(水) 08:52:24
ようはSIMD
0036デフォルトの名無しさん2005/10/31(月) 01:05:14
>>34
いまならシェーダーさえ書けばどんな計算だってしてくれる
向き不向きはあるが、膨大な量の単純計算繰り返しなら
最新のCPUよりもGPUのほうが早い
0037デフォルトの名無しさん2005/10/31(月) 01:16:46
向き不向きなんてレベルじゃない。
かなりのレベルの並列性が無いとダメだし、入出力もかなり限定された形でしか出来ん。
どんな計算でもなんてとても言えん。
が、条件にはまる物ならばパフォーマンスの高さに驚く。
0038デフォルトの名無しさん2005/10/31(月) 01:28:46
結局GPGPUの使いどころとしては画像処理(2D)・映像処理・音声処理あたりに落ち着くんでしょうかね
もともとGPUの得意分野だし
0039デフォルトの名無しさん2005/10/31(月) 01:39:01
物理演算はねーの？？
0040デフォルトの名無しさん2005/10/31(月) 21:15:21
GPU演算での精度はどれぐらいまで期待できるんでしょうかね？
0041デフォルトの名無しさん2005/10/31(月) 22:43:58
丸めの方向を制御できなかったり、なんていう困った点もあるみたいよ＞GPGPU
0042デフォルトの名無しさん2005/11/08(火) 00:19:25
保守
0043デフォルトの名無しさん2005/11/13(日) 01:46:21
age
0044デフォルトの名無しさん2005/11/13(日) 15:32:56
発想としては面白いし、昔からこういうハードを本来の目的以外に使うって話は好きなんだけど
(キャラクタ表示機能しかないマシンでビットマップ表示とかFM音源でPCM多重再生みたいな）
なんかあんまり現実的に聞こえないんだけど。。

ハイエンドなGPUなんてゲーマー以外もってないじゃん。
CAD用のGPUなんてもっと少数派だし。
そのくせ、3d表示で使ってる間は当然使えないわけだろうし。
だいいち各GPUの違いを吸収する負担は誰が負うのよ。

CPUのマルチコア化の流れを受けてのことなのかな。
昔のコプロみたいにCPUの中にそういうGPU的なアーキテクチャを組み入れていこう、
って展望でもあるのか？
0045デフォルトの名無しさん2005/11/13(日) 16:05:04
3D表示使わないアプリで使えば無問題だし、
最近じゃハイエンドじゃなくてもシェーダが動く。
GPUの違いはシェーディング言語そのものでバージョン管理と、
そのラッパーであるライブラリで十分埋まる。
0046デフォルトの名無しさん2005/11/13(日) 20:08:06
>>44
とても現状を理解しての発言には思えない。
0047デフォルトの名無しさん2005/11/13(日) 20:15:55
PhysXもそろそろ出るね
CPU以外のパワーを利用するのって
一時的かと思ってたけど時代の潮流かな
0048デフォルトの名無しさん2005/11/22(火) 18:01:21
http://staraxis.kazelog.jp/okiraku/2005/11/atiavivo_49a9.html
ATIのAVIVOエンコード機能は凄い!!

DVD映像5分（720x480）をDivXやwmvにエンコードするのが25秒で終わるとか早すぎ！！！
GPGPUを使った物らしいです
0049デフォルトの名無しさん2005/11/22(火) 22:17:01
いや、Theaterっていう専用チップが乗ってるよ
http://www.4gamer.net/news.php?url=/news/history/2005.09/20050920190000detail.html
0050デフォルトの名無しさん2005/11/25(金) 12:27:04
FAQ - GPGPU.org Wiki
http://www.gpgpu.org/wiki/FAQ
0051デフォルトの名無しさん2005/11/29(火) 00:05:32
GPU GEMS2の日本語版が出たようだ

http://www.shader.jp/xoops/html/modules/wordpress/index.php?p=166
0052デフォルトの名無しさん2005/11/29(火) 00:06:17
sageたままだった・・・orz
0053デフォルトの名無しさん2005/11/29(火) 00:09:53
AGPメモリにフレームバッファ確保できなかったっけ？
0054デフォルトの名無しさん2005/11/29(火) 01:22:55
>>10
Javaチップ、Javaアクセラレータ
なんてものがあるしな。
考えられなくもないな
0055デフォルトの名無しさん2005/11/29(火) 01:24:29
>>19
むしろVMと速度だな。
C言語の中の人は
オブジェクト指向を使うと速度が遅くなる
から使わない方がいいとか未だにいっているからね。
0056デフォルトの名無しさん2005/11/29(火) 01:25:23
>>28
JavaのGUI, Swing APIやJava3D APIの3Dレンダリングの
部分だけGPUに任せられたらいいねえ。
0057デフォルトの名無しさん2005/11/29(火) 01:29:20
>>31
それも微妙なところではあるが。
Java SE 5 Tigerからかなりの高速化が実現されているし
Java SE 6 Mustangからはさらに高速化する。
Javaアプリ初回起動だけVM上で動いて
２回目以降からはネイティブで動くってことがあるわけで。
Javaアプリを起動するたびにVMをいくつも起動するという
問題も解消されるし。

それとJavaは他の言語と比べレスポンス性能が
極端に遅いことからクライアントサイドでは普及が
一時停滞した。ところがJavaは代わりに
スループット性能が高いという利点があったりする。
他の言語が戦術的短距離走タイプであるのに対し、
Javaは戦略的マラソンランナータイプ、ってところだろうか。
0058デフォルトの名無しさん2005/11/29(火) 11:54:36
>>56
Java3DはOpenGLかDirect Xがバックエンドになっているんだが。

ちなみに、SwingをGPUに描画させるという考えは、Swingの
設計思想(全部Javaで描画)に反するから実現不可能。
0059デフォルトの名無しさん2005/11/29(火) 16:23:09
これってグラボ変えたら動かなくなるんでしょ？
グラボなんてドンドン新しいのが出るんだからそんなの使えネェじゃん。
0060デフォルトの名無しさん2005/11/29(火) 16:42:24
それを避けるための高級言語じゃないの？
0061デフォルトの名無しさん2005/11/29(火) 17:11:03
自作板の雑談と何も変わらんな
0062デフォルトの名無しさん2005/11/29(火) 17:42:26
大抵はグラボを変えても動きます
特に新しいものに変える場合は可能性は高いです
例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です
0063デフォルトの名無しさん2005/11/30(水) 00:55:00
＞大抵はグラボを変えても動きます
大抵って？

＞例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です

MMXは、世に機能公開して広範なアプリを作らせた以上、
後継CPUでは完全互換を取って当たり前、という位置にいるわけだが、それと同等と？　
MMXが出たのは１０年くらい前で、今でもまだ動くんだが、それと同等と？
0064デフォルトの名無しさん2005/11/30(水) 01:01:32
>>63
既にShaderはほぼ標準装備ですが何か？
0065デフォルトの名無しさん2005/11/30(水) 01:12:41
>>63
並列アルゴリズムの実装のために少しでも安くて速い計算リソースを使おうという研究なんで、
互換性を気にして「10年後に動かなかったらどうするんだよ」という向きには用は無い。
0066デフォルトの名無しさん2005/11/30(水) 01:25:58
そもそもGLSLはOpenGLドライバ側でコンパイルされてGPUのコードに変換されるものだから
原則的にはGPUが変わっても動くと考えても問題ない。
(バグや仕様で動かない可能性は100%否定できないが)

ARBあたりから互換性のないシェーダー言語が出てきて、
どっかのGPUメーカーが今のGLSLをサポートしなくなるということがあれば問題になるが
ここまできてARBやGPUメーカーが今の仕様を完全放棄するのは難しいと思われ
0067デフォルトの名無しさん2005/12/01(木) 19:23:35
今までのGPUは後方互換をほぼ意識しないで拡張してきたからこれだけの性能が出たのだと思う。
今後もちゃんと動くかはかなり疑問に感じる。（GPGPUが一過性のような気がする。

＃最近のボードでも過去のDXは動くけど、ネーティブに動いてるわけではなくて、ドライバ辺りのエミュレートだったと思う。
0068デフォルトの名無しさん2005/12/01(木) 20:10:14
まぁ一過性というのはそのとおりでGPUは通過点でしかないだろうね。
今はいろいろ試して、問題点を出したり適応範囲を模索したりしてる段階。
それを元にハードウェアも含めてだんだん方向性が決まってくるわけで。
0069デフォルトの名無しさん2005/12/01(木) 21:17:17
GPUに本当に有用なアーキテクチャがあるならコプロと同じ運命をたどるでしょ。
リレースイッチをブザー代わりに使うような技術に発展性があるわけがない。
0070デフォルトの名無しさん2005/12/11(日) 06:22:53
age
0071デフォルトの名無しさん2005/12/13(火) 05:47:10
>>69
浮動小数点演算はコプロというか専用エンジンが無いとどうしようも無いぞ。
それはCELLとかも同じ。
0072デフォルトの名無しさん2005/12/13(火) 19:53:50
整数演算もできるようになるのはいつ？
0073デフォルトの名無しさん2005/12/13(火) 21:27:15
>>71
意味わからん。話が噛み合ってないな。

どうでもいいけど、コプロがない時代はPCは浮動小数点演算ができなかった、
とでも思ってるのかなw
0074デフォルトの名無しさん2005/12/14(水) 16:26:15
マシンに本物のFPU積んだ時には、嬉しくって毎日レイトレしてたな。
0075デフォルトの名無しさん2005/12/14(水) 16:41:40
コプロ積んでもBASICが全く速くならなかった時には、orzだったな。
0076デフォルトの名無しさん2005/12/15(木) 20:19:33
>>69
しかしブザーが出回るまでの間は有用だし生き延びるだろうさ。
0077デフォルトの名無しさん2005/12/17(土) 09:48:59
コプロ無しの少数演算って遅すぎだろ
0078デフォルトの名無しさん2005/12/17(土) 09:56:39
それよりGPGPUの話をしよう
0079デフォルトの名無しさん2005/12/17(土) 14:40:11
先生！誰もわかってないので話すことがありません！
0080デフォルトの名無しさん2005/12/17(土) 18:07:10
GPGPUは手段であって、目的じゃないからな。
なにか高速に計算したいものがあって、その手段としてGPGPUが良ければ使う。
目的がないのにGPGPUやろうぜとか言われても盛り上がらん。
手段のために目的を探すのはアホだしな。
0081デフォルトの名無しさん2005/12/17(土) 18:47:17
目的がないから手段も学ぶ必要ないもんな・・・・
日本発のGPGPUを使ったDivXエンコーダーとか作れれば盛り上がるのだろうが。
0082デフォルトの名無しさん2005/12/17(土) 20:29:41
GPGPU = Game Programming Gems(ﾌﾟ
0083デフォルトの名無しさん2005/12/18(日) 03:24:22
>>47
GRAPEは専用プロセッサのままなので他では使われないね。
コプロにしたほうが広がりやすい気がするけど帯域が問題なのかな。
http://www.itmedia.co.jp/news/articles/0405/28/news048.html

そして東工大のOpteronグリッドにはClearSpeedのSIMDアクセラレータが乗る
http://www.itmedia.co.jp/news/articles/0410/07/news039.html
http://japan.cnet.com/news/ent/story/0,2000047623,20075021,00.htm
0084デフォルトの名無しさん2005/12/19(月) 15:18:34
Scoutって一番興味あるんですが、まだ公開はされていないんですか?

Los Alamos National Labsのサイトに行ってもPDFの論文にしかリンク貼ってない。
0085デフォルトの名無しさん2005/12/21(水) 01:05:14
>>84
Brook for GPU じゃだめなの？
0086デフォルトの名無しさん2005/12/21(水) 13:29:13
Vista時代で、常に3D使うようになったらGPGPUも終わりな気がするのは
俺だけかな。
0087デフォルトの名無しさん2005/12/22(木) 17:50:35
AeroGlassをEnableにすれば大丈夫じゃない？
0088862005/12/22(木) 18:09:05
AeroGlassをEnableにすると、常にシェーダーが使われているわけだから
GPGPUには使えないのではないかと思ったんだけど。
0089デフォルトの名無しさん2005/12/22(木) 20:22:33
>>86
GPGPUって科学技術計算等の激しく重い演算用だろ？
普通のアプリ走らせてる横でやる必要もないと思うが。
0090デフォルトの名無しさん2005/12/22(木) 20:29:13
聞きたいのは二つのシェーダー使うアプリを同時に使用できるかと言うこと。
できるのならWindowsがGPU使っていてもGPGPUできるだろう。
もしできないのであったら、GPGPUするときはAeroGlassをオフにしなければならない。
>>89が言うことももっともだが、いちいちそんなことが必要になるなら価値は少し下がる。
0091デフォルトの名無しさん2005/12/23(金) 00:15:44
GPUにもコンテキストスイッチは存在するんじゃね？
0092872005/12/23(金) 00:16:23
ごめん、英語間違ってますた…disableだ…＿|￣|○
0093デフォルトの名無しさん2005/12/23(金) 00:34:05
VistaではGPUが仮想化されて、DirectXのデバイスロストが無くなる。
GPGPUとAeroGlassの併用も可能と思われ。
0094デフォルトの名無しさん2005/12/25(日) 18:37:14
>>90
GUIは(ゲームなどの描画と違って)四六時中描画してるわけではない。
0095デフォルトの名無しさん2005/12/26(月) 05:54:47
>>90
多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
GPGPUの唯一の価値＝速度だから、あんまりそういう用途には向いてないような・・・
0096デフォルトの名無しさん2005/12/26(月) 19:08:48
計算用に、もう一枚刺す。
0097842005/12/26(月) 19:49:18
>>85

いや、なんか紹介記事見てたら、簡単そうで。
C*の情報がないので言語仕様がわからないけど。

Vista時代には、PCI-ExpressにGPUどんどん追加していける仕様にするのでは。
x1でもパフォーマンス出るように工夫する必要があるけど。
0098デフォルトの名無しさん2005/12/26(月) 21:46:14
>多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
CPUはそれなりに現実的にマルチタスクできてるんだから
GPUだけできない理由は何もないような。
ドライバがそこらへんに対応してれば。
0099デフォルトの名無しさん2005/12/27(火) 16:55:05
>>98

並列性が高い分、タスクスイッチに伴うペナルティコストが、CPUに比べて
馬鹿にならないと思われ。
0100デフォルトの名無しさん2005/12/27(火) 17:07:20
並列動作可能なら、CPU側のタスクに合わせてタスクスイッチする必要はないんじゃない？
OS分の描画やりながら、遊んでるユニットでGPGPUの計算するとかできんの？
0101デフォルトの名無しさん2005/12/27(火) 19:25:35
VistaになってもUIは2kスタイルに設定するから問題ない。
■ このスレッドは過去ログ倉庫に格納されています