元スレIntel Larrabee 4コア

Intel覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

601 = 571 :

intelがlarrabee向けに作らせてるモノがあった筈なんだが
それの動画もintelのサイトで見た記憶がある
なんでそれじゃねーんだよって思ったわ
先ず

603 = 571 :

苦労を数えて奇を論ずる遊びに過ぎんって

604 = 560 :

N厨はデバッグ終わってないシリコンで製品版と同等のパフォーマンスが出ると思っているのが痛い

605 = 571 :

淫厨は教祖様がすべて正しいと思っているのが面白い

609 = 571 :

嘘も100度言えばlarrabeeの実物が出てくる！

610 :

ララビは1コアでfermiの4倍のパフォーマンスが出るわけですね
OpenGLのエミュレーションでもati,nvidiaを楽々と抜きさってくれることを期待してます
流石に固定パイプラインでは勝てないでしょうが、これからのOpenGLは固定パイプライン廃止なんで
一層ららびに有利になるんでしょうね

614 :

Fermiやローンチ版Larrabeeが主戦力の時期は
まだレイトレーシングが一般的になる時期じゃない。
一般的になる時期になったらnvは（それまで生きていたらだが）たぶん
がらっと変えてくる。これまでもコロコロ変えてきた

615 :

レイトレーシングが一般的になった時、x86を持たないNVIDIAはPC市場から消える
これは約束された敗北であり確定した未来

616 :

なんかレイトレに夢持ってる人が居るみたいだけど
ラジオシティを伴わない光線追跡したって大してリアルになんねーよ？
モデリングの問題だってあるし。

で、ラジオシティのエネルギー場計算はそれなりにパワー居るけど
計算しちまえばレイトレにも従来法にも適用は可能。

618 :

なんだ、やっぱり落とし穴があるのか。
結局そんなうまい話はないんだな…。

620 :

どのA-Bufferをいってるんか知らんけど、LucasFilm考案のやつなら
既存アルゴリズムの拡張だからそれこそLarrabeeである必要性は低いよ。
むしろピクセルシェーダの拡張だし。

必要な情報量が増えて転送量が上がる分、むしろLarrabeeには不利。

レイトレがLarrabeeに向くのはピクセル処理よりも交差判断の演算処理が
はるかに膨大になるっていう比較の問題であって、リアルな描画求めたら
結局オンラインレンダリングなんて夢物語に終わるし、まぁ微妙なところ。
無理にリアルタイムレンダリングに拘らないほうがいい。

621 :

コア数増やすだけでスケーラビリティが得られるという点で将来性があるのでは？
Stencil Routed～かな。
もちろんNVIDIAも論文書いてるし、そのうち実装を出してくると思ってる。

自社に有利なメソッドを選ぶことでの差別化も大事だが、業界全体がついてこないことには。

624 = 621 :

たとえば既存アーキテクチャでは、ROPから吐き出したピクセルデータを
ピクセルシェーダにダイレクトに渡せばいいものをVRAMに都度吐き出して
またそれをロードしてるわけで。

キャッシュ容量改善によるメモリ帯域消費の削減の余地はかなりある。
GDDR5でそれなりには帯域は確保するようだし多少キャッシュミスしても
トータルで帯域をセーブできれば十分元が取れるのでは。

627 = 621 :

全体的には食うけど局所的には減らせる。

628 :

喰うメモリの量が予測できないのが辛そう。
溢れそうになったら途中で一旦合成して続ける？

631 :

だんごせんせー
小さすぎるキャッシュが結局メモリバンド食うってわかっててゲフォやラデのキャッシュ容量が大きくならないのは何でー？

632 = 621 :

キャッシュはダイサイズ食うからだ。
というか低クロックの演算ユニット大量並列処理する分には焼け石に水。

多少SPの個数減らして高クロックで回転数あげるならキャッシュの意味も出てくる
（クロックが高くなるほど相対的にキャッシュのトランジスタ密度は高くなる）

633 :

コアの”座標”に意味があるような稼動を想定してるみたいだな

ttp://www.tgdaily.com/content/view/44417/135/

634 = 620 :

>>625
酷い勘違いをしているけど、別にZBufferだって最終工程まで並列処理できる。
透過処理を正しく行うには事前にポリンゴンをソートしておく必要がある（これはたいした負荷じゃない)のと、
それでもポリゴンが交差してしまった際に正しくない結果を招くというだけ。
これは何をしても解決しないし、A-BufferもZ-Bufferも並行処理度は変わらない。

