PS3のCellってもともとGPUの処理もまかなう予定だったそうだけど、
具体的にどんなレンダリング方法を試みようとしてたのか、ハッキリ言ってこれは向いてるってものがない。
MSの人も指摘するとおり計画が破綻してNVIDIAに頼ったというのが事実。
リングバスはもともとソフト的にグラフィックパイプラインをやる上では重要な位置づけで
たとえばレイトレーシングなら6つのプロセッサをリングバスで接続すればバケツリレーで
処理ができる。
でも実際にやろうとしてみると逆にLSがボトルネックになる。
たとえばレイトレだと、共有メモリが絶対的に優れてると絶対的なことはいえないのだが、
独立メモリであるLSは、Larrabeeみたいな共有キャッシュよりあまり効率が良くない。
他のSPE上のLSの○○番目のデータをとってくるにしてもいちいちDMAコマンドを発行して
ブロック単位でまとめて転送してくるしかない。
結果としてはデータを重複して持つことになってしまう。
その上128KB〜1MBというアーキテクチャ上の制限もあるから拡張の余地があまりない。
レイトレーシングパイプラインのキャッシュメモリは共有分散型でトータル数MBが一番妥当なんだよね
Larrabeeはx86アーキテクチャの延長でCellのやろうとしてできなかったことを試みてるんだよね。
更に言うと、SPUの命令Opcode空間は最初の実装の次点で9割以上使ってしまってる。
SPEはまっさらからコード体系を再設計するとかしない限り、たとえば256ビットとか512ビットとかの
SIMDには対応できない。
んで、コアを増やすくらいしか根本的にスループットを引き上げる方法がない。
いまだに数千〜数万命令の拡張の余地がある命令セットってx86くらいしかない。
,__
http://japanese.engadget.com/images/2006/06/kutaragi.jpg r勹ー−、 \
/シ_ -__ ヽハ , -――――-、_ 在りし日のクタ
{ソ_,= 、 ´` }_」! / //_;'┐
{j ゝ - ,ヽ ィ } / __ __ __ //r_‐、〉'
{ 〈 '  ̄ _ rノ / /┘_〈 _‐/ //r'‐、/ 今ほど落ちぶれるとは夢にも
ヽ r、´ リ / / ̄7、 }
___ __>-- 、 }ヘ ___/ / / /
/´ \ \ \八/\}\ / / /} 〈
| \ \ \ \〉l / / /タュュ」\
| \ \ | |} | く ̄ ̄/⌒二二)../}/ `ー―〉
| ヽ ヽ}__j_ >'チ  ̄`ー' / /
| , イ´ ̄ ̄ ̄ |_____./ /
\ ∨ | / /
}\ / l / /
| \_______ cccc/ |\' /
. / C/ i ̄ l ヽ.___/
>>654 -------------------
SPEはまっさらからコード体系を再設計するとかしない限り、たとえば256ビットとか
512ビットとかの SIMDには対応できない。
-------------------
レジスタ数を減らした拡張命令セットが定義可能なことは確認済みです。
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/74 ====================
現ISAとの互換性を保ちつつ、専用命令で『大幅な性能向上』を得るための最も単純な解決策わ
ベクトルレジスタを連結して128個の128-bit幅VRFを256-bit幅 x 64又わ512-bit幅 x 32として
扱うことす。
====================
命令エンコードの詳細については、当該投稿をどうぞ。
Opcodeにあといくつ空きがあるか調べてみればわかることだ
どっちにしろ既存命令潰さないと無理だけどねwww
馬鹿だからわかんないだろうけど
>>657 ----------------
馬鹿だからわかんないだろうけど
----------------
数が数えられない自分をそんなに卑下しなても良いですよ(笑)
4レジスタ命令と2レジスタ+ハーフワード即値命令で殆ど食いつぶしてるんですが。
>>660 いつものように知ったか振りが止まらないようですが、
------------------
4レジスタ命令と2レジスタ+ハーフワード即値命令で殆ど食いつぶしてるんですが。
------------------
>>659の感想はいかがですか(笑)
倍精度積和やキャリー/ボロー処理が第一ソースオペランドを破壊してるんですが
それをOpcodeに余裕があるって言うんですか?
x86ってアドレッシングモードの即値・スケール値込みだと最大7オペランドくらいになる。
当たり前のように使えるModRM+SIB+DISPによるアドレッシングモードだが
実は性能を引き上げる上で大きく寄与していた。
Cellの命令セット触ってみて、なぜRISCの時代が終わったのか分かったよ
>>662 -------------------
倍精度積和やキャリー/ボロー処理が第一ソースオペランドを破壊してるんですが
それをOpcodeに余裕があるって言うんですか?
-------------------
それは命令仕様の問題で、op-codeの余裕とどういった関係があるのでしょうか(笑)
もうMACオタはNGするとか言ってなかったっけ?
命令セットマニュアルよく見たら16ビット即値とるオペレーションってソース破壊型か。
道理でoriによるコピーが増えるわけだ。クソ過ぎる。
優位に導く余裕が無いだけでも万死に値する。
団子は決して自分の間違いを認めない
667 :
Socket774:2009/02/11(水) 16:01:27 ID:6DH38jjR
似たようなもんだろ
>>666 俺は4オペランドにすべき命令がソース破壊になってると言う観点から余裕が無いと言ってるわけだが。
256bit×64本でも512bit×32本みたいなけちな拡張方法自体発想に無いし思いつくのを賢いとも思わない。
レジスタ本数やオペランド数に制限を入れないと拡張できないのを余裕とは言わない。
x86の論理レジスタは汎用レジスタ16本+SIMD16本+αだが、Larrabeeではそれが4スレッド
物理的には1コアあたりSIMDレジスタは64本(テンポラルを入れるとそれ以上)備えてることになる
VEXエンコーディングはレジスタ間オペレーションだけでも5レジスタオペランドまで対応できるフォーマットだ。
たとえばSIMDレジスタの本数を32本や64本なんて拡張だってOpcode空間の余裕的には可能だ
>>668 ----------------
俺は4オペランドにすべき命令がソース破壊になってると言う観点から余裕が無いと
言ってるわけだが。
----------------
『ぼくの考えたスゴい命令セット』の話はご自身のホームページでどうぞ(笑)
拡張以前に最初からSPE ISAで倍精度積和演算等は結果を上書きする3引数命令です。
この結果レジスタ指定に必要な命令フィールドわ、以下のように減少するす。
4引数: 28-bit -> 24-bit (256-bit幅), 20-bit (512-bit幅)
3引数: 21-bit -> 18-bit (256-bit幅), 15-bit (512-bit幅)
そして4-引数命令を8-bitフォーマット(256-bit幅の場合)又わ11-bitフォーマット(512-bit幅の場合)
に割り当てることが可能になるす。
>>73に書いた通り、8-bit Op-codeも4引数命令を割り当てる程度にわ空いているすから、
このやりかたわ、論理的にわ可能ということす。
的中するかどうかわ、数年後ということで。。。
↑ぼくの考えたすごい命令セット(笑)
変位ゼロ指定でバイトシフト命令(Oddパイプ側)を使えばEvenパイプ使わずに別のレジスタに値退避できるので
倍精度拡張版Cellが実効性能半分ってわけでもない。
もっともこの程度の最適化は、Oddパイプ側に空きがあればコンパイラが自分で行うけど。
LINPACKがハッタリ以外のなんでもないことだけはわかった。
そもそも論理レジスタ本数がそれほど多くない命令セットでは同じ論理レジスタを繰り返し
再利用する頻度が高いので、4オペランドにすることでのメリットも決して大きくは無い。
レジスタ128本の命令セットでそれをやるのは、どうかと思うけど(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)
そして誰も見向きもしなくなったころにSSEのまねごとをするVSX(笑)
破壊する加算値か乗算値のどっちのレジスタを破壊するか選べる時点でAMDのSSE5もIntelのFMAも
SPU(笑)よりだいぶマシな仕様だ。
破壊しない2つのオペランドのうちどちらかをメモリアドレッシングするかを指定できることができる
(μOPsドメイン数の削減)というわけでx86ならではの利点は充分ある。
>>674 -----------------
(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)
-----------------
精神的に追い詰められてきたっぽいので、これ以上追求するのはヤメておきましょう…