トップページ⇒tech
1001コメント273KB

GPGPU#3

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん2009/03/21(土) 19:18:14
GPGPUについて語りましょう

前スレ
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/
0821デフォルトの名無しさん2009/10/06(火) 08:08:21
>>820
同意。
俺もCPUの論争で散々言ったが、Intelはプロセス技術にもの言わせてるだけだよな。

団子がPPCのヘタレっぷりとVLIWのItaniumを槍玉に挙げてx86最強とか、
未だにRISCだのCISCだのニュースの記事を鵜呑みにしたような事を言っているのを聞くと、
それは違うんじゃないかと言いたくなる。
0822,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/06(火) 08:50:47
PPC G4が【同クロック】のAtomに負けてもそう思うか？
0823デフォルトの名無しさん2009/10/06(火) 08:52:39
はいはい負け惜しみ負け惜しみ
0824,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/06(火) 09:13:29
少なくともAtomに関してはSoC製造をTSMCに委託できるように契約してるし
キツキツにチューンしてるわけではないようだが。

デコーダ側が2命令/clkなのにLoad + 演算 + Storeを同時発行できるのは
少なくともRISCみたいな2〜4バイト固定のフォーマットじゃ出来ない芸当だ。

あと、Itaniumは例外視すべきじゃないよ。最強のプロセス技術をもってしてアレなんだろ？
逃げるのはただの詭弁でしかない。
0825デフォルトの名無しさん2009/10/06(火) 11:33:37
未だにRISC信者いるのがきもい
整数演算性能に関していえば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:13
肉薄orz
0827デフォルトの名無しさん2009/10/06(火) 11:44:30
インテルのはいつも都合いい数値しか出さないからなぁ。
実効性能ではPPCのが上でしょ。
0828デフォルトの名無しさん2009/10/06(火) 11:47:05
pu
0829デフォルトの名無しさん2009/10/06(火) 12:39:19
ここGPGPUスレだから
Larrabeeすら関係無いIntel賛美は他でやれ
0830デフォルトの名無しさん2009/10/06(火) 12:44:57
>>827
中立な数字出したら完全敗北なのが>>825なんだが。
AppleのIntel移行すら未だに認められない糞マカ乙
0831デフォルトの名無しさん2009/10/06(火) 12:58:38
RISCは命令セットを単純にしてクロック上げやすくすることで
結果性能向上をはかるもので、命令あたりの演算の密度は犠牲にしてる。

同クロック・同命令発行数なら、CISCに性能で勝てるわけがないだろ。
ついでにいうとGPUも命令あたりの演算処理単位からいえば一種のCISCだ。
0832デフォルトの名無しさん2009/10/06(火) 12:59:21
だってさ
0833デフォルトの名無しさん2009/10/06(火) 13:25:05
x86の命令でなんか演算密度高い命令とかあったっけ？
0834デフォルトの名無しさん2009/10/06(火) 13:41:28
主記憶がレジスタと同じ応答性とスループットになればRISCが勝つよ
0835デフォルトの名無しさん2009/10/06(火) 13:47:08
>>833
ぶっちゃけメモリアドレスをオペランドにとれる命令全部。
ベースアドレス＋インデックス×スケール＋即値によるアドレスの算出と
ロード操作を1命令に含めることができる。
同じ命令内のオペレーション間で依存関係が決まってるから
スケジューリングもしやすい。
んで、アドレス演算のルールに特化した特殊な演算ユニット（AGU）で
解決することで性能向上を図ってる。

RISCだとアドレスの算出すら整数命令で、汎用の整数ユニットを使って
計算することになるから、そこで大きな性能差が生じる。
0836デフォルトの名無しさん2009/10/06(火) 14:03:52
x86の強力なアドレッシングモードはLarrabeeのパワーの源と言ってみる
事実GeForceはワープ内の要素ごとに独立にメモリアドレス計算やってたり、
メモリ周りの命令に関してはかなり効率悪いし