A-Bufferはピクセル化と最終書き込みの際に透過処理用を情報をてんこ盛りで付加して
Z深度比較と同時に透過演算まで行う代物。これでポリゴン交差しても問題がなくなる。
つまりZ-Buffer法ではZ情報(ピクセルあたり32bitか64bit)を読み出せばすむだけの話が
A-Buffer法では輪郭マスクや透過度、さらには透過合成するために過去のピクセル情報まで
読み直さないといけない。

膨大なメモリを消費してでも透過描画を正しく行うのが A-Buffer の目的であって、
速度向上への寄与ないよ。

お得意のタイルレンダリングで局所的に扱えばキャッシュに収まる～といつもの台詞が
帰ってきそうだけど、一度に扱えるタイルが激減するのは明らかでその分並列度が下がるね。

Larrabee擁護したいだけの素人が適当なこと言ってると恥かくよｗ

>>628
リアルタイムで処理するにはそういった割り切りが必要になってくるね。
ATIとLarrabeeあたりは区画で切ってきそうだけどNVIDIAはバス幅広げて力で解決してきそうｗ

635 = 620 :

あと、前に指摘したのにまだ理解してないみたいだけど、
通常のZ-Buffer（やA-Buffer)ではポリゴンはそのまま描き捨てればいいけど、
Larrabeeで使うタイルレンダリングでは区画が変わる毎に全てのポリゴンを再評価しないといけない。
過去の評価結果が再利用可能ではあるけど、キャッシュに乗り切らない場合はそれも足を引っ張るね。

キャッシュに頼る結果、性能を維持するにはシーンで扱えるポリゴン数が激減するのもLarrabeeの問題。

レイトレにするとNURBSやMetaBall使ってオブジェクト作れば、膨大な演算量がかかる
代わりにオブジェクトが消費するデータ量を減らすことが出来るので、そのへんも含めて
「相対的に」Larrabee向きっていうハナシ。

636 = 621 :

>>634
> お得意のタイルレンダリングで局所的に扱えばキャッシュに収まる～といつもの台詞が
> 帰ってきそうだけど、一度に扱えるタイルが激減するのは明らかでその分並列度が下がるね。

あのさー、たかだか32コア～64コア動かすのに
ウン千スレッド必要ない設計なんだが。そこらのGPUみたいに。

637 = 621 :

・メモリレイテンシを隠蔽するために大量のスレッドが動く設計になっている
・でも、キャッシュが効かないからVRAMのレイテンシが大きいんだよ。
・同時に動かすスレッドが常に大量にあるからキャッシュなんてききようがない
　（＋ダイサイズの制約もあるから簡単には増やせない）

既存資産の同時に解決するアーキテクチャなんて考えようがないんだよ、GPU屋には。
Larrabeeはスレッド数を多くしないといけない制約がない

言っておくがキャッシュに載っかりきる必要なんてないんだよ、ポリンゴンくん
たとえばトラフィックを半分程度に削減できるなら、2倍のヘッドルームが出来るのと同じことになる
クリーンヒットなんて求められてない。

ポリンゴンくんはキャッシュに頼るとVRAMの帯域が大幅に削られたり、レイテンシが大幅に伸びたり
する妄想に囚われてるようだが、同じGDDR5(or XDR2)を使う限りそれはないだろう。

ポリンゴンくんはさ、ハードの特性を正しく理解した上で
相対的にどうなのかを判断しよう

638 = 621 :

ぶっちゃけると、タイルレンダリングである必要すらない。
キャッシュはプライオリティが高いデータが残るという特性は変わらないからね。

どっちかというとLarrabeeの場合レジスタ間よりもL1キャッシュ間オペレーションのほうが
演算密度を稼げる変なルールがある。

639 = 621 :

並列処理「しないといけない」スレッドも相対的に減る。
並列処理してキャッシュを取り合うくらいなら逐次処理したほうがマシと言うことも時としてある。

GT200ではCUDAでは16ワープ、GPUとしては最大32アクティブワープ動かせるようになっているが、
Larrabeeはコアあたり1～4スレッドだ。むしろ、それ以上のアクティブスレッドは動かない。
大前提として同クラスのGPU程にはスレッド数が動かないし、
平均メモリレイテンシが遙かに小さいので動かす必要もない。

いまのところLarrabeeの方針は、メモリ帯域は減らすのではなく、確保しつつ、キャッシュによって得られる
一桁違いの広帯域と圧倒的な低レイテンシを有効活用することで更なる性能アップを目指すもので
外部帯域もRadeon程度には確保する。ただしGeForceほどには必要ない。
したがって

> 性能を維持するにはシーンで扱えるポリゴン数が激減する

という妄想が成立する道理もない。