- Core i7 が Atom に駆逐された件
317 ：Socket774[sage]：2009/04/07(火) 00:21:44 ID:g7ggsR1Y - Limaでいいじゃん。65nmSOI Athlon64 2000+(1GHz)でTDP 8W
|
- Core i7 が Atom に駆逐された件
318 ：Socket774[sage]：2009/04/07(火) 00:27:14 ID:g7ggsR1Y - Lima vs. Atom
ttp://northwood.blog60.fc2.com/blog-entry-2207.html
プラットホームとして消費電力でATOMがAthlon64に負ける。
945GCが盛大に足を引っ張ってるわけだが。
|
- Intel Larrabee 2コア
139 ：Socket774[sage]：2009/04/07(火) 00:49:07 ID:g7ggsR1Y - タイルにしたってLarrabee程度のキャッシュじゃSD解像度くらいでしか役にも立たんと
どっかのスレで教えてやったろうが、馬鹿団子。
効率を上げるのはメモリ量じゃなくて転送帯域だぞ。
ネコの額ほどの広さしかないキャッシュなんて一瞬で使い切って、結局転送速度律速になる。
本来ならReadバス2本+Writeバスの3系統ほしいところだ。
|
- INTELがNVIDIAを提訴
173 ：Socket774[]：2009/04/07(火) 02:40:18 ID:g7ggsR1Y - >>169-170
元来がカルフォルニア大学バークレイ校のRISC Iベースだし、
1989年からアーキテクチャは公開されてて富士通やTIなんかがオリジナルSPARCを開発･製造している。
もともとSun Microsystems自体スタンフォード大学のワークステーションアーキテクチャをベースとした
数あるSUN-WS製造メーカの一つが生き残ったものだし。
>>171
SGI破産したけどなｗ
|
- 何でARMのスレがないの？
45 ：Socket774[sage]：2009/04/07(火) 02:56:43 ID:g7ggsR1Y - MSM7600とか最強じゃね？
|
- Intel Larrabee 2コア
148 ：Socket774[sage]：2009/04/07(火) 12:24:22 ID:g7ggsR1Y - >>141
ひどい勘違いがあるようだが、Larrabeeにブレイクスルーなんて無いよ。
既存GPUに比較して目立つ要素はなにもない。>>147の言う自由度はあがるけど。
団子が主張するタイルだのローテーションだのキャッシュだのは既に実現されてる。
ペンキの話題に乗っかってやるなら、500mlのバケツを20個くらい用意して「さぁどんと来い！」と
叫んでるのがLarrabee。バケツにはペンキ以外にニスも入れられるぜ、万能だろ！？って感じ。
バケツにペンキが残っているうちは他の人とバケツを交換しあえるので一見効率がよさそうに
見えるけど、現実を見ると壁は20平米位の広さがあって30色使うことが要求された。
足りない色が出るので中身交換しにヨチヨチ歩きの子供がお使いにでる。
バケツの容量も足りないからやっぱりお使いに何度も走る。
所詮使えるのは犬小屋の屋根を塗る程度でしたってオチ。
|
- Intel Larrabee 2コア
149 ：Socket774[sage]：2009/04/07(火) 12:56:46 ID:g7ggsR1Y - 3D処理で扱うデータは
・ジオメトリ（形状)データ。数万単位の頂点、テクスチャ座標、カラー情報など。
・シェーディング（陰影）データ。ピクセル毎の演算処理。レイトレも同じ。
・フレームバッファやテクスチャデータ、アルファ値などのイメージデータ。
レイトレでもZ-Bufferでもこれらは変わらず必要なデータだが、これがどれだけの量になるか考えればいい。
既存GPUではこれら処理ごとに（内部的には）個別の足回りを用意している。
NVやATIのストリームプロセッサ部分に置かれるキャッシュはLarrabeeのものと同様に共有される上、
ATIの場合は別のSPアレイとの共有用キャッシュも置かれる。
メモリインターフェイスはピクセルオペレーションでのタイル処理に併せて4ないし8程度分割して置かれ、
もちろんそれぞれにキャッシュがおかれる。
LarrabeeでIntelがさもすごそうに発表している内容は、Intelにとって画期的なだけで
「あって当然」「なにを今更」の内容でしかない。
|
- Intel Larrabee 2コア
151 ：Socket774[sage]：2009/04/07(火) 16:28:21 ID:g7ggsR1Y - >>150
SD程度の画質なら最速じゃないとしても、
UnifiedShaderなんかに比べて遥かに高い自由度と、x86系プログラマの熟練度っていう強みから
最強にはなれるかも。
消費電力が数W程度に抑えられるなら、
Windows7が動くスマートフォン用プラットホームとしてQualcommのMSM7xxxxを駆逐できるかも？ｗ
|
- Intel Larrabee 2コア
153 ：Socket774[sage]：2009/04/07(火) 16:50:41 ID:g7ggsR1Y - それは詳しい団子が教えてくれんじゃない？
Larrabeeのキャッシュに幻想抱いてる団子に対し、
> Larrabee程度のキャッシュじゃSD解像度くらいでしか役にも立たん
つーのが俺の主張だし。
|
- Intel Larrabee 2コア
157 ：Socket774[sage]：2009/04/07(火) 17:30:44 ID:g7ggsR1Y - >>154
まずZ-Buffer法の場合。
オブジェクトはあるグループ単位に切り分けることが可能だからこれは順次処理すればよい。
レイトレーシングと比較して大量のオブジェクト数でも少ないキャッシュですませられる。
しかしそのオブジェクトがどのフレーム領域を占めるかは完全にランダムであり、
Z-buffer法の性格上、BGRA情報およびZ-Buffer情報は頻繁に読み込み-比較-書き出しが行われる。
タイル式で処理する場合はこれを分割してキャッシュに保持することになるが、
必要なキャッシュ量がどのくらいになるかは簡単に計算できるでしょ。
> 解像度の話なら、SDで最強なのを６発積めばＨＤまでいけるってことだろ。
まぁ要するにSLIだのCrossFireやれってことだね。
レイトレーシングの場合。
ピクセル毎に注目するためフレーム領域は一部がキャッシュに乗っていればいい。
この点でZ-Buffer方に比べ、高い解像度でも必要なキャッシュ量は小さくてよくなる。
一方で、レイトレーシングの場合光線と交差するオブジェクトを全て検査する必要がある。
オブジェクトの構成要素は最低でも X,Y,Z座標と透過率、反射率、屈折率、そして RGB。
場合によってはテクスチャ座標（U,V)も必要。1トライアングルあたり72〜132バイト。
全てのコアでこのデータは共有可能なためLarrabeeの場合L2にドカンとのせておけばいいけど、
搭載できるデータ量に対しオブジェクト数がどの程度になってしまうかは簡単に想像つくでしょ。
SD解像度なら数千ポリゴンで済ませられるけど、解像度高くなってきたらそれなりに分割しないと
荒さが目立つ。
これらに加えて複数のTextureイメージ抱えてFSAA用の合成を行いつつ、
さらにインストラクション用にキャッシュを裂かないといけない。
|
- Intel Larrabee 2コア
159 ：Socket774[sage]：2009/04/07(火) 17:45:57 ID:g7ggsR1Y - >>155
> これを64*64タイル程度の適切な単位で実現するには、ある程度のオンチップキャッシュの大きさが必要になってくる
そういうこと。
たとえば24領域つかって 64x64サイズのタイルを表現した場合、
同時に扱えるフレーム領域は512x192程度でしかない。
>>156
> でもIntelは解像度が高くなるほどキャッシュによってメモリへの
> アクセスを減らすことが出来ると言っていたはず
インテルはいつもこういう部分でポカを行う。もしくは分かっていて騙す。
大量のオブジェクトがスカスカの空間中を遠方で蠢いてるだけなら、「平均的に見た場合」正しい。
一方、大量のオブジェクトが万遍無く空間に散らばっていた場合、全ての領域に
アクセスが散発的に発生する。また少ないオブジェクトでも画面いっぱいに
ドアップで表示されるような場合、全ての領域に連続したアクセスが発生する。
これらの場合、キャッシュの入れ替え作業が頻繁に発生しはじめる。
結果どういうことがおきるかというと、ピーク性能は高くてもある条件下で極端に性能が落ちる、
つまりフレームレートがいきなり低下するという状況が発生する。要するに、「もっさり」GPUの誕生。
|
- Intel Larrabee 2コア
161 ：Socket774[sage]：2009/04/07(火) 17:51:28 ID:g7ggsR1Y - > 既存のGPUはキャッシュ持ってるとは言え、1ポリ描画毎にVRAMにフラッシュせにゃいかんようなもん
これは相当以前のGPUの話であって、現行GPUはオンチップキャッシュに載ればそこで処理される。
もちろんキャッシュに乗り切らない部分はメモリと入れ替えが発生する。
1/60毎で済ませられるかどうかはLarrabeeもNVもATIも変わらん。
|
- Intel Larrabee 2コア
162 ：Socket774[sage]：2009/04/07(火) 17:52:35 ID:g7ggsR1Y - >>160
君はもう少し>157を理解したほうがいい ;-)
|
- Intel Larrabee 2コア
166 ：Socket774[sage]：2009/04/07(火) 18:03:33 ID:g7ggsR1Y - >>163
ああ、もしかしてKYROなんかの奴を言ってる？
あれ、単なるZ-Sortの発展です。領域ごとにポリゴンソートして手前だけ描画。
以前団子には説明したけどな。当然だけど、NVでもATIでもいまのUnifiedShaderなら再現可能。
いまそれが使われないのは、
・交差ポリゴンの処理が複雑になり正しい表示が行えない、
もしくはポリゴン分割処理を伴い速度にペナルティが発生する
・透明処理が行えない、特殊な追加処理が必要となる
という致命的な欠陥があるから。
|
- Intel Larrabee 2コア
169 ：Socket774[sage]：2009/04/07(火) 18:10:39 ID:g7ggsR1Y - >>164
> じゃあメモリのバンド幅とキャッシュサイズをあわせて論議しなければならないのでは？
そういうことです。
タイルレンダするからキャッシュ溢れおきず最適に描画できるっていうのは幻想ですんで、
結局足回りが重要になってくるんです。と、>139で申しております^^
>>168
その頂点データがレンダリング途中で可変という実に厄介な現象が発生する。
テクセルだけ注目してはいかんというのは>157のレイトレの方で解説した。
|
- Intel Larrabee 2コア
174 ：Socket774[sage]：2009/04/07(火) 18:37:01 ID:g7ggsR1Y - >>170
君のいうタイルレンダをきちんと説明してみ？
DreamCastというキーワードが出てきたからKYRO、もっといえばPowerVRのことだと思うんだけど ;-)
ごめんねPowerVRなら元中の人なんです。
> 別に厄介じゃないと思うけど…次に必要なポリの頂点データはわかってるんだから順次プリフェッチするだけ
交差するポリゴンの前後関係がでたらめになってもよければね。
正しい表示を行う場合、交差部分でポリゴンを分割していく処理を行うため、
ポリゴンスキャンを最初に行う時点で新しいポリゴンが発生し、頂点データが新しくなります。
>>172
> タイルレンダならメモリのバンド幅を節約できるってのも幻想なの?
フレームバッファだけみたら節約になりますけど、3D処理ってそれだけじゃないですからねぇ…。
たとえばHD解像度を64x64で分割した際、1万トライアングルをなめるのにかかるトラフィックって
どのくらいになると思います？ 510パスになるわけですけど。
|