fermiのSPは浮動小数と整数が2並列発行できるようにして
浮動小数演算をやりつつアドレス計算もできるようになってるが
それまでのGT200まで整数と浮動小数は排他動作だったから
読み書き対象のアドレス計算のたびに浮動小数演算の発行が止まってたわけで
実効性能を下げる要因になってた。
0837デフォルトの名無しさん2009/10/06(火) 18:25:32
>>827
この板にもベンチマークとかシミュレーターの意義がわからない馬鹿が居たんだな
0838デフォルトの名無しさん2009/10/06(火) 19:18:53
>>836
じゃfermiで解決だね
0839デフォルトの名無しさん2009/10/06(火) 19:34:30
>>838
全然解決してねー。

サイクルあたり2命令しか発行できないのに
アドレス生成だけに1命令分取られるだけでも大きなロス

Larrabeeのほうは、アドレス生成つきロードを伴うマスクつき積和算と
スカラ命令あるいはストア操作を同時にデコード・発行できる。
つまり1クロックあたりの実効オペレーション数で水をあけられる可能性がある。
0840デフォルトの名無しさん2009/10/06(火) 21:03:42
?
int,fpって並列可能なんだよね？
2つのIU使って16spに命令出すの?
fermiって
0841デフォルトの名無しさん2009/10/06(火) 21:37:24
>>835
で、そんなアドレッシングがどれだけ使われるわけよ？
0842デフォルトの名無しさん2009/10/06(火) 22:01:35
おまえらGPGPUのネタがないからって自作板化するなよ
0843デフォルトの名無しさん2009/10/06(火) 22:04:16
>>839
GPUの場合、メインになる大規模配列へのアクセスなんかだとアドレス計算なんかは
コードで明示しなくてもハードで自動でやるんでなかったっけ？
0844デフォルトの名無しさん2009/10/06(火) 22:05:11
俺821だけどさ、RISCなんか微塵も擁護してないわけよ。

PPC含めていろんなアーキを触るのは楽しいけれど、
x86が現実的に俺が金を出せる中では最強だと思っているわけよ。

でもRISCとかCISCじゃないでしょ？と言いたかったんだ。
現にAVXではデコーダが軽くなるように変更してるでしょ？
今までの実装に負けを認めてるわけよ。

でもそれはRISCに負けたわけじゃないし、CISCが勝っているわけでもない。
Intelは今まで割と酷いアーキだったと思うんだけど……分かんないかなあ。
0845デフォルトの名無しさん2009/10/06(火) 22:14:32
捨ててまた拾うなんてこの世界じゃ常識なのに
負けを認めただの何だの
典型的なIntelアンチですね
0846デフォルトの名無しさん2009/10/06(火) 22:33:49
11月25日GT300発売決定しました
0847デフォルトの名無しさん2009/10/06(火) 22:37:38
>>843
ソースレベルと機械語レベルを混同してる
0848,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/06(火) 22:57:22
>>844
なにが勝って何が負けたの？

x87もMMXもSSEも潰さずに新たなSIMD命令を追加出来るのはまさに可変フォーマットたるCISCのメリットだろ
命令長の縛りで好きにOperand空間を拡張したりできないのがRISCだよ。

360のCPUなんか、SIMDレジスタを128本に拡張した分、4オペランド命令や1バイト単位の操作命令が
削られてたりする。

それから君はAVXを根本的に理解していない。
0849,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/06(火) 23:40:41
まあ俺に言わせればABCDの4レジスタの時代から1バイト、もう1バイトと継ぎ接ぎしていった
伝統的CISCアーキテクチャの新たな1ページですよAVXにしてもLRBniにしても
可変アドレッシングモードがある限りx86はどこまでもCISCだ。
add eax, ecxみたいな1バイト命令がたとえば4バイト固定に変わりますか？なりません。

