- 1 名前：デフォルトの名無しさん [2007/08/29(水) 17:08:58 ]
- いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
GPGPUについて語りましょう
前スレ
GPGPU
pc11.2ch.net/test/read.cgi/tech/1128780920/
関連スレ
pc11.2ch.net/test/read.cgi/tech/1167989627/
参考リンク
総本山? gpgpu.org
www.gpgpu.org/
CUDA
developer.nvidia.com/object/cuda.html
GPUをCPU的に活用するGPGPUの可能性
pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/
- 816 名前：デフォルトの名無しさん mailto:sage [2008/12/10(水) 23:51:34 ]
- 貧乏人はMSに期待しろ
結局それが一番堅い
- 817 名前：デフォルトの名無しさん mailto:sage [2008/12/11(木) 11:11:46 ]
- ShaderAnalyzerからGPGPU分を分離したようです。
Stream KernelAnalyzer
ttp://developer.amd.com/gpu/ska/Pages/default.aspx
- 818 名前：デフォルトの名無しさん mailto:sage [2008/12/11(木) 23:34:54 ]
- CALでASCIIだけは
処理できそうなんだけど
うまくいかねぇｗ
詰めが甘いんだよなぁ
うーん
- 819 名前：デフォルトの名無しさん mailto:sage [2008/12/12(金) 00:09:20 ]
- StreamSDK 1.3
完全にDebianでは動かなくなった
Debian見捨てたなこりゃ
- 820 名前：デフォルトの名無しさん mailto:sage [2008/12/12(金) 01:36:45 ]
- それ以前にDebianだとfglrxが随分前からインストール出来ないだろ。
experimentalですら11月に10月号が出てそのまま足踏みって時点でDebian側も投げてる。
つまりは素直にUbuntuにしろって事だ。
- 821 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 00:24:33 ]
-
AMD，Open CL 1.0サポートを表明。2009年のSDK配布開始を予告
www.4gamer.net/games/080/G008082/20081215051/
- 822 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 00:34:22 ]
- 「ATI Stream SDK 1.3」の大幅な機能強化をベースとするバージョン1.4は、
より細分化されたデータタイプのサポート、グラフィックスAPIの相互運用性、
マルチGPUのサポート、Brook＋へのスレッドレベルのデータ共有を追加できるよう設計されています。
このほか、「ATI Radeon HD 4870 X2グラフィックス」へのサポートの向上や、
複数の「ATI FirePro 3Dグラフィックス・アクセラレータ」のサポートなどの機能強化が図られています。
「ATI Stream SDK」のバージョン1.4の公開は2009年第1四半期中を予定しています。
1.4でようやくマルチGPU対応か
サイドポートも有効になるか？
- 823 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 01:19:38 ]
- マルチGPUのサポートと4870X2のサポート向上を別表記してるんだからやってくれるだろう。
本当にサイドポートという機構が存在すればの話だが。
- 824 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 06:09:14 ]
- 結局マルチコアCPUで落ち着きそうだな
- 825 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 08:45:23 ]
- 結局4670でもDP対応しているようだな。
- 826 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 10:10:07 ]
- だってVLIWの問題だもの
どうにでもなる
- 827 名前：デフォルトの名無しさん mailto:sage [2008/12/18(木) 10:25:18 ]
- なんか、CUDAもAMD Streamもスルーして、OpenCLに絞った方がいいのかなぁ
開発リソースが有り余ってる訳じゃないし…
- 828 名前：デフォルトの名無しさん mailto:sage [2008/12/18(木) 15:04:18 ]
- 専用ので作った方がピークパフォーマンスは高いかもしれないけど
ATiもヌビもOpenCLに全面対応すると言ってるんだからそう違いはないだろうな。
- 829 名前：デフォルトの名無しさん mailto:sage [2008/12/18(木) 15:11:35 ]
- OpenGLでQuadroとFireGLが既にやっているように、
FireStreamやTeslaを売るためにGeForceやRadeonでOpenCL対応が制限されそうで嫌だ
結果的にDirectXのComputeShaderの方が遥かにアベレージパフォーマンス良かったりしてな
- 830 名前：デフォルトの名無しさん mailto:sage [2008/12/18(木) 22:10:42 ]
- >>829
> OpenGLでQuadroとFireGLが既にやっているように、
FireStreamとRadeonってどこが違うのって聞かれたAMDの中の人は
サポート（供給期間の保証とか）が違うだけだよって普通に言っちゃってたよ。
- 831 名前：デフォルトの名無しさん mailto:sage [2008/12/18(木) 23:35:25 ]
- >>830
VRAMの容量が4Gが出るのはFSのみだって
行ってたよ。
09末までに2Gは両方で出るようだけど
- 832 名前：デフォルトの名無しさん mailto:sage [2008/12/19(金) 01:23:59 ]
- >>831
kwsk
- 833 名前：,,・´∀｀・,,）っ-●◎○ mailto:sage [2008/12/19(金) 01:38:26 ]
- 9600GTで2GBのネタみたいな仕様のカードあったな。
Tesla代わりに使えるんじゃないかと思ったもんだ。
VRAM大容量＝64ビット専用と認識してるが
- 834 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 18:33:42 ]
- AMDのサイトで"R6xx Family Instruction Set Architecture"読んでるんだが、
普通のプロセッサの資料と勝手が違って違って読みにくい。
なんか、アーキテクチャの概略がわかる資料とか知ってる心やらしい人がいたら
教えてください。
- 835 名前：,,・´∀｀・,,）っ-●◎○ mailto:!sage [2008/12/27(土) 22:32:56 ]
- 1つのストリームプロセッサエレメントがX, Y, Z, W, Transからなる5-WayのALUがぶら下がったVLIWで構成されてる。
- 836 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 03:35:37 ]
- >>834
cpがcfを解釈するようになったので、cfの説明とaluに対するopsのフォーマットだけだな、r600isaは。
まずプログラミングマニュアルの方を見た方がいいと思う。
- 837 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 10:25:21 ]
- >>835
thx
でも、さすがにそれはネットメディアの解説記事で知ってたｗ
>>836
ｔｈｘ
早速読んでみる。
しかし、ブロックダイアグラムだけ見ると癖の強いアーキテクチャだな＞R6xx
演算器の間の連携手段が小容量のR/Wキャッシュだけってのはこの規模の
SIMDマシンとしてかなり弱い気がする。
- 838 名前：デフォルトの名無しさん mailto:sage [2008/12/29(月) 13:07:13 ]
- PV、PSあたりの仕様を見ると
ALU Clauseの存在意義が分かって面白い。
- 839 名前：デフォルトの名無しさん mailto:sage [2008/12/29(月) 13:34:55 ]
- GSが入った所にDmaCopyってのが入ってるけどなんか厄介そうだな。
ジオメトリシェーダーって全然ノータッチなのだが、結構面倒なのかな?
this program type is optionalなので意味分からない時は無視するが勝ちかorz
- 840 名前：デフォルトの名無しさん mailto:sage [2008/12/29(月) 13:57:16 ]
- ILじゃなくてISAで何を作ろうとしてるのかね?
- 841 名前：,,・´∀｀・,,）っ-○◎● mailto:sage [2008/12/29(月) 17:18:29 ]
- ネイティブアセンブラじゃね？
俺もCUDAのPTXが嫌いなんだが
- 842 名前：デフォルトの名無しさん mailto:sage [2009/01/07(水) 08:20:20 ]
- amdのstream kernelanalyzerて走らせるのにstream sdk以外になんかいる？
もらってきた実行ファイル叩いてもコンソールが数秒開く以外反応がないんだが。
- 843 名前：デフォルトの名無しさん mailto:sage [2009/01/07(水) 08:25:25 ]
- コンソールアプリなら、コンソールで使えよ。
- 844 名前：デフォルトの名無しさん mailto:sage [2009/01/08(木) 00:11:48 ]
- amdユーザなんて所詮このレベルｗ
- 845 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 19:58:38 ]
- >>844
どこからどうみても、一番レベルの低いレスをどうも。
- 846 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 03:18:18 ]
- よくわからんのだけども、折角だから流行りそうなの勉強したいなと思ったんですが
調べてみて
-AMD-
CTM
Havok
-NVIDIA-
CUDA
Physx
-他-
BrookGPU
PeakStream
RapidMind
こんんあ感じかな？
今のところCUDAが流行ってるんですか？
あと、今後PhysxとかHavokとかの物理エンジンがCUDAやCTMなんかに統合されるとかいう可能性とか
あったりするんでしょうか？
- 847 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 04:16:02 ]
- 今年はIntelもメニーコアの汎用GPUを出すし先のことは分からない
Intelはx86命令セットを実装するからたぶんこれが生き残る
現状一番扱いやすくて普及してるのがCUDAとphysx
AMDは資料もろくにないし言語仕様もぐちゃぐちゃで使い物にならない
- 848 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 04:45:32 ]
- つ[OpenCL]
- 849 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 08:06:00 ]
- ハードよりの資料はAMDの方が充実しているだろ。
Brook+が微妙なだけでCALの仕様はまとも。
まあ、CALはほぼアセンブリだから、高級言語で記述したいなら
Brook+でどうにかするしかないのが最大の難点だが。
- 850 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 23:38:04 ]
- >>847
Larrabeeは確かにx86命令＋αを実装するみたいだが、果たして普及するかは別問題だぞ
パフォーマンスが出ないんじゃHPC分野からは見向きもされない
そもそもアセンブリレベルでコーディングなんてしないわけで、CUDAなりBrook+なりの高級言語使うのが当たり前になってるんだから
結局はどこまでLarrabee用の言語を構築できるかでしょ
- 851 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 00:00:51 ]
- Intelは言語レベルではなく、OpenMPのようなライブラリっぽいものでLarrabeeサポートしていく方針だったかと。
で、同じコードでマルチCPUやなんかにも対応させるようなことを言ってたような希ガス。
- 852 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 00:18:08 ]
- Larrabeeがどうなるかは知らないけどIntelは独自言語も作ってるし、OpenCLにも対応する予定だよ。
ま、開発はどうにかなるとしてもLarrabeeは消費電力気にしてキャッシュを
強化する代わりに絶対的なメモリ帯域が足りないっぽいのがなあ。
実際のコードはそんなに局所性が高くないものも多いんだよ。
- 853 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 00:46:03 ]
- 別に流行ってないよ。
マニアのみ。
- 854 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 07:11:14 ]
- Larrabee 300W
アホだろｗ
- 855 名前：,,・´∀｀・,,）っ-●◎○ mailto:sage [2009/01/14(水) 15:23:02 ]
- >>852
実はリアルタイムレイトレーシングに最適化されてるとか。
キャッシュの利用によって外部バスの負荷を軽減することで、結果的に省電力化を図れる
みたいな話で、このへんはイスラエルのキャッシュ大容量CPUの設計思想のフィードバックだよ。
メモリコントローラに帯域を狭くするなんて言ってない訳だが、誰が言ったんだ？
しかし、メモリ云々はGeForceあたりでも切実な問題じゃないの？
SMあたりのレジスタファイル倍増したかわりにGeForce8なんかと比べてメモリ帯域減らしてるじゃないの。
>>852
「ハイエンドでも300W以内に収める」とは言ってるが300Wになるなんて誰も言ってないだろ
480SPのGTX295が300一歩手前の状態だから上位はそんなもんだろ
Larrabeeは16Way SIMDユニット搭載だから、32コアでGT100/200換算512SP程度。
- 856 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 17:00:17 ]
- まあWindowsがlarrabeeにカスタマイズされただ嫌でも買うでしょ
- 857 名前：デフォルトの名無しさん [2009/01/19(月) 05:19:28 ]
- 3Dゲームしている時以外は
GPUパワー余っているから
今こそ分散コンピューティングの時
- 858 名前：842 mailto:sage [2009/01/22(木) 21:02:05 ]
- stream Kernelanalyzerだが動いた。
もらってきたファイルの拡張子が.exeだったんでそのまま走らせるのかと思ってたら、実は.MSI形式だった。
恥ずかしい。
- 859 名前：デフォルトの名無しさん [2009/01/27(火) 09:29:34 ]
- >>858
あげてみる
- 860 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 02:43:34 ]
- マイコミジャーナル
OpenCLのパワーが一目瞭然のデモムービーが公開
ttp://journal.mycom.co.jp/news/2009/02/04/023/index.html
- 861 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 05:23:02 ]
- OpenCLはマルチコア対応でしかもSSEなんかで最適化されてるから
GPUよりクアッドコアCPUのが早いというｗ
- 862 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 09:02:03 ]
- 手軽に複数枚増設できるgpuに対して、cpuを複数つけることは難しいだろう。
それに行き詰まってるcpuよりは、gpuのほうがまだまだ速くなるし、
計算／表示まで1つのハードウェア内で完結したほうがいいだろう?
cpuの仕事ってioと制御だけでもいいくらい。
- 863 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 09:12:51 ]
- GPUメモリからシステムメモリへの転送が早ければなあ
- 864 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 09:19:14 ]
- GPUからプロセッサキャッシュへ直接転送できればいいのにな。
- 865 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 23:26:29 ]
- >>計算／表示まで1つのハードウェア内で完結したほうがいいだろう?
それこそCPU有利じゃないかｗ
- 866 名前：,,・´∀｀・,,）っ-○◎● mailto:sage [2009/02/06(金) 13:17:48 ]
- IntelのCtだけど、俺なりに解釈してまとめてみたお
tripper2.kousaku.in/?Ct
- 867 名前：デフォルトの名無しさん mailto:sage [2009/02/06(金) 13:55:53 ]
- >>866
乙
- 868 名前：デフォルトの名無しさん mailto:sage [2009/02/07(土) 11:18:29 ]
- 4亀のGPGPU記事、突っ込みどころが多すぎてもうどうしたものやら。
誰か頼むわ。
- 869 名前：デフォルトの名無しさん mailto:sage [2009/02/07(土) 15:20:21 ]
- ざっと流し読みした限り、そんなに変な箇所は無かったように思うが
ゲーマー向けのGPGPU解説ならあんなもんじゃねーの？
- 870 名前：デフォルトの名無しさん [2009/02/07(土) 16:54:42 ]
- 超解像のような考え方は昔からあるようだな
フリーソフトImageD2
www.tiu.ac.jp/~zohzemi/imgD2/index.html
これは時間軸方向にも参照するものだ。
NVIDIAのMOTIONDSPと同じ考え方だな。
西川善司の大画面☆マニア 第113回 超解像
av.watch.impress.co.jp/docs/20090120/dg113.htm
この方法は数フレームを参照することで低解像な映像のブレから情報量をアップさせるようだが、
この方法だとシーンチェンジやめまぐるしく動く映像では逆効果でめちゃくちゃな映像になるのではないか？
（これは上記のフリーソフトの別ページでも注意点として載っていた）
でも東芝などの日本の各社がやってる1フレームだけで行う超解像はそもそも無理がある。だから不自然な画質になったり、情報量が逆に消失したりする。
Lanczosなどでそのままアプコンしたほうがずっと情報量あるし自然な画質だ。比較してみれば一発で分かる。
plusd.itmedia.co.jp/lifestyle/articles/0812/24/news031_2.html
ここの元画像を720×480にし、それをAVIUTLなどでLanczosでフルHDにしたもののほうがずっと綺麗。
超解像は単純な処理だから柵とか崩れてるし、文字も駄目だし、元からあった情報を処理によって消しちゃう副作用のほうが強い。
超解像、超解像と目新しくいって盛り上げようとしたいのは分かるが、こんなのはまやかしだよ。
www1.axfc.net/uploader/Li/so/24824.zip&key=pass
比較用画像もうｐしておいた
一方、数フレームでやる方法は計算が大変だが、シーンチェンジや盛大な動きの問題さえクリアすればかなり使えそうではある。
MOTIONDSPや↓はそのあたりちゃんとクリアしているのだろうか？
www.flashbackj.com/red_giant/instant_hd_advanced/
- 871 名前：デフォルトの名無しさん mailto:sage [2009/02/07(土) 20:20:03 ]
- なるほどマルチでしたｗｗｗ
ていうかコピペなのね。
gimpo.2ch.net/test/read.cgi/av/1201962634/275
が初出なのかな？ Google によるとだけど。
- 872 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 03:03:55 ]
- >>869
「標準的なプラットフォームの登場」という要望に答えたCUDAって書き方してるのは笑うしかないでしょ。
こことかも
> しかも，CUDAソフトウェアのパフォーマンスは，GPUの世代やモデルに応じてスケーラブルとなるため，
> 開発者もプログラム側も，「動作対象となる GPUがGeForce 8800 GTXなのか，（中略）」といったことを気にする必要がない。
気にしなければ確かにスケーラブルだけどパフォーマンスはでないわけで。
CUDAアプリの殆どがGPUの仕様に合わせてガチガチに最適化してるのを黙ってるのはどうかと。
PTXトランスレータがGPUの個数を考慮してるってのは完全に嘘だ。
NVIDIA PhysXのRadeon制限も自分の妄想語るのに夢中でさっぱり忘れてるみたいだし。
ATI Streamに関してもCTMとCAL ILとHDシリーズのISAをごっちゃにした解説をしてる。
絵の説明のところでATI Stream解禁の本質がCALをドライバに含めることだと正しく説明してるのは評価できるけどね。
CSとOpenCLに関しては、3DAPIとリソースの共有が出来ることが重要なポイントだというのなら
CUDAが両APIのリソースを扱えるってことを説明しないとまずいでしょ。
OpenCL 1.0の仕様はもう公開されてるのに仕様確定が09年6月ごろとかは意味不明だ。
- 873 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 03:08:54 ]
- MOTIONDSPで検索したらモザイク消しの話題があった
それは思いつかなかったｗ
確かに超解像はモザイクが消せるｗ
- 874 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 08:11:31 ]
- 前後のフレームを参照してモザイクを消そうなんて
プログラムのプの字も知らなかった小学生の頃に思いついたけどな。
みんなそんなもんだろ？
- 875 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 09:55:43 ]
- >>872
所詮ユーザー向けのバラ色セールストークなんだから気にするなよ。
- 876 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 16:26:50 ]
- >>874
は？思いつかなかったしそんなの
その発想が出てるだけでもう俺より才能あるし
- 877 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 19:09:29 ]
- >>872
ユーザー向けとしてはその程度でいいだろ
確かに普段書いてるCUDAプログラムなんて、使ってるGPU毎にブロックサイズとかを全部最適化し直してるけど
一般ユーザーにそこまで説明する必要はない
とりあえずGPGPUすげーなって程度の認識を持たせれば十分でしょ
逆にそこまで説明しちゃうと「なんだ役にたたねーじゃん」って印象を与えかねない
まぁ実際問題としてはまだアカデミックな用途がほとんどだけどな
- 878 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 23:30:26 ]
- 実行ポインタやら実行コンテキストはgpuだけで自律制御できるようになったのかな?
その辺の理解がもっと深まればintelやamdの変態cpuを待つ必要がなくなると思うんだけど。
- 879 名前：デフォルトの名無しさん mailto:sage [2009/02/09(月) 05:31:06 ]
- 被写体を３Dモデル化して全フレームからテクスチャを合成して
無限に超解像とか出来る日が来る
- 880 名前：デフォルトの名無しさん mailto:sage [2009/02/09(月) 13:34:59 ]
- >>877
> 逆にそこまで説明しちゃうと「なんだ役にたたねーじゃん」って印象を与えかねない
現状では実際そうだからちゃんと説明しろっていいたいんだが。
|
 |
