GPGPU#3
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/03/21(土) 19:18:14前スレ
GPGPU#2
http://pc11.2ch.net/test/read.cgi/tech/1188374938/
関連スレ
http://pc11.2ch.net/test/read.cgi/tech/1228891105/
http://pc11.2ch.net/test/read.cgi/tech/1206152032/
参考リンク
総本山? gpgpu.org
http://www.gpgpu.org/
OpenCL
http://www.khronos.org/opencl/
NVIDIA CUDA
http://developer.nvidia.com/object/cuda.html
ATI Stream
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx
GPUをCPU的に活用するGPGPUの可能性
http://pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/
0016デフォルトの名無しさん
2009/04/03(金) 21:12:280017デフォルトの名無しさん
2009/04/14(火) 12:10:11ttp://developer.amd.com/gpu/ATIStreamSDK/pages/Publications.aspx
0018デフォルトの名無しさん
2009/04/26(日) 11:36:47ttp://sourceforge.jp/magazine/09/04/22/0915222
0019デフォルトの名無しさん
2009/04/26(日) 11:59:02OpenＣLに対応不可能らしい
なんでか知りたい
0020デフォルトの名無しさん
2009/04/26(日) 12:07:37ATI STREAMオワタ
0021デフォルトの名無しさん
2009/04/26(日) 13:03:210022デフォルトの名無しさん
2009/04/26(日) 20:24:320023デフォルトの名無しさん
2009/04/26(日) 20:37:29なんで？
0024デフォルトの名無しさん
2009/04/27(月) 00:17:030025デフォルトの名無しさん
2009/04/27(月) 07:17:33なにか？
0026デフォルトの名無しさん
2009/04/27(月) 08:06:51で、実パフォーマンスは9600GT(312gflops)をphysx専用に使った場合と同じ
0027デフォルトの名無しさん
2009/04/27(月) 08:45:522009年上半期中に対応予定だろ。
0028デフォルトの名無しさん
2009/04/27(月) 23:04:36それずれた
29日にスキンヘッドのおっさんショーに行って
聞いてみなよ
0029デフォルトの名無しさん
2009/04/28(火) 10:12:050030デフォルトの名無しさん
2009/05/08(金) 10:07:00http://forums.nvidia.com/index.php?showtopic=96303
0031デフォルトの名無しさん
2009/05/16(土) 11:30:380032デフォルトの名無しさん
2009/05/16(土) 19:49:570033デフォルトの名無しさん
2009/05/16(土) 19:59:40無いね海外でも採用事例作れないらしく
切り捨てるかもって話だね
0034デフォルトの名無しさん
2009/05/16(土) 20:35:30その辺ｎの方はどうなんか知らんけどさ。
遊びで弄る分には低レベルなところを見れるのは面白いんだがな。
0035デフォルトの名無しさん
2009/05/16(土) 22:36:02実用上、ILで書けば早いよ！なんてのは使い物にならん
それが通るならCellももっと普及したはずだしな
CUDAの強みはほぼCの構文だけで書けて、かつ理論値と見比べても悪くない性能を出せること
まぁブラックボックスが多すぎて、最適化がむずいって問題はあるんだが
0036デフォルトの名無しさん
2009/05/17(日) 02:41:480037,,・´∀｀・,,）っ-○○○
2009/05/17(日) 22:21:180038デフォルトの名無しさん
2009/05/17(日) 22:30:14暗礁に乗り上げててリリース不可能と言われてるしなぁ
0039デフォルトの名無しさん
2009/05/17(日) 22:52:18同じ土俵でどっちが早いのか気にはなるから頑張っては欲しいけど
0040デフォルトの名無しさん
2009/05/17(日) 23:09:39出ないしOpenCA化しても性能全然発揮できなくないか？
0041デフォルトの名無しさん
2009/05/17(日) 23:17:51絶対性能ならそうだろうけど、電力やコストとの兼ね合いもあるからそこまで悪くはないと思われる
性能だけならHPCに力入れてるnVidiaが強いけど、実用用途じゃ電力だとか色々制約もあるのよ
0042デフォルトの名無しさん
2009/05/17(日) 23:21:04でも現実的にそうだとしてもVLIW系のアーキテクチャで
並列性上げるってそうとうつらくない？
資金無限にあるように見えるIntelですら投げ捨てたものでしょ？
0043デフォルトの名無しさん
2009/05/17(日) 23:23:09それについては結局演算の割り当てとかを考えながら最適化していく事になると思うよ
CUDAでブロックサイズ変えたりアライン変えたりしてるみたいにね
その辺も含めて試してみたいし期待してる
確かにVLIWで性能だそうと思ったら、アプリケーションも限られてくるし実装も相当面倒くさくなりそうだけど
0044,,・´∀｀・,,）っ-○○○
2009/05/17(日) 23:30:350045デフォルトの名無しさん
2009/05/17(日) 23:50:12結局それだと、HavokClothのためにRadeon使います
か各アプリ用に無理にでもRadeon使うって感じですよね。
ダンゴさまが得意なララビーでも待とうかなぁ
OpenCAとか暗号関係にCUDA使いたかったけど
普通の数値演算以外適合力無さ過ぎて途方にくれているｗ
0046デフォルトの名無しさん
2009/05/17(日) 23:52:37VLIWのコード最適化なんてもう数十年も研究されてるし、科学技術計算
や信号処理用の商用機だってそれなりの数が出てるわけでさ。
性能が出ないのは単にコード書く人間の調査不足って事はないんだろうか。
0047デフォルトの名無しさん
2009/05/17(日) 23:54:02CUDAは並列性が高くないと性能出せないからね
暗号みたいに、次々チェインしていくようなルーチンには根本的に合わない
0048デフォルトの名無しさん
2009/05/17(日) 23:56:05歴史は長いけど、その割には普及してないでしょ？要はそういうこと
すっごい頑張れば、すっごい性能出るよ！ってのは一部の人間（HPC分野）にはウケが良くても
結局実務じゃ使い物にならないのよ
んで、数が捌けないと値段も下がらないし、次も出てこない
0049デフォルトの名無しさん
2009/05/17(日) 23:57:18効率の良い扱いの良いVLIWをどうやって最適化するかという
文献はあるけど、既にある特定の分野に特化したVLIWを
多目的に最適化するという技術論文は見当たらないなぁ
あるなら欲しいのでリンク教えていただけますか？
0050デフォルトの名無しさん
2009/05/18(月) 00:06:43R700のVLIWアーキテクチャて具体的にはどの辺が特定の分野に特化してるわけ？
0051デフォルトの名無しさん
2009/05/18(月) 00:46:350052,,・´∀｀・,,）っ-○○○
2009/05/18(月) 00:51:12いまのx86は命令エンコーディングそのものを演算の依存関係の解決に使う方式をとってるから
絶対性能的には微妙かも
0053デフォルトの名無しさん
2009/05/18(月) 01:25:2565nmプロセスで1TFlops, 98W, 275mm2
こういうのも検討した上でLarrabeeでの保守的な選択がある
示唆的だね
0054,,・´∀｀・,,）っ-○○○
2009/05/18(月) 02:17:190055デフォルトの名無しさん
2009/05/18(月) 07:55:490056デフォルトの名無しさん
2009/05/18(月) 08:22:50塗絵
結局OpenCLでHavok Clothやっても自社4 core cpuよりパフォーマンスが劣っていて
GW前のイベントでは1体はGPU,3体はCPUで動かし、
（モーション止めた状態で、CPUに切り替えたがドレスは微妙に動いていたわけで、CPUに切り替えたとたん軽くなったｗ）
GPUでやるのが良いと言うわけではないとか苦しい言い訳してたよ
VLIW以前に、R600系はG80系よりも演算粒度がでかすぎ
1アレイでshader 16個並んでるけど物理演算だとそのほとんどが遊んでる
0057,,・´∀｀・,,）っ-○○○
2009/05/19(火) 06:05:14SMあたりのキャッシュメモリを数百KB確保してワークセット数減らしたほうが
明らかにキャッシュが無いせいでVRAM読み書きせざるを得なくなり、更にそのレイテンシ隠蔽のために
ワークセット数をアホみたいに増やさないといけない。
どんな悪循環だよ。
物理演算エンジンとしてもCellのほうがまだマシなレベルじゃね？
0058デフォルトの名無しさん
2009/05/19(火) 08:50:44元々GPUがメインターゲットとしているのが、CPUでやると
10倍100倍時間がかかるからセットアップに多少時間がかかっても
元が取れるような処理なのだから。
GPU処理のときにメッシュ数が16倍になって
より滑らかになりますみたいなデモのやり方をしないと
GPUのメリットは出にくい。
まあ元々GPUのメリットをアピールするための
デモではなかったということだな。
0059デフォルトの名無しさん
2009/05/19(火) 17:51:060060デフォルトの名無しさん
2009/05/19(火) 21:44:34ATI Stream Developer Showcase
0061デフォルトの名無しさん
2009/05/19(火) 22:48:16http://developer.amd.com/gpu_assets/ATIGPGPUComputingFusionRenderCloudGDC09CompatibilityMode.pdf
0062デフォルトの名無しさん
2009/05/19(火) 22:56:140063デフォルトの名無しさん
2009/05/21(木) 01:15:35python用のライブラリなんかあるんだな。
何故かVSでbrook+コンパイラが動かないんでそっちに行ってみるか。。。
0064デフォルトの名無しさん
2009/05/24(日) 17:36:56ttp://jp.arxiv.org/pdf/0904.3659v1
0065デフォルトの名無しさん
2009/05/24(日) 19:46:190066デフォルトの名無しさん
2009/05/24(日) 20:09:39作ってるけど同じ数値にならんなｗ
俺腐ってるぜｗ
0067デフォルトの名無しさん
2009/05/24(日) 20:40:470068デフォルトの名無しさん
2009/05/24(日) 22:17:13ここのか
0069デフォルトの名無しさん
2009/05/24(日) 22:29:32ありがてぇ。
0070デフォルトの名無しさん
2009/05/24(日) 22:31:25自分の理解不足発見wktkしてきた
だがしかし、月曜日が近づいてきた
どうしよう会社どうしよう
0071デフォルトの名無しさん
2009/05/24(日) 22:41:37じひょうをかいて
やめちゃえよ
ちなみにヒラ社員は退
0072デフォルトの名無しさん
2009/06/13(土) 04:10:23エンコード高速化対応お待ちしております。
DirectX 11講座（中編）
非ゲーマーのアナタのパソコンも
DirectX 11演算シェーダーでスーパーコンピューターに変身する！
http://game.watch.impress.co.jp/docs/series/3dcg/20090327_79998.html
GPGPUの場合は、組んだGPGPUプログラムがATIかNVIDIAのどちらかでしか動かない、
踏み絵的な「ATI対NVIDIA」なのだ。
これではGPGPUの進化、発展、普及が望めない。
そこでGPGPUの標準化プラットフォームが強く望まれるようになった。
このGPGPU標準プラットフォームを、Windows環境下で提供しようと出てきたのがDirectX 11ということになる。
DirectX 11は、このGPGPUの標準プラットフォームとして「DirectX Copmute Shader」（演算シェーダー）を提供する。
演算シェーダーでなにができるのか
http://game.watch.impress.co.jp/img/gmw/docs/079/998/html/3dd1103.jpg.html
0073デフォルトの名無しさん
2009/06/14(日) 15:32:58DirectX11に負けそう
0074デフォルトの名無しさん
2009/06/14(日) 19:07:550075デフォルトの名無しさん
2009/06/14(日) 19:09:31金と開発力の関係が
急速に悪くなっててやばいんだよ
0076デフォルトの名無しさん
2009/06/14(日) 20:19:340077デフォルトの名無しさん
2009/06/14(日) 20:26:04仕様はともかく実装はベンダー任せじゃないの？
0078デフォルトの名無しさん
2009/06/14(日) 20:57:39コンシューマ用途じゃ、扱う問題が小さい+レスポンス重視だから
GPGPUが有効な物でも実力の10%程度しか出せないものが殆ど。
GPGPUが本当に有効に働くのは、スパコンでやるような
大規模な科学技術計算みたいなものなのだから
0079デフォルトの名無しさん
2009/06/14(日) 21:01:39まぁDirectXとのInteroperabilityがもっと上がったら、テクスチャ動的生成とかに使えそうな気はするけど
0080デフォルトの名無しさん
2009/06/14(日) 21:16:000081デフォルトの名無しさん
2009/06/14(日) 21:22:500082デフォルトの名無しさん
2009/06/15(月) 01:17:56でもMSって対抗馬がいないと頑張らないからMSファンにとってもOpenCL重要
0083デフォルトの名無しさん
2009/06/16(火) 00:13:35他のOSではOpenCLって感じに棲み分けができるんでは？
最終的にはPhysXとHavokもDirectXに統合されるんじゃないかね。
GPUメーカー依存の規格は最終的には滅ぶ。
0084デフォルトの名無しさん
2009/06/16(火) 00:25:41いやそれは無い
Intelが新しいGPUの代理店募ってるし
既存のチャンネル潰してIntelに振り分ければ
報奨金出るから、今後の情勢として代理店レベル
開発者レベルどの層でもIntelとMSの独自規格で
占められるはず。
0085デフォルトの名無しさん
2009/06/16(火) 00:44:22○万個ただであげるとかだよｗ
0086デフォルトの名無しさん
2009/06/16(火) 01:03:380087デフォルトの名無しさん
2009/06/16(火) 02:02:18StreamとかHavokとか。OpenCLも発表だけは早かったけど今はNVに水あけられてるだろ？
IntelはATiを上回る糞ドライバっぷりで、ららびーが出た時点ではまともに動作するのかも怪しいし。
NVの優位はそう簡単には覆らないんじゃないの？
NVが大ポカして、なおかつATiとIntelが驚異の改善でもしない限り。
0088デフォルトの名無しさん
2009/06/16(火) 02:06:44Intelがもうちょっと別方向のアプローチで頑張ってくれるといい競争になると思うんだけど。
ATIにはもう期待しとらん。。。
0089デフォルトの名無しさん
2009/06/16(火) 02:08:58先日WindRiver買収したけどここのコンパイラがヘボでもICCダメって話にはならんわけで
0090デフォルトの名無しさん
2009/06/16(火) 20:15:20HavokはIntelだしOpenCLはAppleですよ？
0091デフォルトの名無しさん
2009/06/16(火) 20:23:30ATiはHavokと契約してライセンスうけとるよ
あとOpenCLは名前の通りオープン規格だし、規格策定にはAMD、nVidia、Intelを含む主要メーカーが参加してる
別にApple専用規格じゃない
0092デフォルトの名無しさん
2009/06/16(火) 20:32:02Larrabeeのドライバは元ATIとNvidiaのエンジニア
で構成される主力部隊で開発しているから
完成度は従来よりも高いよ
0094デフォルトの名無しさん
2009/06/16(火) 21:29:539月後半か10月中旬に配られるから
大丈夫順調順調
0095デフォルトの名無しさん
2009/06/16(火) 23:17:51>現状GPGPU技術ではnVidiaの一人勝ち感があるなぁ。
しかし、GPGPU自体が、全然勝ち感がないね。。
0096デフォルトの名無しさん
2009/06/16(火) 23:23:58いわば始まってもいない状態で、勝ち負けを語る段階にない。
0097デフォルトの名無しさん
2009/06/16(火) 23:32:1990%Compute Shaderって言われてるよ
1社で1500億円投入すると言われている
OpenCLは集金がもう破綻していて
そろそろ予算尽きる
0098デフォルトの名無しさん
2009/06/16(火) 23:40:11OpenCLは計画が幾ら遅延しようとUNIX系列やその他のOS用に開発は続行されるだろう。
0099,,・´∀｀・,,）っ-○○○
2009/06/16(火) 23:56:320100デフォルトの名無しさん
2009/06/16(火) 23:57:56もちろん、nVidia PhysXみたいなコンシューマ用途に限るのであればCompute Shaderが優位だとは思う
0101,,・´∀｀・,,）っ-○○○
2009/06/16(火) 23:59:200102デフォルトの名無しさん
2009/06/17(水) 00:04:12ですよねーｗ
0103デフォルトの名無しさん
2009/06/17(水) 01:59:34中途半端だとVRAMとのメモリ転送などがあるからかえって遅くなる
だから一般アプリではあまり用途がないんだよね
0104デフォルトの名無しさん
2009/06/17(水) 07:04:170105デフォルトの名無しさん
2009/06/17(水) 23:33:03京都大学の掲示板で
＞nvidiaのグラフィック統合チップセットで、このatomの弱点を補うことはできない
＞IONがそもそもGPGPUとは違う話である
という主張があるんですが、そんなにGPGPUってカスなの？
http://www.kyoto-u.com/lounge/pc/html/200903/09030002.html
0106デフォルトの名無しさん
2009/06/17(水) 23:38:45Larrabee以外はカスだね
0107デフォルトの名無しさん
2009/06/17(水) 23:46:37それを書いてる奴の文章が、有り得ないくらい糞だから読解しづらいけど
要約すると「動画再生とか一部の用途に限ってはIONでAtomを補えるが、それ以外では役に立たない」ってことでしょ
で駄文の読解はそこまでとして、GPGPUは向いてる用途（ベクトル化、並列化がしやすくてかつ重い）に関しては十分な性能を持ってる
ただ、まだまだGPGPUに移植するのが面倒なのと、その上で性能を出すのが面倒だから今一はやらない
Google Scholarで、GPGPUとか「GPU acceleration」とかで検索かければ山ほどヒットするはずだから
興味有るなら自分で読んでみるのがいいと思うよ
0108デフォルトの名無しさん
2009/06/17(水) 23:50:320109デフォルトの名無しさん
2009/06/18(木) 00:27:08なんだかアンチマックかGPGPUを憎悪しているのか
希望の光を遮られていたような気分でしたが、
ちょいとホッとしました。まだまだこれからですね。
0110デフォルトの名無しさん
2009/06/18(木) 00:34:24それもすごくシンプルな。
並列化しにくい問題や分岐が厳しい問題には向いていない、というか使えない。
ごく一部の処理は速くなるけど、IONがあるからといってAtomがCore 2 Duoの性能になるわけじゃない。
0111デフォルトの名無しさん
2009/06/18(木) 03:34:23Core2QuadのSSEに負けるからなぁ。
0112,,・´∀｀・,,）っ-○○○
2009/06/18(木) 03:48:00最大スループットの理論値自体がかなり無茶なんだよ。
Cell SPEですら一応は積和算を発行しつつロード・ストアが並列実行できるような設計になっている。
0113デフォルトの名無しさん
2009/06/18(木) 07:21:030114デフォルトの名無しさん
2009/06/18(木) 07:27:52ですよねーGPGPUなんてバカネタですもんねー
0115デフォルトの名無しさん
2009/06/18(木) 17:36:55GPGPUはともかく、その掲示板って天下の京大生が書いてるとは思えない
APPLE製PC だとか IONがそもそもGPGPUとは違うだとか
アホの巣窟みたいだ
0116デフォルトの名無しさん
2009/06/18(木) 19:35:28激しく同意。
叩かれてるやつの態度はともかく言ってること自体は比較的マシで
他のやつの理解度とレベルが低すぎるだけだなぁとか思いながら読んでた。
■ このスレッドは過去ログ倉庫に格納されています