OSってインオーダーでもアウトオブオーダー効率性関係なし？
それともあるの？

>>499
>ATIとNVIDIAはアーキテクチャがまったく別物だけど、DirectXが違いを吸収してくれてるように
>Larrabeeも透過的に扱われるだろうよ。

その透過的ってやつをインテルが本気でやる気があるのかってこと。
透過的である以上LarrabeeもレイトレじゃなくてZバッファを前提にした従来型の
GPUとして動作する必要があるけどレイトレのアピールばかりしてるのを見てると
インテルとしてはそれはやりたくないんじゃないのと思えるんだよ。
まぁ、もう三度目だし通じそうにないね。

>>500
AMDも将来のことは見据えてるよ。

AMDとしてはFusionが最適解になるかもしれない。
GPUからアクセスできる高速なメモリが確保できるからね。
CPUのキャッシュメモリを一部だけでもGPUに開放すれば、簡易的ではあるが
それほどレイテンシの大きくないレイトレースキャッシュになりうる。

AMDは、Fusionは将来的にはx86のコードシーケンスからGPUにアクセスできるできるようにする
といっている。そのためには、よりワイドなSIMD命令をサポートする必要がある。
後手に回る限りはIntelとの互換性もある程度確保しなければならない。
それって出来上がるものは結局、「AMD版Larrabee」なんじゃないの？

一番つぶしがきかないのが自前のx86アーキを持たないNVIDIAだ。

>>507
インテルは今でもオンボを作ってるしあるしそりゃある程度は動く物を
作れるだろうよ。でも、その動作は信頼されてなくてサポート対象から
外されたり、動かしたかったらグラボを買え、と言われる。
そんな現状を変える気があるの？ってことなんだけどなぁ。

＞でも、その動作は信頼されてなくてサポート対象から
＞外されたり、動かしたかったらグラボを買え、と言われる。

それ機能じゃなくて性能不足の問題じゃないの？
メモリ共有だからフレーム脱落したり帯域とりあったりするんだよ。

安定性に関してなら、バグだらけのベータ版ドライバを好き好んで試す人が多いのは
GeForceエンスージアニストの不思議な性質

要はWPFのC++版じゃねーのかと思ったけどあらかた当たってるらしいな

規模が違うとどうして問題ないんだ？

>>499
デコーダの負担は減るけど、メモリアクセス効率は悪化しないか?
その点だけならメモリバスに合わせたバイト長のVLIWにしといて、きっちりプリフェッチ分送れるAMDの方が
電力効率は上がる気がするけど

Larrabeeの死角はメモリバンド幅じゃないのかな。メモリインターフェイスは
まだ詳細不明だがIntelは大バンド幅を与える気は全然なさげ。
アプリのバンド幅需要次第ではLarabee大成功ってなるのかもしれないが

SIMD特化型CPUでメモリへの要求が少ないってマトモに使われてないって事じゃ？

ゲームのトレンドが局所性でどうにかなるアプリに向かうかどうかって話になるんだろうか
HPCはどうしても帯域欲しいですって話が出てきそうだけどその辺は棲み分けるのかな

>>519
あのさ、x86だからWordやExcelが実用的な性能で動かないといけないとか勘違いしてない？

まあ、そこそこ実用的な性能で動く必要があるとして、Atomといういい例があるじゃん。
x86からアウトオブオーダを取っ払い、2issueに命令帯域を削ぎ落とし、その代わりにHTをサポート。
SSEは倍精度を除いてPentium Mをしのぐほどの性能を誇りながら、トランジスタ数は劇的に減ってるんだ。

それよりさらにワイドなSIMDユニットを搭載し、代わりにx86スカラ性能をさらに諦めるという
極端なことをやるのがLarrabeeだ。
Larrabeeのx86エンジンはAtomより更にシンプルになることが知られている。
具体的にはPentiumのときのU/Vデコーダに近いような制約が復活する。

Atomはまだ主役はSSEじゃなくてスカラ命令だから、そこそこ性能が悪くならない程度には
トランジスタを割いてる。LarrabeeはSIMDが主役で従来x86命令（スカラ）は脇役になる。

