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/
0751デフォルトの名無しさん
2009/10/04(日) 08:08:01一部のゲームもな
結局互換性で勝つ
0752デフォルトの名無しさん
2009/10/04(日) 08:54:47CUDAとかでCPUコードを書くのはデバッグのためでしょ。
>CPUでだけ使う場合に既製のコードをOpenCLに移植するメリットが基本的に無い。
何を自明なことを
0753デフォルトの名無しさん
2009/10/04(日) 09:32:45じゃ団子が帰起を使えるようにいろいろ改良したOpenCL+を作れば良いんだ
0754デフォルトの名無しさん
2009/10/04(日) 09:34:30× 帰起
○ 再帰
0755デフォルトの名無しさん
2009/10/04(日) 10:06:24Applesも現時点のいずれのアーキテクチャ
でも不可能だって諦めてるし
0756デフォルトの名無しさん
2009/10/04(日) 10:06:29そもそもGPUでまともに再帰使えるんか？
0757デフォルトの名無しさん
2009/10/04(日) 10:08:30> 鳴る物いりで登場したCellのスレは今お葬式モードだし。
Cellスレどこよ？見つからないんだが。
0758デフォルトの名無しさん
2009/10/04(日) 10:14:03http://pc12.2ch.net/test/read.cgi/tech/1249915266/
なんでみつからないのかがわからない
0759デフォルトの名無しさん
2009/10/04(日) 10:41:280760デフォルトの名無しさん
2009/10/04(日) 11:06:10OpenCLはそれをベースに、汎用的にどのGPUでもそれなりに動いてくれるように作られた言語
そりゃ、後者が機能で前者に劣るのは当然
0761デフォルトの名無しさん
2009/10/04(日) 11:18:550762,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 11:33:50無理
ワープ単位で命令ポインタが同じ方向にしか動かせないから
似非スカラを辞めない限り無理
言語レベルで分岐があればネイティブコードレベルではプレディケートで両方のパスを実行
とろくさいこと山の如し
LarrabeeはベクトルをC++的なあのベクトルとして扱ってるからいざとなればスカラに落とし込むことで
再帰を表現可能。
もちろんその時同じハードウェアスレッド内の要素は並列処理じゃなくて逐次処理になる。
extactps rcx, xmm0, 0
call procN
extactps rcx, xmm0, 1
call procN
extactps rcx, xmm0, 2
call procN
extactps rcx, xmm0, 3
call procN
0763,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 11:34:55スカラに落とし込むときのイメージとしてはこんな感じね
0764デフォルトの名無しさん
2009/10/04(日) 11:39:32文法上再帰を許しても、ループに出来ない場合
コンパイル時にエラーが出るとか。
0765デフォルトの名無しさん
2009/10/04(日) 11:47:450766,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 11:48:02最終的に0になったときに全部一緒に抜けるんだよな
0767デフォルトの名無しさん
2009/10/04(日) 18:17:12今Larrabeeの話しなんかしててもしょうがない
現状ではnVidia一択
今後AMDやIntelが良くなればそのときに買い換えればよい
グラボなんて別に高くないし、取り替えられるのだから
0768デフォルトの名無しさん
2009/10/04(日) 18:19:56金持ちは
0769デフォルトの名無しさん
2009/10/04(日) 18:40:28Larrabeeはハードを140ドル未満で投入してくるぞ
0770デフォルトの名無しさん
2009/10/04(日) 18:48:53じゃあ、貧乏人だったらLarrabeeを今買うか？
そんなの不可能だろう？
貧乏人であってもLarrabeeなんて不毛な話だよ
0771デフォルトの名無しさん
2009/10/04(日) 18:50:03いやだからそれは2年後に考えればいいということだろ。
将来性とか考えずに今現在の時点で費用対効果を考えればnVidia一択であると>>767は言ってるんだから。
0772デフォルトの名無しさん
2009/10/04(日) 19:04:07>>769の主張だと足並み揃う2年後でよくねって思うけど
NVidiaがドカタ言語に仕上げてくれるなら今から取り組む価値はあるけど
だんごと一緒にLarrabeeのシミュレータで遊んでいたほうが
有意義だと思う
0773デフォルトの名無しさん
2009/10/04(日) 19:06:54他社製品は意味をなくす
0774デフォルトの名無しさん
2009/10/04(日) 19:14:07シミュレータで遊ぶにしても2年は長い
0775デフォルトの名無しさん
2009/10/04(日) 19:20:46実際GT300って今年中に出るの？
0776デフォルトの名無しさん
2009/10/04(日) 19:36:36多分来年の春ごろ
夏ごろになる可能性もある
それまではAMDがグラボ市場の覇者
そして、再来年の春にはGPU搭載CPUが発売され
ゲーマーがGPUを購入する時代が終焉する
今のGPUはGPGPU用のアクセラレーターとしての価値しかなくなる
ちなみに、NVは売り上げの３分の１を占めるチップセット市場からも
撤退を余儀なくされている
数年以内にNVはまともの売れる製品がなくなる
さよなら、NV
,,,
( ﾟдﾟ)つ┃
0777デフォルトの名無しさん
2009/10/04(日) 19:45:150778デフォルトの名無しさん
2009/10/04(日) 19:49:400779デフォルトの名無しさん
2009/10/04(日) 20:10:25実質的にnVidiaしか選択肢ないんだよ
悲しいことに
0780デフォルトの名無しさん
2009/10/04(日) 20:38:040781デフォルトの名無しさん
2009/10/04(日) 20:40:07平行で新設計のGPUでもつくってんのかね？AMDは
0782デフォルトの名無しさん
2009/10/04(日) 20:47:270783,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 21:01:170784デフォルトの名無しさん
2009/10/04(日) 21:09:17bit切り出しと単純な例外処理だけじゃない。
0785,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 21:19:02Intelがやる理由はキャッシュ容量・メインVRAM帯域の節約のためらしいが。
0786デフォルトの名無しさん
2009/10/04(日) 21:21:520787,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 21:24:180788デフォルトの名無しさん
2009/10/04(日) 21:26:28Larrabeeでさえデモやってるのに
0789デフォルトの名無しさん
2009/10/04(日) 21:31:010790デフォルトの名無しさん
2009/10/04(日) 21:35:24それこそglideとかHEIDIもやろうと思えば
0791,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 21:36:53PCSX2のGSエミュとかやらせたらフレームレートと再現度両立できそうだって
開発者が言ってたりする
0792デフォルトの名無しさん
2009/10/04(日) 23:48:14しばらくこの板来てなかったから記憶が定かでないが
0793デフォルトの名無しさん
2009/10/04(日) 23:53:28俺が改心させてやった
0794,,・´∀｀・,,）っ-○○○ ◆???
2009/10/04(日) 23:57:13批判してるのは先見性の無い奴だけ
方向性は正しいだろ
まあAMDがBulldozerをあっさりAVX互換化したくらいだし
FusionがLRBni互換になっても何ら不思議じゃない
0795デフォルトの名無しさん
2009/10/05(月) 00:11:09転職をおすすめしとく
0796デフォルトの名無しさん
2009/10/05(月) 00:12:30まだ20代だったらお友達になって欲しい。
0797,,・´∀｀・,,）っ-○○○
2009/10/05(月) 00:16:290798デフォルトの名無しさん
2009/10/05(月) 00:17:05SEDとか
0799デフォルトの名無しさん
2009/10/05(月) 00:19:070800デフォルトの名無しさん
2009/10/05(月) 00:23:45で？
0801,,・´∀｀・,,）っ-○○○
2009/10/05(月) 00:24:36ゲーム業界には、前世代で圧倒的な勝利を飾ったのに後継機種で会社傾けるほどの大赤字
なんて例もあるからね。
ただIntelはマーケティングを含めて隙がなさ過ぎる。
Intelは22nmが順調に微細化できれば2〜4コア＋Larrabee 8コアくらいの統合チップ出してくるだろうよ
0802デフォルトの名無しさん
2009/10/05(月) 00:31:060803デフォルトの名無しさん
2009/10/05(月) 00:32:09で、いつものゴミオンボつけて売り出す
情弱向けに誇大広告うてば勝手に売れてく
いつものパターン
0804デフォルトの名無しさん
2009/10/05(月) 00:32:18獲物のアム厨がレッドブックに載ったので名無しに戻ったらしい
0805デフォルトの名無しさん
2009/10/05(月) 00:37:19なんじゃそりゃ。
Cellとともに滅びたのかと思ってた。
0806,,・´∀｀・,,）っ-○○○ ◆???
2009/10/05(月) 00:39:31そのゴミオンボの後継がLarrabeeなんだが。
SIMD以外はシンプルにしないと10〜12コアなんて載らないよ。
8コアくらいでも22nmになれば70〜80mm²になる。
これは32nmのSandy Bridgeに載るGPUと同程度。
0807デフォルトの名無しさん
2009/10/05(月) 03:54:15そんなものは今までGPUだった分のトランジスタも活用できる程度でしかない
TSMCも1年遅れ程度になってきたからあまり優位に立てないのもあるが
CPUはもう限界だしそんなに速くなくてもGPU(Larrabee)があるし…とIntel自身が白状している
Larrabeeは全方位アクセラレーターだ
0808デフォルトの名無しさん
2009/10/05(月) 04:18:110809デフォルトの名無しさん
2009/10/05(月) 05:28:04外注受けてるとこでここより技術が上なのはGFしかないし。
0810デフォルトの名無しさん
2009/10/05(月) 05:38:040811デフォルトの名無しさん
2009/10/05(月) 21:31:040812,,・´∀｀・,,）っ-○○○ ◆???
2009/10/05(月) 22:48:51その上でだ。
Larrabeeは8コアあればNVIDIA換算で128SPくらいだよな。
0813デフォルトの名無しさん
2009/10/05(月) 23:26:44PixeluxとAMD、Digital Molecular Matterエンジン向けのOpenCLアクセラレーションを開発
ttp://khronos.jp/news/2009/09/pixeluxamddigit.html
PixeluxはAMDと共同で、Digital Molecular Matterエンジン向けのOpenCLアクセラレーションを開発しています。
Pixeluxはルーカス・フィルムで特殊効果制作に使用された Digital Molecular Matterエンジンを開発しています。
ってことはクローズに数千ドルの融資を獲得したから
オープンにしてレッドオーシャンで戦う必要はないんだな
0814デフォルトの名無しさん
2009/10/05(月) 23:34:06あれいつの話になるんですかね？
0815デフォルトの名無しさん
2009/10/05(月) 23:35:430816デフォルトの名無しさん
2009/10/05(月) 23:37:050817デフォルトの名無しさん
2009/10/05(月) 23:37:32来年ならデモ機レベルで64コア出せるって言ってるよ
0818デフォルトの名無しさん
2009/10/06(火) 00:06:20「GPUとして」GTX280レベルを出すならその位要る
0819デフォルトの名無しさん
2009/10/06(火) 00:10:040820デフォルトの名無しさん
2009/10/06(火) 01:28:500821デフォルトの名無しさん
2009/10/06(火) 08:08:21同意。
俺もCPUの論争で散々言ったが、Intelはプロセス技術にもの言わせてるだけだよな。
団子がPPCのヘタレっぷりとVLIWのItaniumを槍玉に挙げてx86最強とか、
未だにRISCだのCISCだのニュースの記事を鵜呑みにしたような事を言っているのを聞くと、
それは違うんじゃないかと言いたくなる。
0822,,・´∀｀・,,）っ-○○○ ◆???
2009/10/06(火) 08:50:470823デフォルトの名無しさん
2009/10/06(火) 08:52:390824,,・´∀｀・,,）っ-○○○ ◆???
2009/10/06(火) 09:13:29キツキツにチューンしてるわけではないようだが。
デコーダ側が2命令/clkなのにLoad + 演算 + Storeを同時発行できるのは
少なくともRISCみたいな2〜4バイト固定のフォーマットじゃ出来ない芸当だ。
あと、Itaniumは例外視すべきじゃないよ。最強のプロセス技術をもってしてアレなんだろ？
逃げるのはただの詭弁でしかない。
0825デフォルトの名無しさん
2009/10/06(火) 11:33:37整数演算性能に関していえばRISC ISAは前世紀に事実上死んでる
当時のSPECint見てみればわかるが、所詮はキャッシュメモリの容量で
性能稼いでただけのハリボテということが露見している
---------------------------------------
Model Name: TDZ300
CPU: 200MHz Pentium Pro Processor
FPU: Integrated
Number of CPU(s): 1
Primary Cache: 8KBI+8KBD / Secondary Cache: 256KB(I+D)
SPECint95 8.04 / SPECint_base95 8.04 ※95年12月登録
http://www.spec.org/cpu95/results/res9512/p040.html
Model Name: RS/6000 43P-140
CPU: 200 MHz PowerPC 604e
FPU: Integrated
Number of CPU(s): 1
Primary Cache: 32KBI+32KBD on chip / Secondary Cache: 1MB(I+D) off chip
SPECint95 7.79 / SPECint_base95 6.99 ※97年4月登録
http://www.spec.org/cpu95/results/res97q2/cpu95-970414-01779.html
----------------------------------------
浮動小数だけはレジスタ本数とオペランド数ないと性能稼げないから
スタック形式のx87は圧倒的に不利だったが（その点でLarrabeeには死角はない）
整数性能に関して言えばIntelの対RISC性能はP5で肉縛しP6で追い越し
NetBurstで大きく引き離した
0826デフォルトの名無しさん
2009/10/06(火) 11:36:130827デフォルトの名無しさん
2009/10/06(火) 11:44:30実効性能ではPPCのが上でしょ。
0828デフォルトの名無しさん
2009/10/06(火) 11:47:050829デフォルトの名無しさん
2009/10/06(火) 12:39:19Larrabeeすら関係無いIntel賛美は他でやれ
0830デフォルトの名無しさん
2009/10/06(火) 12:44:57中立な数字出したら完全敗北なのが>>825なんだが。
AppleのIntel移行すら未だに認められない糞マカ乙
0831デフォルトの名無しさん
2009/10/06(火) 12:58:38結果性能向上をはかるもので、命令あたりの演算の密度は犠牲にしてる。
同クロック・同命令発行数なら、CISCに性能で勝てるわけがないだろ。
ついでにいうとGPUも命令あたりの演算処理単位からいえば一種のCISCだ。
0832デフォルトの名無しさん
2009/10/06(火) 12:59:210833デフォルトの名無しさん
2009/10/06(火) 13:25:050834デフォルトの名無しさん
2009/10/06(火) 13:41:280835デフォルトの名無しさん
2009/10/06(火) 13:47:08ぶっちゃけメモリアドレスをオペランドにとれる命令全部。
ベースアドレス＋インデックス×スケール＋即値によるアドレスの算出と
ロード操作を1命令に含めることができる。
同じ命令内のオペレーション間で依存関係が決まってるから
スケジューリングもしやすい。
んで、アドレス演算のルールに特化した特殊な演算ユニット（AGU）で
解決することで性能向上を図ってる。
RISCだとアドレスの算出すら整数命令で、汎用の整数ユニットを使って
計算することになるから、そこで大きな性能差が生じる。
0836デフォルトの名無しさん
2009/10/06(火) 14:03:52事実GeForceはワープ内の要素ごとに独立にメモリアドレス計算やってたり、
メモリ周りの命令に関してはかなり効率悪いし
fermiのSPは浮動小数と整数が2並列発行できるようにして
浮動小数演算をやりつつアドレス計算もできるようになってるが
それまでのGT200まで整数と浮動小数は排他動作だったから
読み書き対象のアドレス計算のたびに浮動小数演算の発行が止まってたわけで
実効性能を下げる要因になってた。
0837デフォルトの名無しさん
2009/10/06(火) 18:25:32この板にもベンチマークとかシミュレーターの意義がわからない馬鹿が居たんだな
0838デフォルトの名無しさん
2009/10/06(火) 19:18:53じゃfermiで解決だね
0839デフォルトの名無しさん
2009/10/06(火) 19:34:30全然解決してねー。
サイクルあたり2命令しか発行できないのに
アドレス生成だけに1命令分取られるだけでも大きなロス
Larrabeeのほうは、アドレス生成つきロードを伴うマスクつき積和算と
スカラ命令あるいはストア操作を同時にデコード・発行できる。
つまり1クロックあたりの実効オペレーション数で水をあけられる可能性がある。
0840デフォルトの名無しさん
2009/10/06(火) 21:03:42int,fpって並列可能なんだよね？
2つのIU使って16spに命令出すの?
fermiって
0841デフォルトの名無しさん
2009/10/06(火) 21:37:24で、そんなアドレッシングがどれだけ使われるわけよ？
0842デフォルトの名無しさん
2009/10/06(火) 22:01:350843デフォルトの名無しさん
2009/10/06(火) 22:04:16GPUの場合、メインになる大規模配列へのアクセスなんかだとアドレス計算なんかは
コードで明示しなくてもハードで自動でやるんでなかったっけ？
0844デフォルトの名無しさん
2009/10/06(火) 22:05:11PPC含めていろんなアーキを触るのは楽しいけれど、
x86が現実的に俺が金を出せる中では最強だと思っているわけよ。
でもRISCとかCISCじゃないでしょ？と言いたかったんだ。
現にAVXではデコーダが軽くなるように変更してるでしょ？
今までの実装に負けを認めてるわけよ。
でもそれはRISCに負けたわけじゃないし、CISCが勝っているわけでもない。
Intelは今まで割と酷いアーキだったと思うんだけど……分かんないかなあ。
0845デフォルトの名無しさん
2009/10/06(火) 22:14:32負けを認めただの何だの
典型的なIntelアンチですね
0846デフォルトの名無しさん
2009/10/06(火) 22:33:490847デフォルトの名無しさん
2009/10/06(火) 22:37:38ソースレベルと機械語レベルを混同してる
0848,,・´∀｀・,,）っ-○○○ ◆???
2009/10/06(火) 22:57:22なにが勝って何が負けたの？
x87もMMXもSSEも潰さずに新たなSIMD命令を追加出来るのはまさに可変フォーマットたるCISCのメリットだろ
命令長の縛りで好きにOperand空間を拡張したりできないのがRISCだよ。
360のCPUなんか、SIMDレジスタを128本に拡張した分、4オペランド命令や1バイト単位の操作命令が
削られてたりする。
それから君はAVXを根本的に理解していない。
0849,,・´∀｀・,,）っ-○○○ ◆???
2009/10/06(火) 23:40:41伝統的CISCアーキテクチャの新たな1ページですよAVXにしてもLRBniにしても
可変アドレッシングモードがある限りx86はどこまでもCISCだ。
add eax, ecxみたいな1バイト命令がたとえば4バイト固定に変わりますか？なりません。
0850,,・´∀｀・,,）っ-○○○ ◆???
2009/10/06(火) 23:58:37どっかのプログラムをテキトーに逆アセンブラかけてみろ。アホみたいに使われてる。
AMDのCPUがALUとは別個にAGUを3つも装備しちゃうくらい使われてる
あとついでにいうと32ビットとか64ビットとかの即値を命令ストリームからダイレクトに供給できることも
パフォーマンス要因として大きい。
どっかの情けないCPUには32ビットレジスタに16ビットずつにわけて即値ロードする命令があったりするけど
パーシャルライトのレイテンシで氏ねる。
メモリ空間が広がるほど、即値のビット幅に対する要求がシビアになる。
CellのSPUなんて直接アドレッシングできるメモリが物理的に256KBしかないから即値フィールドが16ビットもあれば
左に２ビットあればロード命令の即値フィールドとしては十分だが、
特化型じゃない普通のCPUでは4GB以上に対してアドレッシングするわけで。
論理メモリ空間が広がるほどRISCは使えなくなる。
8バイト固定長のRISCにすればいいだろって？
氏ねばいいと思うよｗ
0851デフォルトの名無しさん
2009/10/07(水) 00:11:52それがIntelの優位性をより伸ばした。そんな説がありえるのか？
■ このスレッドは過去ログ倉庫に格納されています