私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレIntel Larrabee 4コア
Intel スレッド一覧へ / Intel とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
このスレとかIntel次世代スレとか、木どころか葉脈見て森見ないようなやつばっかだな
>>907
普及させるために仮面かぶってるからさ。
普及させるために仮面かぶってるからさ。
VRAMの帯域消費量を節約するため。
ピクセルライン単位でちびちび転送して処理するからあのデータが足りないとかいって
帯域をひたすら浪費する。
ある程度の大きさずつキャッシュに確保して纏めて処理したほうがトラフィック削減できる。
ああ、PowerVRがどうとか言ってるのはアホなんで構う必要なし。
そんな帯域狭いわけがないだろ。
ピクセルライン単位でちびちび転送して処理するからあのデータが足りないとかいって
帯域をひたすら浪費する。
ある程度の大きさずつキャッシュに確保して纏めて処理したほうがトラフィック削減できる。
ああ、PowerVRがどうとか言ってるのはアホなんで構う必要なし。
そんな帯域狭いわけがないだろ。
VRAM転送だけで何十Wも消費するので、キャッシュを旨く使って消費電力を抑えれば
その分の余剰TDPキャパの枠内でコアをオーバークロックすることができる
なんて実装が登場するかもしれないね。
その分の余剰TDPキャパの枠内でコアをオーバークロックすることができる
なんて実装が登場するかもしれないね。
運が良ければそのままL2キャッシュにそのまま保持。
Cellじゃないんだからバケツリレーする必要なんてないよ。
ストリーム処理の粒度は粗くなり、今までのGPUでは絶え間なくなく流れてた
VRAMのフローは途切れ途切れになる。
いや、それがIntelの目論見なんだけど。
段階的にタイルに移行し、ゆくゆくはCPUコアと統合し、L3キャッシュでバッファリングすることで
より狭い帯域のメモリで動かせるようになったり、CPU間と高速にデータやりとりしたりってことが
できるようになる。
GPUは帯域食いのイメージがあるが、実は意外と食わないってのはあまり知られてない事実。
演算ユニット単位で見るとメモリ帯域はものすごく狭い。
要するにデータの局所性はCPUと比べてものすごく高い。
局所性があるならキャッシュは有効だ。
十分なキャッシュ容量を与えないからこそ無駄にトラフィックが浪費されるわけで。
Cellじゃないんだからバケツリレーする必要なんてないよ。
ストリーム処理の粒度は粗くなり、今までのGPUでは絶え間なくなく流れてた
VRAMのフローは途切れ途切れになる。
いや、それがIntelの目論見なんだけど。
段階的にタイルに移行し、ゆくゆくはCPUコアと統合し、L3キャッシュでバッファリングすることで
より狭い帯域のメモリで動かせるようになったり、CPU間と高速にデータやりとりしたりってことが
できるようになる。
GPUは帯域食いのイメージがあるが、実は意外と食わないってのはあまり知られてない事実。
演算ユニット単位で見るとメモリ帯域はものすごく狭い。
要するにデータの局所性はCPUと比べてものすごく高い。
局所性があるならキャッシュは有効だ。
十分なキャッシュ容量を与えないからこそ無駄にトラフィックが浪費されるわけで。
GPUっていうかリアルタイム3Dグラフィックスは、もっと帯域食わない方法が沢山あるという事だな
ハードワイヤード実装でレンダリングパイプラインが固定され続けて15年が経った、と
俺たち末端のプログラマはそのハードの仕組みに従うしかないからなー
ハードワイヤード実装でレンダリングパイプラインが固定され続けて15年が経った、と
俺たち末端のプログラマはそのハードの仕組みに従うしかないからなー
キャッシュ内タイルレンダで帯域ハッピーなんて
とてもじゃないがLarrabee世代で実現できるような話じゃない。
後プロセス3世代くらい進めば物になるのかもしれんが。
とてもじゃないがLarrabee世代で実現できるような話じゃない。
後プロセス3世代くらい進めば物になるのかもしれんが。
>>916
なんで「賭け」?
あったらあったでトラフィック削れるし、無いなら無いでかまわんのだよ。
キャッシュにないなら、メモリからとってくればいいじゃない。
そこは従来のGPUと変わらん。
ロードして必要データがキャッシュにある別の部位を処理するタスクに切り替えて間を繋ぐ。
そこも従来のGPUとかわらんし、むしろ条件は良い。
だが大丈夫、その程度で望み薄いとか言ったら、10分の1以下のL2キャッシュ容量しかないGeForceやRadeonは
「絶望的にありえない」から。
なぜ運任せになるかって、OSが入るから。カーネルタイムで処理が遮られるし、場合によってキャッシュが流される。
しかし全部のコアでカーネルが動くわけじゃない。
そこを避けさえすれば、明示的にコントロールすることすら可能だ。
あとFermiも含めテッセレータはソフト実装だから安心しろ。
FermiではCUDAで実装するんじゃね?
ソフト実装ではHull Shaderステージと内部処理レベルで統合してしまってもかまわんのだよ。
むしろそっちのほうが好都合だろう。
なんで「賭け」?
あったらあったでトラフィック削れるし、無いなら無いでかまわんのだよ。
キャッシュにないなら、メモリからとってくればいいじゃない。
そこは従来のGPUと変わらん。
ロードして必要データがキャッシュにある別の部位を処理するタスクに切り替えて間を繋ぐ。
そこも従来のGPUとかわらんし、むしろ条件は良い。
だが大丈夫、その程度で望み薄いとか言ったら、10分の1以下のL2キャッシュ容量しかないGeForceやRadeonは
「絶望的にありえない」から。
なぜ運任せになるかって、OSが入るから。カーネルタイムで処理が遮られるし、場合によってキャッシュが流される。
しかし全部のコアでカーネルが動くわけじゃない。
そこを避けさえすれば、明示的にコントロールすることすら可能だ。
あとFermiも含めテッセレータはソフト実装だから安心しろ。
FermiではCUDAで実装するんじゃね?
ソフト実装ではHull Shaderステージと内部処理レベルで統合してしまってもかまわんのだよ。
むしろそっちのほうが好都合だろう。
>>917
俺が言ってることを復唱しなくても十分だよ。行間読めない人?
>ゆくゆくはCPUコアと統合し、
が1世代の話に見えるか?
いずれにせよストリーム処理には変わりないが、きわめて高確率で処理対象の近傍のデータが
キャッシュに載ってるからメモリまで取りに行く頻度は激減する。
俺が言ってることを復唱しなくても十分だよ。行間読めない人?
>ゆくゆくはCPUコアと統合し、
が1世代の話に見えるか?
いずれにせよストリーム処理には変わりないが、きわめて高確率で処理対象の近傍のデータが
キャッシュに載ってるからメモリまで取りに行く頻度は激減する。
その論文のことじゃないが、
論文て肯定的な時だけ出すんじゃないぞ。±どちらでも書く。
これはこのように駄目でした、でも業績一つ稼げるんだから
論文て肯定的な時だけ出すんじゃないぞ。±どちらでも書く。
これはこのように駄目でした、でも業績一つ稼げるんだから
こういう人達は素人fanboyみたいに、知らないまま否定する、ということは
しない。必ず検討する。そして検討に時間を費やした以上は
その労力を自分のキャリア・業績としてカウントされる形で残そうとする。
検討したということと、採用へ傾いたということとはほとんど独立している。
しない。必ず検討する。そして検討に時間を費やした以上は
その労力を自分のキャリア・業績としてカウントされる形で残そうとする。
検討したということと、採用へ傾いたということとはほとんど独立している。
その言い分だと、彼に研究すらされてない
TeslaやFireStreamは検討にすら値しないってことだけどな
TeslaやFireStreamは検討にすら値しないってことだけどな
>>924
君が思ってる以上に米国の企業研究所は利益性に関してシビアだぞ。
なんで他社の製品の有用性を誇示し、自社製品のCellの商売上
不利益になりかねないレポートをIBMの名前で書かせる必要がある?
IBMが給料を出して研究者にLarrabeeの応用法を示させたことが
何を意味するのか、いくら鈍感でもわからないわけがないだろう。
君が思ってる以上に米国の企業研究所は利益性に関してシビアだぞ。
なんで他社の製品の有用性を誇示し、自社製品のCellの商売上
不利益になりかねないレポートをIBMの名前で書かせる必要がある?
IBMが給料を出して研究者にLarrabeeの応用法を示させたことが
何を意味するのか、いくら鈍感でもわからないわけがないだろう。
↓これは自分自身のことを言ってたんだね
> 素人fanboyみたいに、知らないまま否定する
> 素人fanboyみたいに、知らないまま否定する
テッセレータって結局分割自体より
増大後の頂点処理のほうが重かったりする
増大後の頂点処理のほうが重かったりする
IBMがXeonサーバーばんばん売ってる間はインテル様もヨイショしないとな
Larrabeeお願いしますだぁって
Larrabeeお願いしますだぁって
滑らかな曲線描くために頂点を増やすとかやんなくてもソフト実装されるラスタオペレーション側で
補完したほうがよっぽど処理は軽いと思うんだがね。
とか燃料投下してみる
補完したほうがよっぽど処理は軽いと思うんだがね。
とか燃料投下してみる
そもそもIBMは半導体製造業である前にソリューション屋だから
ソニー東芝の3馬鹿連合の腐れ縁引きずって商機を逃すような馬鹿な真似はしない。
ソニー東芝の3馬鹿連合の腐れ縁引きずって商機を逃すような馬鹿な真似はしない。
>>918
> >>916
> なんで「賭け」?
> あったらあったでトラフィック削れるし、無いなら無いでかまわんのだよ。
> キャッシュにないなら、メモリからとってくればいいじゃない。
> そこは従来のGPUと変わらん。
従来のGPUのグラフィクスはストリーム処理だから、そこでメモリにアクセスすることはないでしょ。
GPUの中をぐるぐる回るんだよ。
一方Larrabeeはタイルレンダのためそれができない。
VRAMに一時バッファを設けないといけない。
例えばテッセレーションする場合、分割しうる最大頂点数分バッファ確保しないといけない。
でそれが終わってタイルレンダ始めるときにL2に頂点が残ってる可能性なんて考えるだけ無駄。
Larrabeeでタイルを使うのは>>910のような積極的な理由でなく、
そうしないといわゆるROPの処理(特にZCull)で性能が出ないから仕方なくという面が
強いと思うな。
団子さんもGPUとしはLarrabeeに期待してないでしょ?
> >>916
> なんで「賭け」?
> あったらあったでトラフィック削れるし、無いなら無いでかまわんのだよ。
> キャッシュにないなら、メモリからとってくればいいじゃない。
> そこは従来のGPUと変わらん。
従来のGPUのグラフィクスはストリーム処理だから、そこでメモリにアクセスすることはないでしょ。
GPUの中をぐるぐる回るんだよ。
一方Larrabeeはタイルレンダのためそれができない。
VRAMに一時バッファを設けないといけない。
例えばテッセレーションする場合、分割しうる最大頂点数分バッファ確保しないといけない。
でそれが終わってタイルレンダ始めるときにL2に頂点が残ってる可能性なんて考えるだけ無駄。
Larrabeeでタイルを使うのは>>910のような積極的な理由でなく、
そうしないといわゆるROPの処理(特にZCull)で性能が出ないから仕方なくという面が
強いと思うな。
団子さんもGPUとしはLarrabeeに期待してないでしょ?
Larrabeeに批判的なひとって
Larrabeeに対する理解どころか
GPUの構造に対する理解も無いんですね
Larrabeeに対する理解どころか
GPUの構造に対する理解も無いんですね
メモリ(VRAM)はGPUの「外」にあります。カード上には溶接されてますけどね。
残念なことに、GPUの「中」に全部データ置いておけるほどFLIP-FLOP回路無いんですよ
残念なことに、GPUの「中」に全部データ置いておけるほどFLIP-FLOP回路無いんですよ
>分割しうる最大頂点数分バッファ確保しないといけない。
ちなみにこれは換言するならば、キャッシュ上にバッファの断片を確保できる分だけの頂点単位で
分割処理すればキャッシュミスなしでステージ間を繋ぐことができるってことね
ちなみにこれは換言するならば、キャッシュ上にバッファの断片を確保できる分だけの頂点単位で
分割処理すればキャッシュミスなしでステージ間を繋ぐことができるってことね
あ、ちなみにL2にヒットするようにスケジューリングして動かすってのはLarrabee側の
タスクスケジューラの仕事であって、「専用」に組む必要は無いっしょ。
高級言語ランタイムで提供されるAPIで遣り繰りだけならね。
だが敢えてDirectXなどクソ食らえと言っておく。
音楽配信におけるApple、検索エンジンにおけるGoogleがそうであるように
猫も杓子もMSに主導権持たせる必要など無い。
タスクスケジューラの仕事であって、「専用」に組む必要は無いっしょ。
高級言語ランタイムで提供されるAPIで遣り繰りだけならね。
だが敢えてDirectXなどクソ食らえと言っておく。
音楽配信におけるApple、検索エンジンにおけるGoogleがそうであるように
猫も杓子もMSに主導権持たせる必要など無い。
>>947
クソ言う暇があったら自分で作れや
クソ言う暇があったら自分で作れや
コンシューマ優先のうちは、Xbox独り勝ちにでもならない限りは
どのみちクロスプラットフォームのミドルウェアで対応することになるからね。
柵の多いDirectXに囚われず自由にカスタムエンジン書きたい酔狂なエンジン屋さんがいるかぎり
ソフトウェアレンダラはそれなりに使われることになるでしょうよ
ちなみにEPICはLarrabeeべた褒め
どのみちクロスプラットフォームのミドルウェアで対応することになるからね。
柵の多いDirectXに囚われず自由にカスタムエンジン書きたい酔狂なエンジン屋さんがいるかぎり
ソフトウェアレンダラはそれなりに使われることになるでしょうよ
ちなみにEPICはLarrabeeべた褒め
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / Intel スレッド一覧へ
みんなの評価 : ○類似してるかもしれないスレッド
- Intel Larrabee 5コア (985) - [95%] - 2009/12/19 17:16 ○
- Intel Larrabee 1コア (1001) - [95%] - 2009/3/27 22:32 ○
- Intel G4X(G45/G43/G41) (727) - [31%] - 2009/8/18 5:31 ☆
- Intel Core2 Duo/Quad/Xeon 合同 134コア (1001) - [21%] - 2009/1/13 20:01 ○
トップメニューへ / →のくす牧場書庫について