実用上、添字やビットマスク、アドレス計算、分岐なんかを担当する程度の使い方しか要求されない。
別にWebブラウズしたりメールしたり表計算したりするわけじゃないんだから、利用頻度の低い
命令なんかは遅くてもかまわないわけで、そういうのはマイクロコードで提供したっていい。
基本的に滅多に使わないんだからさ。

>>520
メモリ周りってGPUにおいて最も電気食らいな場所のひとつジャン。
パラダイムシフトが完了すれば、今ほどのメモリ帯域は必要なくなるよ。
ディスクリートGPU自体不要になる。

CPUベースのレイトレーシングの課題は充分なコア数が確保できてないこと。
そこでレイトレーシングに特化した「メニーコアCPU」を先行投入する必要がある。
LarrabeeはディスクリートGPUからメニーコアCPUへの橋渡し以上の意味は無い。

過渡期の実装である以上は従来GPUと同程度の機能は提供しないといけないわけで
必然的にメモリ帯域は確保してくることになるでしょ。
すでにGDDR5ってうわさが出てるけど。

http://isdlibrary.intel-dispatch.com/vc/2224/VA2_QuakeWars_NOcovers_final.pdf
http://www.youtube.com/v/mtHDSG2wNho

うんこすぎる

やっぱ細かいところはテクスチャの素材次第だな。
世代遅れのゲームでも水や金属のような反射物の表現はレイトレーシングに置き換えるだけで
圧倒的にリアルになるがくすんだオブジェクトはテクスチャの地が出て違和感が生じる。

テクスチャに影を焼きこんだりとかアホな工程が減るだけでも、開発工数・表現力ともにメリットはある

>メモリ周りってGPUにおいて最も電気食らいな場所のひとつジャン。
>パラダイムシフトが完了すれば、今ほどのメモリ帯域は必要なくなるよ。

こんなの初耳だけどどなたかソース出せますかね。レイトレで必要な帯域は
増えることはあっても減ることはないと思うんだけど。

狭いメモリ帯域でも演算機は必要、となるためには、演算量>帯域、
そうなるケースは”遠く”へ送受しないローカルなデータを
何度も処理するケース。

当然のことながらそういう処理へ帰結できる課題もあるけど、
できない課題もいっぱいある。できない課題が減る見込みだというなら
根拠はなんだろうな

>>533
嫁というならURLを出してくれ

>>536
これは別に現存のGPUと比較したわけでもないのに、なんでこれから
必要バンド幅が減るなんて結論が出るんだ？
むしろ、オブジェクトの検索だけで節約しなければならないほど莫大な
帯域が必要なように思えるが。

キャッシュの増量の活用により演算ユニットあたりの必要メモリ帯域は既存のGPUより減る。
あくまで相対的なものだ。

>>526
無料だよ

>>539
いや、今のGPUにもキャッシュはあるし・・・なんかそこから話がおかしいかと

知ってるよ、ダイ全体で数十～数百KBだろ？
全然足りねーよ。

>>542
つまり、容量が小さいからないも同然だと言いたいのか
なんとなく言いたいことはわかったけど、そういう用途なら
CPUでいいんじゃね？って気がするけどなぁ

ループしてるぞ

キャッシュ容量が性能に与える影響は俺が引用したグラフを見ればわかるだろ。

わからんならもうええわ

>>543
CPUでいいからこそ、x86ベースで後腐れ無くCPUに統合できるLarrabeeなんだよ。

>>523
言いたかったのは複雑でボトルネックになりやすいx86デコーダを、
スループット重視のマルチコアCPUにn個分載せたら無駄にならない?って意味だったんだけど
ハードワイヤーじゃなくてマイクロコードにしとけば良い話ではあるね

それはそうとLarrabeeの内部設計って、CPUとの連携には向いてないんじゃ?
n個のコアのキャッシュコヒーレンシは高速な内部バスに留まるうちはいいけど、
CPUと組み合わせたらオフチップでP2Pなバスに載せるわけで、メインCPUの命令とかと同期する時に破綻する気がするんだけど・・・

そんなのしららびー