0850,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/06(火) 23:58:37
>>841
どっかのプログラムをテキトーに逆アセンブラかけてみろ。アホみたいに使われてる。
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
結局、CISCの利点のおかげで儲かったおかげで、プロセスルールに投資できて、
それがIntelの優位性をより伸ばした。そんな説がありえるのか？
0852デフォルトの名無しさん2009/10/07(水) 00:18:50
>>851
Fab商法がうまくいったからだろ
アーキテクチャ云々より
Fab1個丸ごと単一商品の生産工場っていう
資金回収能力が凶悪過ぎる方法実現できているだけ

0853,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 00:21:52
コード資産の継承って点で可変フォーマットであることに助けられてきたのは確かだね。
ステート切替によって複数の命令セットのフォーマットを混在できるARMはCISCに分類する学者さんもいるし

ハイエンドRISCが死に絶えるなか公共事業で生きながらえてるIBMのPOWERですら
BCDアクセラレーションや8バイト命令モードなど既にRISCのポリシーから逸脱してる
0854デフォルトの名無しさん2009/10/07(水) 00:33:05
強い者が勝つのではない、勝った者が強いのだ
0855デフォルトの名無しさん2009/10/07(水) 00:55:59
なるほど、勝ったものが強いか・・ん？
0856,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 00:56:30
ARMがSHやMIPSを凌ぐほどになったのは2バイト形式のThumb命令入れた当たりからだよ

それはそうとNVIDIAの経営相当厳しそうだな
0857デフォルトの名無しさん2009/10/07(水) 01:17:00
ジレンマがあるよね
現状はNVIDIAしかないし、将来はNVIDIAきつそうだと言っても
AMDに乗り換えてもすぐIntelの天下になる可能性もあるし
かといって、今Intelは製品がないから乗り換えようがない
0858デフォルトの名無しさん2009/10/07(水) 01:42:00
そう言えば、昔Itaniumなんてのもあったね
LarrabeeもItaniumの匂いがするなw
0859,,・´∀｀・,,）っ-○○○2009/10/07(水) 01:44:20
俺に言わせればFermiのほうがItaniumっぽいけどな
0860デフォルトの名無しさん2009/10/07(水) 03:02:03
面白いのはItaniumを倒したのはXeonなんだよなｗ
勝ったXeon軍の首領もEMCに行っちゃったし
0861デフォルトの名無しさん2009/10/07(水) 03:04:05
というかそもそもItaniumは失敗したと言うより
Itaniumが狙った市場が消滅した。ってのが正しいんだが・・・
そもそもx86サーバーとかの市場は、元々Xeonの管轄だったわけで・・・
x86サーバーの市場が、そのままかつてSparkやPPCやAlphaがあった市場を喰った。
それだけのこと。
0862デフォルトの名無しさん2009/10/07(水) 03:07:56
なるほどNVIDIAは自爆街道まっしぐらと
0863デフォルトの名無しさん2009/10/07(水) 03:18:06
ま、AMDは最初から蚊帳の外だがｗ
0864,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 03:18:52
>>860
Xeon以前にNehalemが出るまでIntel史上最大の脅威と言わしめたOpteronが遠因だろ
あれの存在があったからこそ、苦戦を強いられながらもXeonを64ビット対応せざるを得なかった。

IA-64 vs x86-64(AMD64)で雑誌の特集組まれてたくらいだし


x86の有用性を自社以外が示してしまったのは皮肉だよな。

毒を食らわば皿までとはよくいったもので、OpteronはIntelの何かに火を付けてしまったようだ
全プロセッサ市場x86化計画の始まりだよ。


XScale捨ててAtom、結果大成功。
GPUもこのノリでx86化したいらしい。


0865デフォルトの名無しさん2009/10/07(水) 04:05:27
Larrabeeがx86なのは統合を成功させるための手段であって目的ではない
0866デフォルトの名無しさん2009/10/07(水) 05:20:18
>>864
話うまっ
0867デフォルトの名無しさん2009/10/07(水) 06:01:32
demo x86布教運動してたゲルシンガーが居なくなっちゃったね
0868デフォルトの名無しさん2009/10/07(水) 07:14:34
最近のオレゴンチームがアレだったからなぁ。
不要論でちゃって、組織統合と同時に退職させられたのかな。
0869デフォルトの名無しさん2009/10/07(水) 08:05:40
え？Nehalem-EPで絶好調だったよ
企業のIT予算減ってるとか言われてたのにモバイルよりサーバーのが回復してた
まあクビって感じじゃないよな
0870,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 08:16:52
破格の条件で抜擢されたっていわれてるけど
0871デフォルトの名無しさん2009/10/07(水) 08:23:11
AtomってPen4より遅いんでしょ？
0872デフォルトの名無しさん2009/10/07(水) 12:55:29
トランジスタ規模相応の性能。
てか性能よかったら棲み分けにならない。
0873デフォルトの名無しさん2009/10/07(水) 19:25:09
fumeFX??提携？買収？
ttp://www.4gamer.net/games/099/G009929/20091001065/SS/009.jpg
0874デフォルトの名無しさん2009/10/07(水) 20:59:23
プログラム板のこのスレに何人のプログラマーがいるのか疑問だ
言ってることがITmedia並みで笑える
0875デフォルトの名無しさん2009/10/07(水) 21:13:55
単純な疑問なんだがATIの場合分岐粒度って64 "pixel"で
nvidiaの場合って32個の"32bitデータ"？(8pixel相当?)
0876デフォルトの名無しさん2009/10/07(水) 21:33:11
Intelは16wideで1cycle : 32bitの16個
nvidiaは8spで4cycle or 32spで1cycle : 32bitの32個
ATIは16shader(16*5=80sp)で4cycle : 64pixel(32bitの256・・・)
0877デフォルトの名無しさん2009/10/07(水) 21:45:51
526 名前：Socket774[sage] 投稿日：2009/10/07(水) 14:11:06 ID:jGgZ/LK7
>>496の大雑把な内容
Nvidia kills GTX285, GTX275, GTX260, abandons the mid and high end market
Full on retreat, can't compete with ATI
ttp://www.semiaccurate.com/2009/10/06/nvidia-kills-gtx285-gtx275-gtx260-abandons-mid-and-high-end-market/


285は既にEOL、260は11or12月にEOL、275は2週間以内にEOL、295も終わりそう。
ハイエンド、ミドルレンジから脱落する。
Fermiの派生モデルはテープアウトすらしていないので、少なくとも2Qは掛かる。
Fermiはダイサイズあたりの性能が低く派生モデルを作ってもフルラインナップで価格競争力で劣る。
ハンダの欠陥問題、G212の失敗、G214の大失敗、G215の遅延、G216とG218の壊れたGDDR5コントローラ。
救世主となるチップはない、プランBはない、全て失敗した。
赤字販売を続けるか、撤退して少ない赤字を出すかしかない。
資金が尽きる前に開発の問題を修正し競争力のある製品を出せるかが問題。
1月にはローエンドからも脱落する。
Nvidiaは全てのパートナーから憎まれており助けてくれるパートナーはいない。
Nvidiaに必要なのは経営陣の総入れ替えだが、その出て行くべき奴らは株主なので起こりそうもない。
ゲームオーバー。
ジェンセンは年俸1ドルでも貰い過ぎである。
0878デフォルトの名無しさん2009/10/07(水) 21:52:52
Intelは16wideで1cycle : 4pixel
nvidiaは8spで4cycle or 32spで1cycle : 8pixel
ATIは16shader(16*5=80sp)で4cycle : 64pixel
0879デフォルトの名無しさん2009/10/07(水) 21:53:03
http://www.z-z-z.jp/BLOG/log/eid450.html

NVIDIAのFERMIコアベースの製品が出てくるのは早くて今から三ヶ月後、
高確率で半年後といわれています(半導体業界関係者の意見)
NVIDIAとしては、今回の発表は、株価対策、あるいはユーザーへの
サービスを兼ねての「やってます」アピールだったといえます。
0880,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 21:54:23
>>878
はぁ？
0881,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 22:04:23
α値があろうがなかろうが5Way ALUで1ピクセルずつしか割り当てられないのがRadeon
R, G, Bで別のベクトルに再パッキングして並列処理できるのがLarrabeeとGT

たとえばLarrabeeはRGBなら 16/3 pixelな
0882デフォルトの名無しさん2009/10/07(水) 22:38:00
>>881
> α値があろうがなかろうが5Way ALUで1ピクセルずつしか割り当てられないのがRadeon
4ピクセル割り当てられますが？
0883,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 22:42:40
グレースケール乙
0884,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 22:44:25
4サイクルで4ピクセルとか言うなよ
0885デフォルトの名無しさん2009/10/07(水) 22:47:38
>>881
アルファを出力しないでどうやってブレンディングするんだよ。
ブレンディングが行われるのはプログラマブルシェーダの後段だぞ。
Larrabee : 4pixelであってる。
あとグレースケールってのはFetch4というかGatherのことを言ってるんだろうが、
あれは読み込みであって出力が4つ同時に出来る訳じゃないぞ。
グラフィックス用途の場合大抵シャドウマッピングでソフトシャドウやるときに都合がいいってだけの機能だ。

>>882
どうやって？MRTとか冗談言い出すんじゃないだろうな？
0886,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 23:30:27
だから分岐粒度の話だろ。
RGBだろうがRGBAだろうがSoAに変換して処理するんだから16並列だ
0887,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/07(水) 23:39:43
まさか RGBA RGBA RGBA RGBA で4ピクセル処理するとか思ってないよな？
VPUは水平加算もなければ、128ビット単位×4でマスク実行するためのビットマスク生成命令も存在しない。
Larrabee Prototype Libraryを読み直してこい
0888デフォルトの名無しさん2009/10/08(木) 00:10:50
>>887
失礼。粒度に関してはこちらの勘違いだった。
ただGeForceはチャンネル毎にスレッド立ててるってソースが見つからなかったんだけど何か知らないか？
0889デフォルトの名無しさん2009/10/08(木) 00:14:27
>>850
なんか即値最強みたいに言ってるが、浮動小数点数のロードも命令に埋め込むつもりか？
0890,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/08(木) 00:27:14
おいおいトンデモ意見が出たな
ロードアドレス算出用のディスプレースメントって「即値」以外のなんなの？
リニアなメモリ空間アドレッシングするのに4バイトくらいないと実質的に使い物にならん。
変量がそんなに必要ないときは1バイトdispモード、そのものが必要ないならdispなしモードでいいし



あーSSE4には汎用整数レジスタにXMMレジスタの浮動小数値を転送する命令（あるいはその逆）が
あったりするけどあれって何のためにあるかわかるよね？
まあLarrabeeとは話がそれるが。
0891,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/08(木) 00:31:42
ロードユニットが忙しいときにしたいときに、単精度の定数を汎用レジスタ上に即値モードで転送して
movdとかinsertpsで挿入とかよくやるテクニックじゃん
0892,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/08(木) 00:32:23
ロードユニットが忙しいときにロード命令節約したいときに、ね
0893デフォルトの名無しさん2009/10/08(木) 00:34:22
せめて小分けにして書くな
0894デフォルトの名無しさん2009/10/08(木) 00:43:03
団子が忙しいときに推敲命令節約したいときに、ね
0895,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/08(木) 00:44:41
俺は頭で考えてレスなどしない
0896デフォルトの名無しさん2009/10/08(木) 00:45:59
餓鬼ですね。
0897,,・´∀｀・,,）っ-○○○2009/10/08(木) 00:48:35
無我の境地というのだよ
0898デフォルトの名無しさん2009/10/08(木) 00:56:25
僕らのアイドル ダンゴリオン
0899デフォルトの名無しさん2009/10/08(木) 06:01:02
atiの分岐粒度がデカ過ぎるのは判った
0900デフォルトの名無しさん2009/10/08(木) 07:39:45
で、Larrabeeはいつ出るのかね？
0901デフォルトの名無しさん2009/10/08(木) 09:16:44
5年後くらいにCellの6割くらいの性能で。
0902,,・´∀｀・,,）っ-○○○ ◆??? 2009/10/08(木) 09:21:05
Sandy Bridgeの4コアが200GFLOPSオーバーだから意味ねーよ。

Haswell世代だとやはりCPU4コアだけで300〜400GFLOPS
0903デフォルトの名無しさん2009/10/08(木) 09:32:24
コンシューマで画処理以外の何に使うのかなぁ？
0904デフォルトの名無しさん2009/10/08(木) 09:45:15
粒度的にはレイトレ向き
0905デフォルトの名無しさん2009/10/08(木) 10:07:42
レイトレのデモができる段階なんだから一年以内には出るだろ
その点GT300なんてハリボテ模型だからな。
量産できないアーキなんてペーパーアーキもいいところだ。
0906デフォルトの名無しさん2009/10/08(木) 10:15:19
レイトレも画処理だろう。。
0907デフォルトの名無しさん2009/10/08(木) 10:18:33
>>900
ハリボテ展示する会社の製品よりは早いだろうなｗｗｗ
0908デフォルトの名無しさん2009/10/08(木) 13:42:09
http://www.4gamer.net/games/098/G009883/20091007054/
Larrabeeは計画破棄が濃厚だね。

Larrabee計画の顔役ともいえるPatrick P. Gelsinger（パット・ゲルシンガー）上級副社長が，
IDF 2009の直前にIntelを退職するという“事件”もあったが，
業界内にはLarrabeeについて，後ろ向きな情報が飛び交っている。
「IntelがLarrabee計画を中止する」といったものまで含まれていたほど。
「Gelsinger氏とともに，主要エンジニアもIntelを去った」という情報もある。
0909デフォルトの名無しさん2009/10/08(木) 14:26:31
>>833
たとえばここの
http://www.ddj.com/architect/217200602?pgno=5

vcmpgtpi k2, v3, [rsi+Edge1TrivialRejectCornerValues4x4+rcx*4]{1to16}
っていう命令は何やってるかっていうと
(1) ベースポインタ(rsi)にメンバのオフセット定数(Edge1TrivialRejectCornerValues4x4)
　　を加算、さらにインデックス値(rcx)を４倍して加算
(2) 得られたアドレスに対して32ビット値にロード
(3) さらにその値をSIMDテンポラルレジスタの16要素にブロードキャスト
(4) その値と、ベクトルレジスタ(v3)の各要素のほうが大きいかどうかを比較し、
それぞれの要素の真偽値をマスクレジスタ(k2)に格納

こんな複雑な操作をLarrabeeでは1命令でしかもパイプラインで1サイクルのスループットで実行できる。
AGU -> LDU -> PERM -> VPU のパイプライン実行だ。
同じような操作を疑似RISC ISAで書くと6命令とかかかるわけ。
shl $offset, $idx, 2
addi $offset, $offset, Edge1TrivialRejectCornerValues4x4
lqa $vtemp, $addr, $offset
rotqby $vtemp, $vtemp, $addr
shufb $vtemp, $vtemp, $vtemp, $ptn
cmpgti $k2, $v3, $vtemp

SPUの命令セットに似てる？気のせい気のせい。
同じ操作を1サイクルのスループットでこなすには6命令同時発行できないといけない。
6命令なんて、POWER6+ですらやってない。
デコーダから実行ユニットまで少ないトランジスタ数で実装できるRISCは
トランジスタリソースの限られた組み込み向けとしては今でも有効だが
数千万〜数億トランジスタが当たり前となった今となっては
パフォーマンスを追及する向きじゃない。Cellもぶっちゃけ効率悪いし。
0910デフォルトの名無しさん2009/10/08(木) 16:52:48
>>908
Larrabee楽しみにしてたのに。GPUとして売ろうとしたのは時期尚早だったのかな。
0911デフォルトの名無しさん2009/10/08(木) 17:51:21
自演つまらん
0912デフォルトの名無しさん2009/10/08(木) 18:42:57
団子は言っていること無茶苦茶だな。
NVのATIに対する利点は再パックしなくても
効率があまり落ちないところにあるのに。

ATIの場合スカラ演算で少ない命令の場合に
1つ分ではALUの無駄が多すぎるが、
命令が多い、スカラを4つパックして入力するなど工夫をする事で
処理命令数を増やせば、5とはいわずとも平均3-4命令は埋まる。
ここまで出来れば素の演算性能で上回る事例も多い。

まあ、レジスタのxyzwをいい感じで指定して、
バンクコンフリクトを排除する必要もあるから
かなり面倒ではある。

ILの仕様が糞で、どのバンクを使うかを明示しなきゃならんから
コンパイラが最適化する余地が無いしね。
0913デフォルトの名無しさん2009/10/08(木) 18:53:38
で、ここまでしたうえなら、扱う粒度が大きくなるから
データ毎に処理が分かれるような対象では
効率が下がりますねという話になる。
ただ、この辺は演算規模が大きい場合には殆ど問題にならない。
CPUで出来る程度の演算負荷の少ない処理を
GPUで代替しようとするときにはかなり大きな問題になる。
0914デフォルトの名無しさん2009/10/08(木) 19:47:57
>>912
高級言語レベルの話とネイティブマシン語レベルの話を混同するなよ
CUDAはgather/scatterをラップしてるだけにすぎない。
32WayのSIMT(SIMD)でX, Y, Zをどれでも等しく操作するってのは
要するにロード・ストアの度にAoS/SoAの変換をやってるから。

Larrabee C++ APIはラップせずにSIMDをSIMDとして直接見せてるだけ。
ピクセル毎のプレディケートさえ必要なければ文字通り再パックしないまま
つまりRGBA RGBA RGBA RGBAの構造のまま効率的に処理する方法も
提供されてる。32ビット4要素毎にSwizzleする命令もあるし。
OpenCL経由の場合はGatherがデフォだろうが。
0915デフォルトの名無しさん2009/10/08(木) 19:55:32
>>912
> 処理命令数を増やせば、5とはいわずとも平均3-4命令は埋まる。
固定機能再現するだけでも2-3な訳だが。
> ILの仕様が糞で、どのバンクを使うかを明示しなきゃならんから
ATI ILでどれだけxだのyだの指定してもISAにしたときは無視されるぞ。
0916デフォルトの名無しさん2009/10/08(木) 19:59:11
C/C++からネイティブコード触れるのはLarrabeeの特権だな


0917デフォルトの名無しさん2009/10/08(木) 20:01:14
ｐｐｐ
0918デフォルトの名無しさん2009/10/08(木) 20:25:05
＞固定機能再現するだけでも2-3な訳だが。

固定機能のエミュに終始するならDX9使ったらって話
それでも2/5-3/5、64pixel中何pixelに適応になって、shaderが何個空転するのか
0919デフォルトの名無しさん2009/10/08(木) 20:45:30
>>918
それがどうしたの？DX9使っても結局ドライバのなかで同じシェーダが生成されるんだぞ。
効率低いことに変わりはない。
0920デフォルトの名無しさん2009/10/08(木) 21:03:38
?
DX10以降でDX9以前の固定機能相当の処理はshaderでの置き換えが必須だが
de9でDX9以前の固定機能使うんならshader自体使う必要がないわけだが
レス数が900を超えています。1000を超えると表示できなくなるよ。