1 :
名無しさん必死だな :
2005/07/03(日) 08:59:25 ID:QQwC7BCv
まりすみぜる
頭のおかしい人は放置でよろ。それでも気になる場合はNGID推奨。
開発環境は全然進歩してないって茶谷が言ってたわけで。
せいぜいましになるのはOpenGL, Cg, Cell周りのIBMが用意したツールがつくって所くらいだろ。
■PS3の開発環境はPS2の時と比べて変化しているところはあるのでしょうか。
【茶谷】基本的にはあまり変わりません。開発用のターゲットハードウェアと通常の開発環境、
ツールがそろっています。従来と異なるのはNVIDIAへグラフィックスを変更したことによるCgコンパイラやツールの追加、OpenGL ESのサポートなどです
http://pc.watch.impress.co.jp/docs/2005/0520/e303.htm VUをprintfでデバッグのは鬼だったが、今度は7個のVUをprintfでデバッグ
するのかよ。。。。
うはwwwwwwprintfおkwwwwwwwユメガセバマリングwwwwwww
6 :
名無しさん必死だな :2005/07/03(日) 10:14:48 ID:/UP3MsYW
7 :
名無しさん必死だな :2005/07/03(日) 11:09:18 ID:0rUE6ABt
そうした方がハードの性能をたたき出せるとか考えんのかな>ID:mUQoxDJMは。
帯域が相関してROPがミクロとマクロで統計上無意味なビッグバン!
10 :
( ● ´ ー ` ● ) はスバラシイ :2005/07/03(日) 12:49:03 ID:QpvcjFeX BE:7867627-###
ハイパースレッディング機能って要は分割ダウンロードみたいなものでしょ。
な、なんだってー!
>>7 力技で局所的な性能アップなんて前時代的な考え。ナンセンス
創刊、いや相関の話はさておいて、 GeForce7のアーキテクチャはそのまま持ち込んでほしくないな。 せめて、バーテックスシェーダの代わりに統合シェーダにして、 ピクセルの処理もできるようにしてほしかった。 統合16、ピクセル24or32、うち統合シェーダのの半分は予備みたいに そうすりゃ、面積は増えても歩留まりは上がるし。 トランジスタは、PCIeとかビデオ処理を削った分からまわして。 メリットは、 シェーダが多少壊れていても出荷できる。=コストダウン ある程度柔軟に作業を処理できる (頂点処理が必要ならCellにもやらせればいい。 そういう時は物理計算などで手を抜けばいい) デメリットは特に思いつかないな。 設計に手間がかかるぐらいか?
>デメリットは特に思いつかないな。 >設計に手間がかかるぐらいか? 何独り言言ってるの
>>13 いいよ、Gefotce7800のまんまで、
最高性能なXBOXも結局はPCのGPU品まんまだったしな。
>>3 それは要するに今までのアプリケーションだと、コアいくら増やしてもあんまり性能上がらない。
むしろ性能下がると。
でもそれって当たり前のことだし、前から言われてなかったっけ?
ゲームの場合、それぞれのCPUに合わせてアプリケーションを設計するから関係ないと思う
>>3 PenXEはPCからの見た目は等価な4プロセッサだけど実際にはHT対応のPen4×2だから、
スレッドの割り振り方が下手だと性能が落ちる。
というのは分かったんだが、PS3との関係が分からん。
RSXがG70ベースであると仮定して、 ・PureVideoがちゃんと削られているのか? ・PureVideoを削ったなら、削った分を使ってパイプライン増量してるのか? が、気になって仕方がありません。 GeForce6で見る限り、PureVideoのダイ面積ってすっげ〜デカかったと 記憶してるのだが、SPEのあるPS3ではさすがにいらんだろうと。 ここまでG70そのまんまだったなら、かなり(´・ω・`)ショボーン RSX確定情報マダ-?! チンチン(AA略
>>18 うむ。
どっちかというと、2スレx3コアなXBOX360のほうが、
その罠にハマる可能性が高いよね。
パイプラインの増量は無いだろう ゴトーさんも言ってるように、E3で発表した 1サイクルあたりのオペ数が G70と同一。 これ以上増やしてもROPが追いつかないし、、 せいぜいテクスチャキャッシュの増量が関の山では。 あるいはROPを増強とか? 3億トランジスタ以上なのは明言してるから、何かの追加はありそうだが・・ 何故 正確なトランジスタ数を言わないのか? a・・・ G70との比較で 何を付け加えたのか推測されないようにするため b・・・ G70から 単に削っただけなのを指摘されないようにするため c・・・ 単に面倒だった
23 :
名無しさん必死だな :2005/07/03(日) 14:54:58 ID:atBrTvwt
>>20 これはタスクの粒度の問題で、マルチコアに特有の現象だからCellとX360CPUの
どちらにも当てはまるよ。
タスクの粒度がコアの性能に対して細かすぎるとタスクの切り替えが頻繁に
起きてオーバーヘッドが発生し易くなるし、逆に荒いとコアに待ちが発生するので
コアの性能を十分に発揮するために最適な粒度というものが重要になるんだな。
>>3 の例では粒度が荒いから2コアのPenDの方が性能を無駄にしていないという事。
ただ、プログラム側の都合でコアに合わせた粒度にするのは条件的に難しいから
マルチコアではある程度の性能が無駄になるのは仕方が無いと言われている。
てか、CELLに関してはあれだけ色々やってるのに、RSXに関してあまりにもなんつか、 寂しい発表しか無いのが不思議。 この先TGSはちょっと違うだろ? E3では技術デモが主体でチップそのものに関する事は殆ど語られてないし。 GF7800の発表会がそれだと言うのは流石に寂しすぎる。
G70は低消費電力化のためのチューニングもしてくるだろうな。 6800Ultraより50%消費電力減らしたらしいけど、それでも家電に乗せるには多すぎるよね。
ここが噂の憶測スレですか
バスケ選手を探し出すスレです
ちがいます
>>23 SPEはタスク切り替えのオーバーヘッドが大きいから粒度を細かくすると性能が
落ちる傾向になりそうってことかな?
なるべく長くかかりそうな処理を任せたいんだけど、そうすると処理待ちが増え
そうだね、SPEの性能を十分に引き出すというのは相当大変な気がする。
箱○CPUは性能に合わせて粒度を下げればいいだけだからラストのパフォーマンス
調整はこっちのほうが楽そうだ。
SPEで使えるコマンドも限られているからルーチンの振り分けもしなけりゃならないしめんどくせー!
>>31 ド素人丸出しの文で煽るのは恥ずかしくない?
33 :
名無しさん必死だな :2005/07/03(日) 15:59:12 ID:k7rzHZSM
>>30 というか、箱○のマルチコアって、競合が殆ど起きない
バックグラウンド処理が前提なんじゃないの?
普通にゲーム作る分には、マルチコア意識しなくてもパフォーマンス出ると思うし、
そうでないといけない。
CELLはどうかしらんけど、その辺意識しないと駄目ってんなら、ナンセンス。話にならん。
>>30 SPEのタスク切り替えのオーバーヘッドが、普通のコアと比べてどれだけ大きいかは分からん。
LSでもL2でも同程度のコードがメインメモリから読み込まれるのは変わらんし、レジスタ数もほぼ同じだろう。
タスクの処理待ちについては、普通のスレッド処理は指定したイベント待つようにスリープするから、
別に待ち時間にSPEを占有する必要も、わざわざ準備が整う前にコードを読み込む必要もないでしょ。
イベントやタスクはPPE上のOSが管理してるんだろうし、普通は他に割り当てられるタスクもあるはずだし。
>>30 CELL の場合「SPE の性能を十分に引き出す」ほどのチューニングをしなくとも、
パフォーマンス調整後の箱○CPUより性能が高そうだから問題ないんじゃない?
妄想乙
>>34 ・このスケジューラには新規にスレッドが追加された場合、
システムとしてリアルタイム性確保可能かどうかを自動的に
判定するアルゴリズムを新規に開発して実装
・スケジューリング・アルゴリズムには「ギャング・スケジューリング」
方式を採用。この方式は同一のSPEモジュールに含まれる全ての
SPEスレッドが、同時にSPE上にディスパッチされるように
スケジューリングする。同期対象のSPEスレッドを常に同時に
動作させ、スピンロックによって同期を実現し、コンテクスト
スイッチによるオーバーヘッドを低減。
・スケジューリングパラメータには「同時実行SPEスレッド数」
「平均SPE処理比率」「先行制約」がある。
「先行制約」とはSPEモジュール間における実行の順序関係。
・スケジューラ以外にもSPEの処理を仮想化する仕組みを
設けた。SPE上のプログラムからゲストOS上のデータに
アクセスする仕組みとか。それによってLinuxのように
メモリ保護機能のあるゲストOSでもPPEと同様にアクセス可能。
>>37 いや、まあそれは読んだけどね。
Windowsのスレッド管理は基本的にただ1つのイベント待ちで処理されているけど、
Cellの場合はもっときめの細かいパラメータを持った管理を独自OSがやるってことでしょ。
http://pc7.2ch.net/test/read.cgi/jisaku/1116091363/ 456 名前:440[sage] 投稿日:2005/06/26(日) 11:10:21 ID:pcmUFXpz
シェーダ数が同じでも演算ユニット数が減らされる可能性もあるわけで。
メモリ帯域、メモリバスあたりに7800GTXに大きなアドバンテージがある。
むしろ、Xbox360のGPUよりRSXが劣っていることがほぼ確実で、
7800GTX>XboxGPU(R520)が有力になってきた今
RSX>7800GTXとなることはまずないかと。
CPU、GPUの性能は共にPS3が圧倒でFA。 CPUとGPUのリンク性・効率性が問題なんだろ? しかし結局、総合性能はPS3の勝ち。 箱○は先行発売に意義がある。
>>41 後はM$の主張(XNA)通りと仮定するなら
ソフトの質でローンチから差をつけられるか、だろうね。
つか、仮にG70と完全に同じだったら単純にクロックの高いRSXの方がG70より性能が高いと思うんだが。 実際に出てくるゲーム画面ならさらにRSX(というかPS3)有利だろうし。
演算ユニットはG70の設計のキモ。 ピクセルシェーダ内の積和演算機がNV40の1個から今回2個に倍増された。 この構造がG70とRSXとで同一であることは、E3での発表(136 ops/c)からも明らか。 シェーダユニット部分はG70とRSXとで、全く変わらないだろう。 両陣営とも、いい加減、諦めろ。 RSXはG70のクロックを 1.3倍に高めた兄弟チップ。 >>むしろ、Xbox360のGPUよりRSXが劣っていることがほぼ確実で なんだこりゃ?願望が暴走して現実が見えなくなったのか?
>>44 普通に考えたらそうなんですけど、ネットは広大ですから・・・
Cell、テクノロジに分けるんじゃなくて PS3,Xbox360テクノロジスレに分けた方がまだましな気が。
そういえば、箱○のメモリコントローラって、GPUパッケージ内に統合? それともブリッジチップとして別パッケージ? 情報出てない?
GPUに統合
これもライブラリで提供してくれるのかな。 木や兵の体型なんかで使ってくると面白そう。 Xbox 360ではグラフィックを自動生成 (ファミ通Xbox) Xbox 360について、マイクロソフトのプラットフォーム開発統括部統括部長・間中氏へのインタビューが掲載されています。 間中氏によると、Xbox 360ではJ・アラード氏の考えを反映してグラフィックの自動生成機能が用意されているとのこと。 HD対応になり、開発者がグラフィックを一から制作するという従来の手法では、作業量が膨大になってしまいます。 しかし自動生成を利用すれば、計算によってグラフィックを作り上げられるそうです。
木の自動生成って言えば、SpeedTreeが有名か。
>>49 メモコンはGPU側、CPUはFSB経由でGDDR3をシェアする。
他にCPUのL2の一部をロックしてデーターをスルーしたりLSのような使い方も出来るとのこと。
>>51 あまりチューンの事考えなくてもいい初期のソフト限定機能になる希ガス。
それEE
>>53 THX.
GPU⇔GDDR3の速度はかなり大きいけれど
CPU⇔GDDR3の速度が小さいのはそれも有るのかな。
57 :
名無しさん必死だな :2005/07/03(日) 17:29:45 ID:qdZzdwWL
>>54 そんなことはない。
木・草・フラクタル生成した山脈・雲・煉瓦タイルにビル群・エキストラキャラやテクスチャーなど自動生成出来るものはやまほどある、むしろこれからのトレンドと言っていい。
統合シェーダーの得意分野だしメモリ帯域の削減にもなる。
ワロス
プロシージャルテクスチャはSPEに取っても得意なんだが。 むしろC/C++でコーディング出来る分SPEでやる方がやりやすいかと。 過去のPS3関連の記事でもCellの強みとして紹介されてるし。
>>57 プリレンダムービーで使うCGアプリでは、このてのツールは一般的になってきてるけどもうGPUで出来ちゃうのかー。
すごいなー、もう少し未来の話だと思ってたよ。
>>60 PCゲームでも一部使われてるらしい、が
利点と同時に欠点もあって
現在、広範囲に使われてない。
ググってみるよろし。
よく知らないんだがSpeedTreeやらその辺のツールって開発時に使う事によってオブジェクトをいちいちレンダリングする手間を省くためのツールだと思ってたけど プログラムを組み込む事でゲーム中にリアルタイムで生成するためのプログラムだったの?
>>54 がちがちのライブラリではなく
ソースレベルのテンプレートをカスタマイズする形なら
いろいろ流用できるし経験値もたまりそうだけどどんなもんなのかね。
>>63 リアルタイムにポリゴンデータの生成(だけでなく描画まで込みで処理)してくれる
SpeedTreeRTというバージョンがあります
もちろんその場合はゲーム中にSpeedTreeRTのライブラリを組み込む必要があります
CELL+RSXはなんでも出来ます出来ますだけで 何もサポートしてくれないんだな。 これってもしかしてSCEの中小つぶし戦略なのか。
>>67 ミドルウェア開発会社とは連携しとるし。
MSにしたってXNA構想からも解るように
開発ツール、ライブラリの全てを自社で用意しようなんて思ってない。
SCEよりは充実してるだろうけどね。
>>66 は別にMS社がやってて無償提供してるとかいうわけじゃないよなぁ・・・。
>>67 は何か勘違いしてるのか?
X360CPU+GPUはXNAで開発が楽になる。 ↑ PPEx1しか使わんのならそうかもしれんな。 PPEx3を使いこなすにはそれなりのスキルは必要だろう。
>>23 マルチコアとSMT一緒にすんな、何知ったかぶってんだ
>>70 それを言ったらCell+RSXは相当なスキルが必要だろう。
3個じゃなくて2個だろ。 ゲーム開発者が使えるのは2個だけですよ。 1個はNTカーネル用。 いい加減諦めろ。
板垣もマルチコア難しいよぉーって言ってたし。XBOX360も特別簡単ってわけでもないだろう
ミドルウェアなんかウンコですよ。
GKが来るとまともなスレ進行出来ないな、アフォ杉。
77 :
名無しさん必死だな :2005/07/03(日) 19:33:03 ID:IRtEiJMB
Xbox360はIDE、Modeling Engine、自動生成ライブラリが標準で付くのに PS3は全て別売りまたは手書き。 サポートしてるのはprintfデバッグだけww
XBOX360はMSが認めた会社にしかだしてないべ。 サードは自分からは入れない。
性能で負けたことに気が付いた 今、箱信者は開発環境を武器に立ち上がろうとしている・・ がんばれ!!
自動生成した結果を一度メモリに書き出してるんだろう。 生成と描画を連続してやるならUMAのほうが効率よさげ
82 :
名無しさん必死だな :2005/07/03(日) 19:55:14 ID:3gfqR6pW
>>77 また、お前か。
>自動生成ライブラリ
そんなものは付きません。
>>80 RSXのテープアウトが9月とか噂されてるのに
今の段階で性能の良し悪しを語ったところで意味あるの?
ちなみに海外ではXBOX360のβキットがかなり高性能で
PS3の開発機より性能高いって噂があったはず(ソースは忘れた)。
GF6800のSLI接続(トランジスタ合計4億以上、RSXは3億程度)
よりXBOX360βの方が性能高いって事は、実機もXBOX360の方が
性能高いか、又は同等くらいの性能なのではないか・・・
クリエイターはぶっちゃけシングルスレッドで行くところ多いんじゃない? PCを含めたマルチ展開するならこれが一番無難。
>>84 噂は噂。
君はすぐどこかの宗教に引っかかりそうだ。
>>84 >PS3の開発機より性能高いって噂があったはず(ソースは忘れた)。
噂、ソースなしで、話を展開されても。
是非、探してきてくれ。信憑性を判断したいから。
マルチでいくに決まってんだろ 今の時代のCPUがどんなもんだと思ってんだよ 4つもスレッドがあるのもこれからのデフォになりそうなのに
ゲームプログラミングにおいて、マルチスレッドはあんまりメジャーじゃないよね。 はっきり言って、マルチスレッドの存在意義は将来的な拡張(ゲーム機の性能 限界まで引き出したい場合、CPU側でバーテックスシェーダー処理を行う) 程度の意味しか無いような気がする。
>>85 RSXのPPEもマルチスレッド対応だよ。
コンテキスト切り替えがネックにならないのなら
スレッド分割しとく意味はある。
>>90 >RSXのPPEもマルチスレッド対応だよ。
訂正。CellのPPEね。
XBOX360のカーネルがNT系なのは分かるが、デバイスドライバモデルはどうなるのかね。 XPのWDMなのか、LonghornのLDDMになるのか。 今のGPUがCPUネックになって性能が発揮できないのは、今のドライバモデルがタコなためとも言われるが。
G70が既存のゲームのベンチマークでまったく 性能が発揮できなかったことについて
G70はSM3.0 xenosはSM4.0
毎度で悪いが ソースくれ<SM4.0
板垣も言ってるようだがマルチスレッドをゲームで効率よく使おうとするなら 補助的な役割でサブスレッドを走らせる程度しかないんだよな。 コア3基の6スレッドを使っても1基1スレッドで処理したときの2倍ぐらいしかならない。 大雑把な理論だがゲームにおいてはそんなもんだろう。
>Xbox360「フレームシティ」物理エンジン搭載であんなことも
>ナムコがXbox360向けに「リッジレーサー」新作を開発中という噂が出ています。
>「メタルギア」シリーズ、Xbox360・Revolutionで開発の可能性も
>コナミの小島監督が、「メタルギア」シリーズ新作をPS3以外のXbox360とRevolution向け
にもリリースする可能性があることを明らかにしたそうです
↓
http://www.g-rev.com/News/Xbox/index.shtml
SM4.0じゃなくて、WGF2.0だろ。
>>99 日本語記事->あいまいな英語訳->誤訳->それを
>>99 がスレ違い投稿
>>100 XenosがWGF2.0に届いてないってのは散々既出だな
WGF1.0についてはどうだっけ?
>>92 箱○の単一ハードウェアでしか動かないのだから既存のドライバモデルなんて気にせず
最も効率が良い方法で実装するだろうね、PCのようにサードパーティーがドライバを書く
事は無いのだし
Xbox360関連の特許でMSがバックグラウンドの自動生成をメイン以外のスレッドで行う というのを出していなかったっけ
360信者の捏造が酷いな・・・未だPS3は不明な部分が多いんだから、もう少し情報が出てから活動すればいいのに
>>104 バッググラウンドで何かを処理するということは
プログラミングにおいて何も特別な話じゃない。
(割り込みで曲を演奏するのだって、バッググラウンド処理)
あと、PS3に比べて、Xbox360が特に自動生成に特化してるわけでもないよ。
頂点シェーダとしての性能はSPE、ピクセルシェーダとしての性能もRSXの方が上。
一部の人間の統合シェーダ幻想は、ちと病的だな。
PS3信者見苦しいぞ ただの地雷7800なのに
G70発表されてから、今まであんなにべらべらと饒舌に インタビューに答えてたATIが急に静かになったのは気のせい?
地雷話もいいかげんあきた
箱丸はR520じゃないだろ
どっちにしても箱○はその地雷GPUに圧倒的な差をつけられてることを まず認識するべきだよな
>>109 R5xx系のGPUの再設計に追われて
お得意の勝手に勝利宣言をしてる時間がない
なんせ春発表だったのが夏発表に延期して、挙句の果てに秋発表(予定)
おかげでNVIDIA大儲け
経営責任を問われるだろうな
稼ぎ時ね!?
ATIの発言を整理してみよう 1:PS3のGPUはPCそのまんまだ 2:R500はゲーム用のGPUとしては最強だ(PS3はPC用なので比較から外してねお願い 3:今後発売される5年間のゲーム機の中でXBOX360は最強の性能だ(ATIのGPU使うレボの立場は・・
R500ならSM4.0だろ
そもそもゲーム用のGPUはXENOSしか無いので 唯一無比、一騎当千。これが本当の「無敵」。 既に発売中のライバルGPUの演算性能が 気持ちXENOSより高いような気もするが、それは錯覚だ。 XENOSは最強のゲームGPU・・・
>>116 Xbox360のグラフィック性能は他の次世代機の5倍だ。
他のって、、、PS2とかGC?
PS3がプロシージュアルシセシスライブラリが非搭載だからって GKはどうして無理やり話題をvsにしたがるのかね。
XenosはR500じゃないってば。現状オリジナルだよ。 完全ゲーム専用としてMSがてこ入れしたもの。
シセシルってなんですか?:-P
xboxのゲームは綺麗だがなんとなく見栄えがしないのが多い それはすべて発色のせい 30本箱のソフトを買ってきた俺がいうから間違いない
MS社員はGPUの歩留りについて話されると話題を変えたがるってことですか
>>122 R500はXENOSの開発コードでしょ。
で、PC用はX900(R520)と。
あの発色はnVidia製のだからどうしようもない。
R500は トランジスタが少ないのでなんとかなるだろう 90nmなら200mm~2を切るのは確実
FABLEとか個人的には細かいところまで描かれてHDRも効いて綺麗と思ったけど そこまで綺麗じゃないとかいう人多かったなぁ
>>128 せっかくだから、リーク電流とトランジスタ数の関係を説明してくれよと。
(テクノロジースレなんだし)
プロセスルールと大きく関係するのは、皆、理解してると思うが。
>>131 リーク電流はトランジスタから漏れ出す.
よって,トランジスタ数が多いほど,リーク電流も増大する.
こんなのはだめですか.
>>106 あぁ、バックグラウンド処理のバックグラウンドじゃなくて、画面上の背景とか
例えばレースゲーで草や木や空を別コアでやらせる、という
>>82 板垣さんは少なくともここに書き込んでいる、どのビチグソ
と比べても遥かに優秀な開発者である事は間違いないからな。
>>133 後景をバックグラウンド(別コア)で処理するということですな。
にしても、この処理分散は特殊でも何でもない。
結局、前景と後景のデータが揃った段階でしか描画スタートできないし。
(カリングやオブジェクトの描画順のソートが必要。しないと帯域が無駄になる)
136 :
名無しさん必死だな :2005/07/03(日) 22:53:04 ID:mlBgDkp0
>>106 SPEでやる場合は生成した頂点情報をどこに置くかという問題があるけどね。
XENOSの場合はローポリゴンでGPUに送ってディプレーストマッピングを元に
XENOSがフレームバッファーに書き込むだけだから帯域の節約になるが、SPEだと
一度生成した莫大な頂点情報をXDRにためてからRSXに送り出す必要がある。
いくら帯域の広いCellでも、それなりに負担になると思うよ。
その板垣サン、PS3のNUMAには反対したのに、360のマルチコアについては 反対しなかったのかな。Sun Niagaraのようなサーバ用途のCPUでなければ、 シンプルで低性能なコアを集積するのはあまりいいアイディアには思えない。 同じトランジスタ数で、PPC970のようなILP指向のシングルコア+VMX大幅強化+ 大容量キャッシュ という選択肢もあったろう。カタログ上の演算性能は落ちても、 シングルスレッドアプリケーションの実効性能を優先した方が 「開発者に優しい」という360のポリシーに沿っていたはず。
しかし、XeCPUが完成したってニュースが出てこないね。安藤さんによる と、CellよりXeCPUのほうが消費電力で不利らしいけど、3.2GHzで3*PPC コアって、かなり無理があったような。TSMCはCPUの生産ではよく問題 起こすし、まだ完成してないのかもね。
>>137 xbox360のCPUって,トランジスタの規模から言えばPPC970相当ですよ?
>>139 俺もそう思うんだが、後藤氏以外みんなin-orderの、CellのPPE相当のコアだって言ってるんだよ。
本当の所はどうなのよ? β開発機のスペック見りゃわかるだろうと思うんだが。
Cellだけじゃわかんねーし
143 :
名無しさん必死だな :2005/07/03(日) 23:14:20 ID:mlBgDkp0
>>140 GPUの頂点情報は普通VRAMに置くもんなんだが、バッファーをとっただけで
オブジェクトの前後位置まで確定出来るのか?
>>141 CELLのPPEよりは強化されてる部分も有ると思うけれど。
>>137 周波数では性能が出せないからマルチコアにしてるんであって
これは逆らえない流れ。
>>145 勘違いしているのはおまえの方。
SPEでも同じ事が出来るが帯域の節約には貢献しない。
箱○はCPUからXENOSに送る頂点数は少なくて済む、これをXENOSでポリゴン
分割してピクセルシェーダーに送りVRAMのフレームバッファーに書き込むから
XENOSからVRAMに送られるのは2Dのフレームデーターだけになる。
>>箱○はCPUからXENOSに送る頂点数は少なくて済む 寝言は寝て言え
>>145 136とは違う人間ですが、
ディスプレースメントマッピング使うためにはテセレーションをしなければいけないのは理解できますか?
・箱はGPU内部でテセレーション(分割後の頂点はGPUで生まれGPUで処理される)
・PS3はSPEでテセレーション(SPEからRSXにリングバス経由で転送)
となるのである意味バス帯域の節約にはなると思いますよ。
ところでRSXにSPEなどから直接頂点列を渡せるらしいですが、
受け取り側のRSXはどうやってそれを溜め込むんですかね?
複数のプロセッサからの複数の頂点ストリームを同時に受け取ることは出来ない気がするんですが。
オーダー順序の問題もありますし。
>>148 書いてある内容が理解出来ないぐらいの低脳ならいちいち返事しなくていい。
>>147 >帯域の節約には貢献しない。
Cell→RSX間の帯域を節約する必要は何?
仮に節約する必要があったとして、RSX側の頂点シェーダ使えばいいだけじゃん。
頂点シェーダ性能でXENOSより劣るわけでもあるまいし。
>>149 自己レス
GDDR3に乗せるだけで良いですね。
片や少ない収入を賢く使う倹約派、片や大きく稼いで大きく使う富豪派だから、 全く話が合わんな。
PS2でもVPU1がGIFに直結されててGSに頂点データが普通に 垂れ流しされてたはずだが、何を今更遅れない理由があるん だろうか。
>>146 周波数の向上で性能が出せないからマルチコアにしてるんじゃなくて
これ以上動作周波数を上げられないからマルチコアにして性能を上げようとしてるんじゃないの?
動作周波数上げられるなら、マルチコアにするより性能上がりそうだけどなぁ
>>149 XENOSはテセレーション後のデーターはeDRAMに溜め込むと思う、オブジェクト
単位かカリングした後のフレーム内全部かは知らないけど。
SPEの場合はRSXに送る前に頂点数が膨れ上がっているから、これをどう処理する
のかが疑問。
ちゅうか
G70単体でディスプレースメントマッピングやってるデモあるから
それ見てお前ら物言え・・
>>149 その辺が、G70と違うっていうクタの発言に起因するんだろうな
ただ複数のプロセッサとはいうが
所詮、SPEも演算機に過ぎないので頂点データの読み取りは普通にできると思うぞ
>>147 ポリゴン分割も決して軽い処理では無いと思うけれど?
>>156 eDRAMって所詮10MBしかないけどね。
SPE->RSXで10MBは、20GB/secの Cell->RSX帯域の1/2000に過ぎない。
言ってみればSPEから毎フレームRSXに流し込むとしても333MB送れるわけだが。
PS3にはXBOX360に劣る部分が見当たらない。 eDRAM非装備ぐらいか? ただそのeDRAMにしたってUMAによるボルネックを回避するための物だしな、 G70ほどの帯域を確保するのは難しいだろうな、ってかeDRAMがそんなに良いものなら PCに既に採用してるって。
>>157 SPEがディスプレースメントマッピングや頂点処理出来ないなんて一言も言ってないぞ。
SPEのLSは容量が小さすぎてジオメトリを単純にRSXに流すのは無理。 分割転送にしてもその処理プログラムも一緒に流すので効率悪ス。
>>163 その理屈だと、PS2でVUからGSに流すのも無理ですな。
VUのワークは容量幾らだったけ?
あーでもさ 箱360でディスプレースメントマッピングやってるゲームってまだ無いんだよな・・ PS3にはあるのにさ・・ファントムなんとかってやつ あとさG70単体でディスプレースメントマッピングできるから SPE使う必要ねーだろ・・
>>165 ゚д゚) ・・・。
このスレの知識レベルってこの程度なのか、どおりで話が通じない筈だ。
>164 VU1でVU Mem 16KBにMicro Mem 16KB。 VU0では各4KB。
この辺の話に暗い俺はここみてるとXbox360のeDRAMがなんでも出来ちゃう魔法の箱に見えてしまう。
>>167 ほとんど溜め込めんね。
ストリーム系処理中心でLS256KBと言うのは
ダブルバッファ前提で考えてもデカイな。
(VUが酷すぎたとも言えるけど)
RSXにもSPEを2,3個載せてくる可能性は…ないか。ないよな。
eDRAMはPS2で既に大した有効性は無いと確認されてるんだろ あれなら外付け8M〜にしとけば良かったと。その反省に立って RSX作ったんだから逆行してもしょうがないだろに
>>171 単に開発が間に合わなかっただけだよ.
ソニーと東芝は混載DRAMプロセスに投資してたでしょ.
>>171 急ごしらえでPC用を転用したRSXに今までの反省も何も・・
それを言うならNVIDIAチップ使ってたMSはATIに乗り換えた
わけだが・・。
しかしRSXには頂点シェーダーがあるのに、なんでSPEで頂点処理をさせたがるのか わからん。普通にRSXでやればいいだろう。 それにどちらが上か?にしか興味ないやつは、このスレにふさわしくない。 VSスレにでも行ってくれ。非生産的な議論に終始する
>>170 載せても意味ない。GPU側のクロック遅すぎ。
あれは3GHzで動くから魅力的なんであって。
>>174 高度な頂点処理や高度な光源計算したい場合は
SPE「も」使うことは有効だよ。
次世代機の後半はGIレンダリングが当たり前になってるだろうし。
>>171 PS2のVRAMとXbox360のそれはまったく違います。
>その反省に立ってRSX作った
nVidiaがSCEのチップの何を反省するのか。
いろいろ話がループしまくってまんどくせ。
>>164 あれは生成なんてせずにただの垂れ流し。
またLSのサイズが小さいとか言ってる奴いるの? 一応SPEはダブルバッファーで大量データ処理の解を持ってるが、 X360CPUのL1&L2キャッシュから溢れるデータ処理はどうするん? まさか、あんな少ないキャッシュに収める量しか処理しないとか言う訳?
>>178 >いろいろ話がループしまくってまんどくせ。
FAQと基本情報リンク集はあった方が良いかもね。
>あれは生成なんてせずにただの垂れ流し。
>>163 からの流れなんで。
つかいちいちvsするなと
SPEはXDRに置いたジオメトリデータをRSXへ流すだけの渡し役だと思うのだよ
>>180 了解。たしかに。
バランス的にジオメトリデータはXDRに置いてGDDR3にはバッファ領域とテクスチャ領域。
あとはSPEを使ってどう実効値を上げていくかをプログラマが試行錯誤。
SPEの具体的な使い方が示されていないからここらへん苦労する。
なんかセットアップやらテッセレーションやら頂点シェーディングやらが、ごっちゃにされてるな。 わざとやってるのか、素でボケてるのか。
>>183 具体的な使い方が示されないのは一般人にだけだと思うけどね、開発者にはサンプルが
渡ってるんじゃないかな?
箱○のロックできるL2の具体的な使い方だって一般人には示されてない訳で
SPE使って何とか切り抜けてくださいよってことだったとすればサンプルも何もないわな。 ゲーム毎に解答が違うんだからテストが大変だ。
発売まで後半年切ってる箱○と1年弱あるPS3の、現時点での開発環境を比べる事に 意味があるのかな・・・ 今から半年前に箱○の開発環境がどの程度整っていてのかと、現在のPS3の環境を 比べるならまだしも
>>183 >バランス的にジオメトリデータはXDRに置いてGDDR3にはバッファ領域とテクスチャ領域。
どこのプログラマも、最初は、この配置を考えそうですね。
Cell→RSX間(20GB/s)に頂点データと描画コマンドだけ通すのは
勿体ない気もするけど。
(XDR⇔DDR上のテクスチャスワップに使うのかな?)
>>156 テッセレーション後の膨れ上がった頂点データを、バックバッファをアクセラレートできる
貴重なeDRAMに置くとはとても思えない、ただでさえバッファの入れ替えが発生する
ぐらいにサイズが足りないというのに、頂点データなんて置いたらさらに入れ替え回数が
増えて、eDRAMの利点を無駄にすることになるし
>>188 一部テクスチャデータもXDRに置いてCellで処理をさせると思いますよ
例えば水面の法線マップテクスチャなんかは、毎フレームの書き換えが発生するので
XDRに置いてCellで処理し、描画時にはRSXから直接参照させれば効率が良いでしょう
VRAM側には変化の無いテクスチャデータやオブジェクトの頂点データを置いておき
CPUで処理を加えるデータはXDR側にといった感じじゃないですかね
>>190 Cell側での処理が終わったXDRのデータを、RSXから参照させる際のタイミングの管理などが厄介そう。
CellとRSXでの処理バランスが上手く均衡していないと待ちが発生するかもね。
>>190 なるほど。
Cell(SPE)側でXDRにテクスチャレンダリングしとくと。
考えてる人は考えてるなぁ。
>>192 Cell側では、次フレ用テクスチャレンダリングをしとけば良いと思いますよ。
そうすれば、同期はいらない。
>>194 リアルタイムな動的割り込みが入らないという前提条件があればの話かな?
そういうことならカリングを考えずにゴリ押しな処理になってしまうけどそこは
ゲーム仕様との兼ね合いになってくるんだろうなあ。
>>192 >>193 のとおりですし、箱○でもPCでも処理バランスが均衡していなければ
GPUかCPU、どちらかが待つ事になるのは当然ですよ
>>195 あぁ、カリングとの兼ね合いですか
でしたらGPUで行う詳細なカリングの前にCPUでオブジェクト単位や、単位空間単位の
カリングが行われますので、その時点で判断できますからGPUと同期する必要は
無いです
>>197 CPUでやるってことはCellからZバッファ参照に行くのかな?
結果的に効率悪い気がす
>>195 標準的なコンシューマゲームプログラムでは
CPU処理がGPU描画処理より、常に1フレーム分先行してるので
>>190 さんのアイディアは、XDR上のダブルバッファへ
CPU処理としてテクスチャレンダリングすることで容易に実現できます。
PCだと事情が違うので、いつも、これを説明するのに苦労する。
>>199 GPUでカリングすればすっきりするんじゃない?
それでも無理にCELL側でやるかどうかはゲーム次第ってことか。
あとXDRとVRAMにそれぞれバッファを持って参照し合うってのはレイテンシは大丈夫なんだろうか。
レイテンシが大きくても動作しなくなることはありませんよ。 理解せずに単語並べてケチ付けまくってるようにしか見えないが これは穿ち過ぎか。
>>198 >>200 違います
ゲーム内のシーン中のジオメトリデータは膨大になるので、明らかに表示されない部分の
データはCPUで取り除く(GPUに送らない)という処理を入れるのが基本です
XBOXのあるゲームではこの処理にCPUの20%〜30%を使っているそうですが
この処理をいれずにGPUにデータを送るととんでもなく無駄な処理をGPUがする事に
なるので、たとえCPU処理の20%〜30%使ってでもする必要があるんです
>>200 >例えば水面の法線マップテクスチャなんかは
自分は、このケースしか想定してないんだけど
カリングということは、このテクスチャレンダリングを
表示される限定的な領域に留めると?
確かに、それだと計算量は節約できるかもしれないけど
随分と複雑な処理になりますね。
>>201 すまんね、素人なりに知りたくて質問しまくってる。
>>202 CPUでの不必要なジオメトリの洗い出しをどうやってるのかが気になってるのです。
>>203 遮断物に隠れたときも、遠い湖でのノーマルマッピングが行われているんじゃないかと
思ったのだけどこのケースはまた別の手法で省かれる?
>>205 >遮断物に隠れたときも、遠い湖でのノーマルマッピングが行われているんじゃないかと
>思ったのだけどこのケースはまた別の手法で省かれる?
これはGPUの仕事ですね。
表示オブジェクトをソートして、手前から描画する限り
見えない領域のピクセルはテクスチャ参照しません。
>>206 たぶん、使われない場合に無駄にテクスチャが作られる事を想定してるんですよね?
例えばオブジェクトがカメラに写る範囲外に有る場合は、オブジェクトの中心座標と
カメラに写る範囲の情報からCPUで演算によって取り除けます
遮蔽関係についてもBSP法等を使えば取り除く事ができる部分もあります
もちろんCPUでのカリングで取り除けなければテクスチャを作る必要がありますが
それは仕方が無いでしょう
>>205 オブジェクトのバウンディングボックスが視野に入るかどうかを判定をするのが基本。
判定を高速に行うためのツリー化とか、カリング手法は様々なレベルで数多くの考案がされていて奥深い。
DirectXのドキュメントにも「最速のポリゴンは描画しないポリゴン」と書いてあるしな。
>>207 >たぶん、使われない場合に無駄にテクスチャが作られる事を想定してるんですよね?
>>203 の発言だと、そうです。
自分は面倒くさがりなんで、そこまで懸念はしてませんけど。
(最初からSPEの余ったパワー使う演出という程度の認識で)
>例えば
ID:ApzkhHJiさん、そこまでチューン考えますか…
リアルな水面を売りにするゲームなら、ここまでする必要があるのかもしれませんね。
既に具体的な水面ノーマル用のテクスチャサイズも想定なさってるとか?
>>202 別にXBOXに限らず常識的にやってる事だけどね。
格ゲーとかの閉じられたケースは例外だけど。
>>207 CPUでテッセレーションをやると、どの段階でカリングやクリッピングをやるのかが問題だけどね。
分割後だとソート自体に時間がかかるし、カリングした後に分割するとエッヂ付近のポリゴンが破綻することがよくある。
カリングまでやるとなると1フレームぶんのポリゴンバッファがいるからジオメトリデーターはXDRに置くことになるな、削減した後の頂点を送るから帯域は節約出来るがXDR側が窮屈になりそう。
頂点レベルのカリングをCPUでやるつもり?正気か? 頂点キャッシュの存在意義が無くなるね。
>>141 PPC970x3コアだと、PPEx3と違って一切言い訳が通用しないくらい、完全に実効性能でCellを上回るからな
必死なんだろ
対称型マルチコアというアプローチそれ自体はそんなにいいもんじゃないぞ。 3コアでは演算能力はシングルコアの2倍にも届かん。 SPEの妙味は、トランジスタを簡略化して8個も塔載したことと、キャッシュをLS+DMAにかえて プログラマがレイテンシを制御可能にしたところにある。
PPC970x3の発熱はもの凄いことになるだろうなあ それこそ扇風機だろうなあ 見てみたいなあ
PPC970x3コア を3.2GHzで出せるワケ無いだろう
箱○信者の必死さだけはものすごく伝わってくる
>>214 少なくとも先日のFFTのベンチのPowerPC970デュアル2.0GHzの結果から類推する限り、
PPEではなくPowerPC970コアだとしても、実効性能ではどう頑張ってCellには届きもしません。
対称型マルチコアに夢見る人って、PCのSMPやマルチコアなマシンのベンチマークとか知らないのかな?
αまでは駄々漏れだったのにβは漏れてこない件。 漏らすような所にはまだ渡ってない? それともαは意図的に漏らしてた?
今までの緩さのお陰で規制が厳しくなったんだとさ
>>219 FFTベンチは実アプリ、特にゲーム系については全く参考にならない
むしろベンチマーク性能に特化されていて、実際の性能はかなり低いとみるべき
証拠は俺のおいなりさんの中だ。
さらに言えば、現在のPC環境でマルチCPUの伸びが小さいのはOSがシングル環境に最適化されている事とCPUコア同士の連携が弱いため 360では、OS自体が3コアに最適化され、CPUコア同士の連携も完璧 こうなるとヘテロジーニアスよりホモジーニアスのほうが実効性能の面で有利になる
> CPUコア同士の連携も完璧 MSがここに何を用意したのか興味あるな。360 CPUの情報はほとんど明らかでない。 CPUからGPUに、L2キャッシュをFIFOバッファにしてデータを送り込む仕組みはMSの特許文書にあるらしいが。
【課題】共有メモリを用いた広帯域処理環境での効率的なマルチタスク処理方法および装置を提供する。 【解決手段】システムは、共有メモリと、共有メモリに接続され共有メモリの要求されたアドレスからデータを取り出し、 かつ共有メモリの要求されたアドレスにデータを書き込むように動作するメモリインタフェイスユニットと、 メモリインタフェイスと通信し、(i)メモリインタフェイスユニットに共有メモリの特定のアドレスのデータに対して データ上で任意の操作を実行するよう予約付きロードを命令し、 (ii)メモリインタフェイスユニットにデータを共有メモリの特定のアドレスにストアするよう命令する複数の処理ユニットとを含む。 処理ユニットの少なくとも1つは、予約消失の有無および共有メモリの特定アドレスのデータの更新の有無を示すステータスレジスタを含む。 特許みてたらSCEから出てた。
>>223 想定通りの連続データが、一定量づつ、同じ間隔で処理されるという状況は、ゲーム系処理では現実的ではない
そんな状況はベンチマークかムービー再製程度しか有り得ないだろう
>>228 メインメモリを介してCPUコア同士の連携をとるよりも、コア同士の連携、キャッシュ上での連携を行ったほうが有利なのは
PenDと64x2が証明している
MSはもっと知識のある工作員を雇うべきだと思う。
>>228 それCell用にとった特許だけど、結局やめたらしい。
日経読んでいれば分かると思うが、 ホモ系アーキテクチャーは性能がでないから 検討のすえ、ボツになった案だよ。
>>225 少なくとも現状のサーバー系のWindowsやUNIXのようなマルチコアに最適化されたOSでも
シングルコアに比べて性能をリニアに伸ばすことはできていないようだが。
>>229 データのバラツキがあってもダブルバッファをDMAで裏読みすればいいだけかと。
それにゲームと言えど処理を全部抜き出して個別に考慮してみれば、
十分予測・制御可能な流量のデータフロウになるでしょ。
>>233 サーバー系OSは機器の故障等を想定し、最悪シングルCPUでも稼動するようになっているため、本当の意味でのマルチCPU最適化はされていない
マイクロソフト自身がNT系OSのカスタムと明言しているのに、ナニ妄想を撒き散らしているんだ?
>>234 なんだか頭がくらくら来るような素敵理論キター。
>本当の意味でのマルチCPU最適化はされていない
その本当の意味でのマルチCPU最適化っていうのは何?一体何??
しかもそれはXbox360に搭載可能なんだよな?
どういう技術を指して言っているのか教えていただきたいのだが。
「マルチコア」でも連携は完璧 ↓ 「マルチコア」に最適化されてるサーバーでも「マルチコア」でリニアに性能アップしないのでは? ↓ いや、サーバーは「マルチCPU」の一部が壊れても動くようになっている よって、サーバーも「マルチCPU」には最適化されていない! そして、○の「マルチコア」の連携は最高!
>>234 >マルチCPU」の一部が壊れて
デュアルシステムとデュプレックスシステムの違いを認識していない?のは判りました。
○は”UMA”で、PS3は”NUMA”構造 UMAでは22.4GB/sをCPUとGPUとで折半 例えば CPU=10GB/s、GPU=12.4GB/sとか、CPU=5GB/s、GPU=17.4GB/sとか これを補うためにeDRAMが搭載されている ○CPUは読み書き共に10.8GB/sが上限。これはGPUのL2アクセスも含めての数字 なお、L2アクセスは、これをGPUから参照する場合 GPUから見れば 普通の「外部メモリアクセス」と同じであり、レイテンシはメインメモリ並みである まぁ一旦メインメモリに書き出すよりは速いが・・ しかも メモリコントローラがGPU側にあるので、CPUからのメモリアクセスはレイテンシが大きい NUMAでは22.4GB/s+25.6GB/s = 48GB/sをCPUとGPUとで折半 ただし、リモートメモリにアクセスせず、ローカルのメモリのみにアクセスする場合は レイテンシの面で速く、有利である 例えば CPU=25.6GB/s、GPU=22.4GB/sとか、CPU=10GB/s、GPU=38GB/sとか CPU=5GB/s、GPU=43GB/sとか、CPU=30GB/s、GPU=18GB/sとか 特に、CPU=10GB/sの場合、GPUの帯域は○の3倍に達する UMAと分離メモリの「いいとこ取り」をしたのが”NUMA”メモリ構造
242 :
名無しさん必死だな :2005/07/04(月) 12:45:48 ID:ysKlC2P3
ちょっとしたことでトリガーを引きやすいんだからまったく
GK暴れ杉(w スペック比較はマニュアルどおりにしか答えられないし、プログラミングの話になると理解の範囲を越えるので発狂するらしい。
・・・・を略さず書け
信者とかGKとか必死だなとかが好きな人はVSスレへどうぞ
難しいけど、それを克服するだけの果実はあるよな。 距離(レイテンシ)を制御し、通常以上のパフォーマンスを引き出す。 またしてもプログラマ泣かせな・・
・リモートメモリにアクセスするときのレイテンシ(256MBの壁) ・FlexIOの帯域制限 この辺につっこみどころがあるが、単純な帯域では勝負にならない。 あとは箱○にはeDRAMでどれくらいの帯域を節約できるか? パフォーマンスにどれくらい寄与するか? が不確定要素。
360のeDRAMは謎多いのね
Cellはベンチ公開、G70は姉妹チップがPC用に発売で、ある程度実像が見えてきたのに比べると、 360はまだCPUもGPUも謎が多い。性能が期待より高くても低くても隠す理由にはなるので、 今の時点ではなんとも。
期待してたよりパフォーマンスが高いことを隠すようなMSは嫌いだ。
そういや、xenonCPUの実物の写真も詳細なスペックも公開されてないな・・ 開発機には載ってるはずなのに。 IBMはCELLに関してはあれほどおおっぴらにしてるのに
>>256 CELLは外販するわけだし、360CPUは完全に360専用。
どーあがいてもCELLより上の数字が出せるわけでもないし、
公表する意味がないってとこだろうさ。
>>254 PS3、箱○ともに
不確定要素の方が多くて
「もう性能の順位は決定的!」
と言う書き込みのほうが胡散臭く感じる。
PS3って、Dsub15ピンのPCモニタ出力できる?
>>258 あくまで今出ている理論上の最高性能値を比べて優劣言うのはそれほど変でしょうか?
>>260 理論値議論することに箱○派は賛成する?
しばらく前から、このスレでの議論焦点は「実効値」だと思ったけど。
>>239 思ったより凄い技術なんだな→NUMA
両メモリへのアクセス時に生じるレイテンシを多少建言できる程度かと思ってた
建言→軽減 orz
「VRAM 512MBです」と nVIDIAのCEOがE3で言ってたしね。 実際にはそんなに使ったらメインメモリがw ただ、レイテンシは大きいだろうから 使い方には注意だな
RSXからXDRメモリへアクセスするレイテンシってどれくらいなんだろ? RSX->GDDR3) RSX->GDDR3 RSX->XDR) RSX->FlexIO->EIB->XDR EIBを通るレイテンシなんてメモリアクセスに比べればかなり低いはず。 後はFlexIOを通る時のレイテンシがどれくらいか次第?
>あくまで今出ている理論上の最高性能値を比べて優劣言うのはそれほど変でしょうか? 出てもいないハードで信者だなんだの熱くやり合うのが、実にゲハらしくて変ではありませんね #前回のPS2の時からなんら変わらない景色
267 :
名無しさん必死だな :2005/07/04(月) 15:42:51 ID:ysKlC2P3
そういえば、NvidiaがGPUで重要なのはレイテンシよりも帯域だと言ってたしね。
1.X360CPU⇔GPU[メモリコントローラー]⇔GDDR 2.Cell⇔FlexIO⇔GDDR って見ると、1と2のレイテンシは殆ど変わらんと思うが。
269 :
名無しさん必死だな :2005/07/04(月) 15:51:01 ID:XaGfSOvp
>>262 PS3においては、ただのAGPメモリじゃないかという意見も・・・。
○は zenon⇔GPU[メモリコントローラー]⇔GDDR なので、 Cell[メモリコントローラー]⇔XDR のPS3と比べて CPUのメインメモリアクセスは苦手のはず。 つまり、 ・3コアなのにL2は1MBだけ ・メインメモリはGPUの彼方でレイテンシ増加 ・そもそもCPUの帯域が上下 各10.8GB/sしかない の三重苦で、しかもそれを改善する仕組みが見当たらない。 ってことで、CellのGDDRアクセスは、 zenonのUMAアクセスと比べて 大して変わらないのでは?
重要なのは、RSX→バス→XDRなのでは?
CELLのDMA転送でも確かにレイテンシは生じるけれど それより大事なのはリングバスが4本独立してあると言う事だと思うんだけどなぁ。
リングバスのレイテンシか
274 :
名無しさん必死だな :2005/07/04(月) 16:23:16 ID:ysKlC2P3
RSXのXDRメモリ参照はレイテンシが大きすぎて実用に耐えないというのであれば 箱○のCPUの立場は・・・
277 :
名無しさん必死だな :2005/07/04(月) 16:37:49 ID:xLpxJC/K
>>274 そこでテッセレーションと自動生成ですよ。
俺は、「実は描画処理最大のネックは、Ztestだった!」説でも唱えとくかw
279 :
名無しさん必死だな :2005/07/04(月) 19:06:01 ID:9osOD63+
360のタイル分割レンダってどのくらいの大きさのタイルだと思う?
10MB近似値
何か本格的にネタが無くなって来てるような気がする。
283 :
名無しさん必死だな :2005/07/04(月) 21:33:55 ID:iwTTfnqa
>>282 のせいで誰も書かなくなってしまったのであった。
TGSまで膠着状態か あるいはそれまでに開発機情報のリークがあるか
>>283 てかほんとにネタがないわけだし仕方が無いだろうw
http://forum.rambus.co.jp/ 7月7日にコレともう一個なんかあった気がする。これで1日分ぐらいのネタは投下されるといいけどな・・・・・
あと360のジャパンサミットが7月に予定されていて、プレイステーションミーティングが7月にあるのではと噂されている
技術的な話が出てくるかどうかは怪しいが
質問だけど、SPEの7つのLSってNUMA構成なの? そうだとしたら1.75MBのL2cache並み帯域のローカル空間になって、できることが増えそう。 帯域関係は放置って怒られそうだけど…
7月7日は七夕。 統合シェーダー凄いかも。
>>287 じゃあDMAでお互いにアクセスできることと、NUMAであることの本質的違いってなに?
いや、だからSPEは他のSPEのLSを参照できんよ。
>>289 NUMAってのは別々のメモリプールがあるのにアドレスが一定になっているという
OSによる抽象化を指してるだけでしょ。全てのLSの空間に一様にアクセスする
ようなOSを作るか作らないかだけじゃないの。
292 :
名無しさん必死だな :2005/07/04(月) 23:40:25 ID:zT3ffGTu
今月の日経エレクトロニクスにCell開発環境について マルチコアスケジューリングやらスレッドプログラミングやらいろいろ書いてあった。 思ってたよりプログラミングしやすそうな印象だったり、 HW/SWの問題点は割と解消されている感じがした。 ちまちまスレッドを一つ一つ動かすようなやり方じゃなくて、 3種類のアルゴリズムで複数スレッド(SPEコア)をまとめて動かす感じか。 一度読んでみ。 ハードウェアでアルゴリズムに従って自動的にスレッドスケジューリングさせる方法と、 スレッド一つ一つ手作業でスケジューリングする方法では 前者の方が楽だし、チューニングも簡単そう。 Xbox360みたく2×3スレッドを手作業で1つ1つ操作するのは マルチコアプログラミングにあってないんじゃないか? XNAでその辺りサポートされてるような話を聞かないから、 知らないだけなのかもしれないけど。 知ってる人は突っ込み入れてください。
>>291 なるほど。
でもよく考えたらLSに他からアクセスしようとすると、LS全体をロックしなきゃいけない気がする。
あまり意味ないね。
>292 XNA のツールは、すべて個別に提供されており ベースのつながりがなかった、例外的なものである。
>>293 そんなこたなかろうよ。ポインタとサイズを取り決めとけば良いわけで。
DMAを使わなくても、その程度の直接小さなメッセージを送れるとかあったはずだし。
メインメモリを介さずにデータを送るのは帯域を考えれば非常に有効。
オンチップバス帯域は200GB/s以上もあるし。
>>295 いやLS外からのDMA自体を否定しているわけじゃなくて、NUMA的に使うのは意味ないかなと。
>DMAを使わなくても、その程度の直接小さなメッセージを送れるとかあったはずだし。
これはリアルタイムOSによくあるmailboxだね
日本の得意分野が発揮できそう
>>292 360の一般的開発手法では開発者はスレッドの分割やキャッシュ制御等、マルチコアを意識したコーディングは必要ないらしい
たいていのことはAPIとコンパイラでやってくれるそうだ
キャッシュ制御はともかく、スレッド分割は意識してやらないとマルチコアを有効活用 する事は難しいと思うんだが
ID:nW9WoVS4 → ID:LgeOHsHH
板垣もマルチスレッドが難しいといってる以上、
>>297 の話は嘘じゃねーの?
ヒント:このスレの大半の人間はド素人
自動並列化という手段はいろいろと開発されてるけど、普通は手動でやるでしょ。 ゲームプログラミングができるやつでスレッド分割できないやつなんていない気が。 せめてopenmp。
>これはリアルタイムOSによくあるmailboxだね そういやSPEごとにmailboxがあるってどっかに書いてあったね。 まあそんなもの意識せずプログラミング出来ると祈りたい所。
むしろ、L2をロックしたりFIFOとして使う箱○CPUは、通常のCPUよりはるかにキャッシュを 意識しないと、せっかくの機能を有効活用できないわけだが・・・ L2FIFOはGPUのAPIとして提供されるにしろ、ロックされた分ゲームロジック部分が使える 領域が減るのだから、相当注意しないとパフォーマンス劣化が凄い事になりそうだし
昨日のマルチコア専用OSの技術についても聞いてみたいし、 自動でやってくれるスレッド分割の技術も教えてほしいね。 そんな魔法のような技術があるなら是非とも。
ID:nW9WoVS4→ID:LgeOHsHHは誰も知らないワンダーでエキサイティングな ソフト開発技術を隠し持つゲイシの秘蔵っ子。
箱○のL2cacheミス時のストールは何clockか公開されてる? GPU側についてるから、相当大きそうな気がするんだけど。
>>292 >スレッド一つ一つ手作業でスケジューリングする方法
スレッドのスケジューリングはプライオリティ指定すればあとはOS任せなんだが。
>>305 >L2FIFOはGPUのAPIとして提供されるにしろ、ロックされた分ゲームロジック部分が使える
>領域が減るのだから
それは間違い、L2FIFOがもし無かった場合でも
L2は同じように汚染される。
ストリームデータをL2を飛ばして直接メインメモリに書き込むケースではその限りではないが
その手法も当然Xboxにも用意されているはず。
そろそろ、毎日 箱マンセー捏造してるIDのひとに、ニックネーム用意してもいいんじゃないか、イチイチ説明するのもなんだし。 箱陣営を貶めるためにやってるんじゃないかとすら思える言動だが。
>>311 節穴でもすれば
同時にGK疑惑も晴れて一石二鳥。
いや、ロックされた領域は他のCPUコア(スレッドかも)から活用出来なくなるので FIFOとして使用中はL2のサイズがロックされた領域分減った状態になる訳ですよ たとえばSPEのLSと同じ256KBロックされると、3コアで768KBのL2キャッシュのCPUに なるわけで、当然性能低下は免れませんよね ちなみに、L2飛ばしで書き込事は可能だと書かれてますね
>>313 長い間無駄にロックが継続されればその通りだけど
GPUに送られるデータの種類からみても
そうはならないと予想。
マルチスレッドにしなくても動きますが、しないとやばいと思います。 一番重要なのは3コアすべての稼働率を極限まで高めること。 出来る限りL2飛ばし型L1プリフェッチを使えるかに掛かっています。 (L1プリフェッチに成功すればL2の汚染は回避できるため。) マルチスレッド自体は難しくないです。まともなデバッカあるし。
>>315 X360開発者の人?ゲームプログラマに開放されてるのは2コアじゃないの?
>>316 性能搾り出すために残り1コアにも仕事を割り振らざるを得ないだろうな。
それでも、このままだと性能は
普通に作ってみたPS3>>必死に性能搾り出した箱○
になりかねない。
>>317 意地悪な書き方をするなよと。
CPUで使える帯域が同条件と仮定するなら
仕事の種類によっては、360CPUの方が上のケースも多いし。
(SPEは得手不得手がハッキリしてる)
どっちも、ハイにスペック使ったゲームが出るのは何年後だろうな それまで待つか
まぁ否定したい気持ちはわかるけどもね
結局ココもvsスレか アホクセ
>>317 大体、そういう考えが理解出来ない。
マルチコアプログラミングって、ゲームのような短い(例えば17msよりかなり短い)時間で
処理するような用途ではないのでは?
そういう実例自体、まだ世に出てないわけだし。
互いに競合しない(してももっとレスポンスが遅くても大丈夫なもの)向けなんじゃないの?
ゲームで言えば、MMOのサーバーとの送受信とか。
マルチコア重要説唱えてる奴は、擬似コードでもいいから、どういったものを想定してるか書いてみてよ。
>>318 > CPUで使える帯域が同条件と仮定するなら
そんな仮定に何の意味があんの?
しかしPS3って箱360に性能で勝てるのかね デモですら箱360のゲームに負けてるけど
現実は厳しいのさ
CPUはコア辺りの帯域の狭さ、メモリの同期を取れないSPE等のバランスの悪さの為に実効性能で負け GPUはPC向けの流用の為、ゲーム機向けに新規設計&最適化された360GPUに素で負ける まあ、同時期の発売ならともかく、半年〜一年遅れなのを考えると、かなりぶざま。
IDぐらい変えたほうがいいと思うよ
329 :
名無しさん必死だな :2005/07/05(火) 09:59:30 ID:GY6+fU9C
本日のID>ID:LgeOHsHH
>>327 >CPUはコア辺りの帯域の狭さ
Xbox360 CPUの問題点を指摘してどうするのw
CPUはコア辺りの帯域の狭さなんてたいして問題にならない なぜならPen4でもFSB1066と800ではほとんど性能の違いはないし もちろんPenMでも違いは少ない そんなこといったらFSBだけ上げてメモリは同期しなくても かなり速度が上がることになる 問題はキャッシュの速度やキャッシュ量
332 :
名無しさん必死だな :2005/07/05(火) 10:27:02 ID:7S64UNzY
>問題はキャッシュの速度やキャッシュ量 Xbox360 CPUの問題点を指摘してどうするのw
>>331 しかしAthronのモデルNoとかみるとL2キャッシュ倍(512KB→1M)でも
クロック1割分程度の性能差ってことじゃねぇの?
キャッシュに過大な幻想をいだくのもいかがなものかと思うが
Athronは1Mの奴のキャッシュが遅いからだろ Pen4 6xxもしかり socket478XEなんかは結構パフォーマンスが上がった
>>333 そりゃCPUによってキャッシュの大きさがまちまちなPCの世界において取られた
ベンチマークと、キャッシュの大きさが事前に分かっているコンソールの世界
の場合とを比べても仕方が無かろう。あとAth"l"onね
337 :
名無しさん必死だな :2005/07/05(火) 11:34:36 ID:5EuCqylm
>>313 3コアで768kb(1コア256kb)じゃなくて、2コアで768kb(1コア384kb)メモリ帯域の細いPCでも256kbもあればCPUの性能は十分発揮出来るよ。
君が期待しているほど性能低下はないですから、残念だったね(w
仮に1コア256kbでもAthlonXPのサラブレッドようなCPUであれば 性能低下なんてあんまりないしな ゲーム用途だけならそんなに必要ないんでしょ 初代箱だって128kbでもあれだけがんばっていたことだし
PPEを例えるならAthlonじゃなくてPentium4系のがいい気がする
PPEはPen3に近い
>>334 Pen4が遅かったのはパイプラインが長すぎてキャッシュアクセスのレイテンシが長くなったからじゃなかったっけ。
キャッシュの容量を増やし過ぎるとデーターを探すのに時間がかかってパフォーマンスか伸びなくなるけどね。
>>341 Pen4が遅かったのは、
1、一部の計算命令が遅い
2、2命令までしか同時実行できない
という要因が大きいのではないかと。
Pen4というとネットバーストということで、パイプラインの長さが
性能低下の槍玉に挙げられがちだが、
そもそも上記2要因のせいで生のスループットが下がってることを
忘れてはいけない。
>>337 ロックした領域はその領域をFIFOとして使うコアからもL2キャッシュとしては使えないので
1コアあたり256kBで正しいと思いますが
ロックされた領域はキャッシュとしてではなく、メインメモリよりもCPUに近い一時バッファ
になってしまうわけですから
ところで、箱○CPUのL2のレイテンシや駆動クロック等スペックって詳細でてましたっけ? 駆動クロックはたぶんCPUコアと等速なんでしょうけど、FIFOやロックといったロジックが 追加されてる分、レイテンシがそれなりに大きいのじゃないかと予想してるんですが
FIFOもロックも、そんなご大層なものではなかろう。普通にL2キャッシュの速度で動くと 思われる。 キャッシュというのは一種のまやかしなので、256KBで十分でもあるし、6MBでも足りないのだが、 3コア6スレッドで1MBというのは、ピーク性能を重視するゲーム機っぽい割り切りの結果かなあと思う。
あれ? 360のβ開発機って、先月すでに配布されてたって話では?
>>346 同じIBM製でも、実効性能重視で当時としては贅沢に
1コア256KBキャッシュ積んだGCのGekkoとは全く逆だけどねえ。
>>348 おいらもそんな記事を見かけたが
はて?
真相は闇の中。 CPUが遅れてるのかな。発売予定まで5ヶ月というところなんだが。
取材をするメーカーによって一ヶ月くらいの情報の誤差は 出てくるんじゃないの?
確かにあった βを優先的に回してもらえるサードと、そうでないサードとかがあったんじゃないか?
ベータキットは国内メーカーにも先月届いてまっせ
あれこれ想像するより先月配布されたってソースを貼るのが一番早いぞ。
> Prior to E3, developers reported that a very small number of these more > advanced kits had been manufactured, but it's only in recent weeks that they > have begun shipping to Microsoft's development partners on a wide scale. E3の前からもごくわずかに出荷して、大々的に配ったのは"recent weeks"らしい。 やっぱ6月中の話ということでいいのか。 で、開発機に関する具体的なリークは何も無しですか。 αより性能上がってるのは当たり前だしなあ。
ベータに移行した開発者のブログあるけどここには貼りたくないっすわ
358 :
名無しさん必死だな :2005/07/05(火) 14:53:38 ID:sPDSPnxK
E3直後だと、箱○はほどんどαキットの所ばっかじゃないかな。 そりゃPS3のαキットと比べれば非力だわな。
貼らなくてもなんていってるかだけわかればいいよ
361 :
名無しさん必死だな :2005/07/05(火) 14:55:13 ID:5PDsgEP8
この時期ってタダなんだろ?アリカじゃもらえないわけだなw
GF6800 Ultra塔載したPowerMac G5 DualってAppleのハイエンド機なんだが、 それでも非力なのかねえ。怖い時代になったもんだ。
問題はベータkitでさえファイナルバージョンではないという件について。 発売まであと5ヶ月しかないというのに完成品のチップが無いって大丈夫か?
チップ自体は量産試作品で、クロックが本番より多少低いとか、その程度の違いじゃね?
365 :
名無しさん必死だな :2005/07/05(火) 15:42:53 ID:VoJBxerp
>>363 βキットに搭載されているチップのソースは?
チップの製造がPS3のCellやRSXよりも遅れているので、βキットの配布が 遅れたと書いてあるな。ということは、クリスマスシーズン発売はます ます怪しくなってきたな
11月だよ 発売は 日本は12月 間に合うでしょ
368 :
名無しさん必死だな :2005/07/05(火) 15:53:20 ID:5PDsgEP8
無理やり一年はやめてぶつけてきたXBOXが年内出ないのなら大笑いだな
>>364 もしかして、βキットがそのままファイナルバージョンに為るかもしれない・・・?
>>365 いや
>>347 を読んだだけ。
少なくとも予定通りならチップの試験生産ラインには入っていなければならないので
歩留まりを考慮しても開発機程度の数なら製品版と同等のチップが採れてないとおか
しいだろう、と。
ATI is currently revamping the chip design of its R520, said the makers, adding that the company is facing leakage issues, as it attempts to migrates its manufacturing to a 90nm process. >ATIの技術者が語ったところによると、ATIは現在R520のデザインをやり >直してる最中らしい。さらに、90nmプロセス製造への移行の試みにとも >なって、ATIは目下のところ、リーク電流の問題に直面しているとも語っ >た。 R520が一四半期発売がずれ込むとすると、当然その双子のGPUである Xenosも一四半期ずれ込む可能性が高いな。すると、今年11月発売 予定の箱○は来年2月発売になる可能性は十分ありうるな。Xenosは R520よりさらに消費電力を低減しないといけないわけだし、R520より さらに製造上の問題点の克服すべきところは多そうだ。 R520同様、XeCPUとXenosも開発遅れて、ベータキット配布が数ヶ月遅れか。 順繰りに遅れると、箱○の発売日は、来年2月になるな。
PS3も開発キットからして春はあやしいな サードもソフト開発が全然進んでなさそう 来年の今頃だろ
まさかレポが最先発?
>>366 360や347の記事にはそんなこと書いてないと思うが…
R520とxenosはほとんど関係がない
>>371 360GPUはR500、そのアーキのPC晩はR600
>>371 願望入りまくってるのが手に取るように見えるw
R500ならSM4.0対応だな
>>359 ベータ届いた。移行作業。シェーダバグ。直し。…等など。
以前から2行程度で淡々と書いてるから大胆なリークはないよ。
ちなみにMSKKの記事だと、7月ジャパンサミット、9月TGSでプレイアブル出展、11月試遊台を店舗に設置
といったスケジュールらしい。
いい加減、真実を認めようよ。 箱○は開発がPS3より遅れている。 リーク電流の問題で、CPU、GPUともようやく試作チップが出てきたレベル。 しかし、歩留まりが悪く、量産のめどが立っていない。 M$内では、今年発売は絶望視されているが、サードにはまだ秘密にさ れていて、9月くらいに情報が開示される予定。いまばらすと、サード が一斉に反発して、開発ラインをPS3にシフトするので、言うに言えない。 どうせ、こんなところでしょ?
PS3の開発キットは100台程度に対して箱○は3000台、どちらの歩留まりがいいかは一目瞭然なんだが。 配布する数の桁が違うのに遅れてるぞー!ゴルァっていってもなんだかなぁって感じだよ。
それがソニー信者クオリティ
箱○のαキットは、G5+nVIDIAの6800SLIでしょ。
なんでCPUにリーク電流の問題が絡むんだ? cellのほうがよっぽどヤバいと思うが なんせ2.4Gだからねwwww
VSスレへどうぞ。
>>381 3,000台って10台づつ配っても300社なんだが?
β開発キットってそんなに大盤振る舞いするものなのか?
そこでゲイツマネーですよw
300社って十分すぎないか?
1社に10台も配らないよ
http://www.geocities.jp/andosprocinfo/wadai05/20050522.htm >ISSCC2005の発表論文から推測すると,3.2GHz動作なら1.1V強の
>電源電圧で動かせそうであり,SPEの消費電力は4W程度でしょう。
>チップ全体の電力は,これが7個とPowerPCとI/Oインタフェース
>などで70〜80W程度ではないでしょうか。かなりの電力ですが,
>Pentium 4の上位よりは小さく,XboxのXenonよりも小さいので
>はないかと思います。
Cellより電力大食いのXeCPU。おまけに、TSMCは90nmプロセスで
のリーク電流対策に手こずっている。そりゃ、製品版がCellより
登場が遅れるわけだ。。。
スクエニ様に見捨てられたゴミ箱360なんかに興味ありません スクエニ様の敵は俺の敵だ、MSと痴漢は俺の敵 ゴミ箱360クッセー、痴漢死ね死ね、PS3とレボ頑張れ
Cellもリーク電力でてこずりそうだな
Cellはいくらでもクロックと使用SPE数落せるから無問題
394 :
名無しさん必死だな :2005/07/05(火) 16:26:20 ID:bUuOcuMU
それ推測じゃん。なんで断定してのかね?
395 :
名無しさん必死だな :2005/07/05(火) 16:27:50 ID:g+XDPN0b
脳内革命がおこったからだね
397 :
名無しさん必死だな :2005/07/05(火) 16:29:46 ID:5PDsgEP8
CELLは4GHzまで出てんだよ
じゃなんで開発機が2.4Gなんだ
GPUが430MHzだから
>>.398 CPUだけでコンピュータにならないから。NUMAメモリとかその他のPS3の構造をある程度 再現していないといけない。その辺の問題だろう。Macで代わりのきく構造じゃないからね。 Cellは実際に4GHz以上で動くのは確実だし。
PS3のβキット配布が今年3月。箱○のβキット配布が6〜7月初旬。およ そ4ヶ月遅れか。このままのペースで行くと、箱○の発売はPS3より3, 4ヶ月遅れて、来年夏くらいになりそうだね。
ID:zUzWZuAQ見苦しいぞ
FayHXUU/は箱信者が、開発機は実機より性能悪くて当たり前だ! って言ってたの知らないのか。 今の箱の開発キットだって、ファイナルバージョンに近いってだけで 性能は悪いと言われてるのにw
もうαキット上で動いていたなら あとはチューニングだけだろ そんなものは一ヶ月もかからない
>>404 スーパーカイハツシャハケーンwwwwww
開発機はいつ配られたってソフトメーカーが頑張るだけだろ。 ソフト買う側の俺としてはどうでもいい。 それよりはXbox360の実機の方が心配。
CPUはともかくGPUの現物は載ってるのかな。 試作テープアウト物でもなんでもとにかく載せとかないとそろそろやばい時期だと思うんだが。
PS3は実機相当で動くゲーム画面がほとんどでてないので 開発なんてロクに進んでない
何で信者って出るわけ? その文字使いたければVSスレ行けば良いじゃん
R500は消費電力も歩留まりも良好
>>407 >なんでもとにかく載せとかないとそろそろやばい時期
そうなの?
なんか、PSPがヤバイヤバイ言われてても結局なんだかんだで出てきたから、
素人考えには結構実機無しでも行けるんじゃないかと思ってしまう。
PSPってどんなスケジュールだったっけ?
箱丸は発売日は守ると思うよ。先行販売が最大の優先事項だから。 でも、歩留まり悪くて台数は揃えられず、そう、DCのような状態なると思うな。
初代X箱の時は、発売当時にはすでに同性能のCPU、GPUが登場していたか ら、いわばPCパーツの流用みたいな感じだったが、箱○はPCにもないよう な高性能チップを搭載してくる。当初の予定では、昨年末にR500の試作チ ップを搭載したβキットが配られるはずだったけど、半年スケジュールが ずれ込んできている。これはやばいね。
PSPはファイナルが7月くらいだったかなぁ。
90nm問題なんてどこの会社もすぐ 克服した。 intelも早い段階で北米で克服した品を 出してたし。
>>413 既存のアーキテクチャの延長線上にある機械なら直前でも良いんだろうけど、
xenosはほぼ完全に新アーキテクチャでしょ。
各種の挙動をつかむことからして時間がかかる。
ローンチソフトが悲惨な出来だとXBOXの二の舞というのが現実化しかねない。
これに対してPS3の方は順調だと思うんだな。cellも7800も現物がすでにあるから
ある程度シビアな使い方まで追い込める。発売まで1年近くあるのに。
>>417 すぐ克服できるとしたらR520が春から秋にまで延びる事はないよw
開発画面さえでてこないPS3のどこが順調とも? 開発環境でも雲泥の差がありそうだ
OpenGLのライブラリは貧弱 これでどうやってまともなシェーダーを 描画するのやら。
>>417 ソースは?
Intelは未だに苦しんでるようだが。
プレスコットもPentiumDもあれだけの発熱・電気食いだし、
PentiumMすら消費電力が結構上がってるしな。
423 :
名無しさん必死だな :2005/07/05(火) 17:26:25 ID:7S64UNzY
Xenos(R500)はトランジスタ数が小さくダイサイズも小さいので R520よりも、製造に苦労しないと思われる。 β開発キットでは、Xenosその物が乗っているのでは CPUもIBMだから大丈夫かと
cellも発熱や消費電力には苦労してそうだ あのデカいケースにでさえ2.4Gの石しか詰め込められな かったからな あとRSXも90nm
みんな大事なことをわすれていないか? 360GPUにはあの会社がついていることを! つNEC なんだtt(AAry
http://spurluxe.jugem.cc/?eid=487 >Penstarsys.com
>
>この記事によると、R520はかなり歩留まりが悪いのかもしれない。
>全部で32パイプ構成なのはご存知のとおりだが、
>32パイプで動くチップは現在までのところほとんど無いようだ。
>24パイプで動けば"ラッキー"で、大部分は16パイプでしか動かないという。
>またR520はリーク電流の問題も抱えているらしい。
32パイプのR520がほとんどとれないないのなら、48パイプのXenosは
絶望的だね。
32本ってピクセルパイプの事でしょ。 Xenosの48本はバーテックスパイプ相当だから トランジスタも少ないしもっと楽だと思う。
CellとRSXと同コアのG70は既に存在している訳ですよ。PS3発売の一年前に。 ソフト開発者から見ればこれは明らかにありがたい事です。 一方、X360はまだCPUもGPUも完成しているのか判らない。発売まで半年なのに。 GPUも新しいアーキテクチャで動作の癖掴むのにも時間がない。 ローンチソフトの出来はだいじょうーぶか?という疑問が出るのは不思議ではないですよね。
430 :
名無しさん必死だな :2005/07/05(火) 17:41:27 ID:7S64UNzY
>>427 Xenosでいう48パイプはR520でいう24パイプに相当する
つか、PSPの時のスケジュール引用したら駄目駄目でしょう。 PSPの出荷数って未だに300万台とかそんな程度で、据え置きハードで世界同発なら、 発売日にそれだけの台数揃ってないと駄目な数。 つまり(無理矢理)PSPのスケジュールから逆算すれば、PSPは去年の12月発売じゃなくて 今年の5月〜6月頃に発売って事になってしまう訳で、360だと来年夏になってまう。 流石にそれは無いだろうし、許されないと。
箱○のGPUはNECのUX6で作られる R520とは無関係。 ヤバいならもうすでに情報がでているだろ?
NECはGCも作ってたな GCも発売延期してたけど、これもNECのせいって事は無いよな
>>421 シェーダーを描画か・・・DirectXでもサポートされてなさそうだw
レボにもeDRAM搭載されるかも・・
Revolution - CPU PPC970FX 2.5GHz * 4 - GPU ATI R520 eDRAM 16 MB 700MHz - MEM 512 MB + 32 MB PPU - Panasonic Blu-ray Disc Drive 4x Speed + 8cm DVD Xbox 360 - CPU PPC970FX 3GHz * 3 - GPU ATI R500 eDRAM 10MB 500MHz - MEM 256-512 MB - DVD Disk Drive 12x Speed PlayStation 3 - CPU STI Cell Broadband Engine Processor 2.6GHz - GPU Nvidia G70 400MHz - MEM 128-256MB - Sony Blu-ray Disc Drive 2x Speed E3前に流れていたスペックだが、これ当たってたな。 ということはレボの性能はやっぱり凄そうだ。
G70は110nm
>>437 90nmプロセス量産半年遅くていいPS3になに言ってるんですか?
あなたの好きな箱丸の心配しておいた方がいいですヨw
>>436 このレベルを当たっていると言っていいならこの板住民全員の予想が当たってると思う。
箱丸のGPUはNECが作るのか
>>441 eDRAMのドーターダイだけのはずです。特許の関係とか?
GKと痴漢が必死になるスレはここでつか?
>>440 Revolution
- CPU PPC970FX 2.5GHz * 4
- GPU ATI R520 eDRAM 16 MB 700MHz
- MEM 512 MB + 32 MB PPU
- Panasonic Blu-ray Disc Drive 4x Speed + 8cm DVD
Xbox 360
- CPU PPC970FX 3GHz * 3 ←ほぼビンゴ
- GPU ATI R500 eDRAM 10MB 500MHz ←アタリ
- MEM 256-512 MB ←アタリ
- DVD Disk Drive 12x Speed ←アタリ
PlayStation 3
- CPU STI Cell Broadband Engine Processor 2.6GHz ←開発機は2.4 アタリ
- GPU Nvidia G70 400MHz ←G70(430MHz)=RSX アタリ
- MEM 128-256MB ←アタリ
- Sony Blu-ray Disc Drive 2x Speed ←アタリ
7800GTはFX57でも性能でないってな つまり地雷の予感があると
言ったもん勝ちだな(笑
nvidiaなんて負け組みと組んでもなwwww
マジレスするとATIのどこが勝ち組みなんだ?
Xbox 360 - CPU PPC970FX 3GHz * 3 ←ハズレ - GPU ATI R500 eDRAM 10MB 500MHz ←アタリ - MEM 256-512 MB ←そりゃどっちかだろ - DVD Disk Drive 12x Speed ←アタリ PlayStation 3 - CPU STI Cell Broadband Engine Processor 2.6GHz ←開発機は2.4だがそれもハズレ - GPU Nvidia G70 400MHz ←G70(430MHz)=RSX ハズレ - MEM 128-256MB ←ハズレ - Sony Blu-ray Disc Drive 2x Speed ←アタリ
nVIDIAのイメージはintelに近い 爆熱、電力食い、低性能 最近は改善してきたようだが・・・
>>451 SCEとnvidiaが契約したのは去年になってからだ
ATIをMSと任天堂に取られていたからCELLベースのGPUが無理と分かってから
契約できそうな会社はMSから干されたnvidiaのみ
PS3では箱のどす黒いグラフィックも再現してくれるだろうなwwww
>>454 G70も負荷時は馬鹿みたいに消費電力上がってるし。
>>455 RSXはSCE工場で作るよ。アナログの出力はnVIDIA画質にはならないんだな。
MSはもっとましな工作員をやとったらどうだ? まともに議論するつもりもなければ、ただ荒らしてるだけ。
単発IDの工作が酷いな
vsスレで思う存分やってくれ、ここはテクノロジースレだ
>>457 無駄だよ
発色なんてそのメーカー色座標で計算するんだから
それにしてもβ開発キットが気になるな どういう構成なんだろう。G70使ってたら笑うな
つーか、それ以前にPS3の標準はアナログのAVマルチではなく、HDMIでは?
β開発キットでも実機の性能に達してない
GCはいいマシンだったけどね あの大きさで静音 性能も悪くなかったけどね
実はβでもう実機の性能に達してるんだけど、そんなこと怖くて言えない…だったりして。
CPUに関して言えば、扱い方が違うといえど CELLの方が確実に柔軟性があって高性能。 IBMからしたって掛けた金額が全く違うんだからな。 GPUに関してはXBOXのチップ裁判等々で ATIにMSが乗り換えるのは目に見えていたから 組むんならnvidiaと決まっていたと思う。 ただ契約が遅かった分、実際には どれほどGPUの性能が違う(引き出せる)か分からんね。 言えるのは、MSと違ってシュリンクする気満々のSCEIは 恐ろしく柔軟な契約をしてるっぽいから次世代機に繋ぐ橋はPS3の方が強い。
Xenosはβ開発キットにもうすでに搭載されてるようだな ただしCPUは2コアだったっけ?
> Xenosはβ開発キットにもうすでに搭載されてるようだな > ただしCPUは2コアだったっけ? いや、β開発機の中身についてまだなにも情報ないと思うけど。ただこの時期なら すでに製品とほぼ同じものを積んでるだろう、というだけで。
Cellは分岐予測の使えないSPE 7コアと汎用コア1つだから、使い方が難しいだろうな。 RSXにいたってはG70の流用で、しかもビデオメモリ帯域はG70より低め。 コアは550Mhzと謳っているが、クロック低下の常習犯であるSCEがどこまで守れるやら。
>>471 用語だけ並べても中身分かってないからボロ出まくり
G70なんてもう発売してるから しかも安いところではもう3万円台
PS3が叩かれると即効で潰しにかかるよなここ
というか叩くほうがあんまりにもレベルが低いからな・・・・ いつもいつも・・・・・
>>474 間違ってると「ちがいますよ」という親切な人がたくさんいるんです
>>473 > しかも安いところではもう3万円台
マジっすか!買ってくるんで場所のヒントplz
>>471 嘘をまき散らす人はVSスレで頑張ったほうがいいよ。
>Cellは分岐予測の使えないSPE 7コアと汎用コア1つだから、使い方が難しいだろうな。
Xbox360 CPUは分岐予測あるの?ソースよろ。
あと、分岐予測は必ずしも必要ないし、
パイプラインの深さや分岐予測の有無でCPUの使い方変わるわけじゃないしな。
>しかもビデオメモリ帯域はG70より低め。
その代わりにCPUとGPUの接続帯域が遥かに太く、しかもNUMA構成なんだが。
>クロック低下の常習犯であるSCEがどこまで守れるやら。
PSPが222MHzリミットを持っていた以外で、
何かクロック低下に該当するような事例あったっけ?
現行機でスペック発表時からクロックが下がってないのはPS2だけだったりするんだけどね。
むしろ箱1が直前にクロック削減してるんだが。
PS3は小手先の技術の塊 もうまさにPC+α そんなんで性能が出ると思うほうが どうにかしている それとlinuxの糞なレイヤー
EEは逆にクロック上がったしな。 というかCELLかRSXあがらないかしら(笑
なんでMS側の擁護は、単発IDばかりなんだろう。 数レスしても、すぐにボコボコにレス返されて消えちゃうし。 聞いちゃダメかw
>>482 Cellは興味深いが、RSXは小手先・・・というかブルートフォースではあるな。
Xenosは興味深いが、Xbox360 CPUは小手先の技術以外の何物でもない。
君の観点で言うならどちらもPC+αに該当するし、そうでもないとも言えるどうでもいい話だ
。
Linuxの糞なレイヤーというのはどのあたりがどう糞かを述べて欲しい。
PS3のゲームで必ずしもLinuxを積むわけではないわけだが・・・。
PSPは出てからクロック低下が判明しました つかこのスレの反応みると普通にVSスレだよな
小手先の技術 って、お前さんはPS3の詳細を良く知ってるようだな。 俺が小手先かどうか判断してやるから、スペック晒せ。
NUMA自体が小手先の技術
>>488 正しくは、PSPはクロック低下じゃない。
最初から
1〜333MHzとあったからな。
最新技術の塊であるX○は高性能、かつコストは安い。 PS3は小手先の技術で低性能、しかもコストは高い。 なんか無理ないか?
>Xenon PowerPC Processing Element details >L1 cache: 32K instructions/32K data >Two-issue superscalar execution >In-order execution >Two-way simultaneous multithreading って事でXBOX360のコアもPPC970というよりCellのPPEに近いようだね
>>474 PS3以外の機種でも変だと突っ込み入ってるのは見えませんか?
http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/3 読んでみたが、これは公式な情報ではないようだが。
>メニーコア構成だとCPUはメチャ帯域食うと言われてるな。
22.4GB/sを3コアCPUとGPUで共有しなければならないXbox360に対して、
PS3はCellの25.6GB/sとRSXの22.4GB/sが独立して存在するので、
帯域勝負ならどちらに軍配が上がるのかは明白だが。
またいつも通り10MBの小さなeDRAMを持ち出してみるのかな?
> クタも似たようなこと言ってる。
文脈が違うと思うけどね。
eDRAMの是非を論じる中で出てきた発言でしょ?
でもたしかにeDRAMの効果がどれほどのものかまだ予想できない。 UMA+eDRAMというのはコストパフォーマンスとしては悪くないものだし。 G70のFSAAがいくら効率よくてもノーコストというわけにはいってないしね>G70ベンチ
>CPUからXDRメインメモリへの帯域は25.6GB/secあるが、 >結局、GPUからメインメモリへのレンダリングは上りバス帯域の >15GB/secに制限されてここがボトルネックとなってしまう。 >CPUからXDRメインメモリへの帯域は25.6GB/secあるが、 >結局、GPUからメインメモリへのレンダリングは上りバス帯域の >15GB/secに制限されてここがボトルネックとなってしまう。 >CPUからXDRメインメモリへの帯域は25.6GB/secあるが、 >結局、GPUからメインメモリへのレンダリングは上りバス帯域の >15GB/secに制限されてここがボトルネックとなってしまう。 ソニ信の最大限に都合よく解釈する癖はいつになったら直るんだろう?
GPU+CPU足して22.4GB/sよりかははるかにましかと・・・
>>499 それは後藤がまだPS3がNUMA採用してるとは知らない時期に勝手な予想で書いた記事ですよ。
>>496 ttp://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm >とりあえず2つのメニイコアの実装を見ていえることは、性能を確保するためには
>広帯域なキャッシュ/メモリが必要とされるということである。
Cellの25.6GB/sは十分なのか不十分なのか、まだ不明だと思うけどな。
>>497 そもそも独立しているメモリ帯域は単純に足しても意味が無いことが分かってるのかな。
並んで接続してるわけじゃないんだから、アクセスする場所によって速度もレイテンシも変わる。
片方が余って、片方が足りない場合、双方がフルスピードでアクセス出来るわけじゃない。
アンチエイリアスやHDRなどを使った場合、フレームバッファは非常に多くのビデオメモリ帯域を
占めると言われているが、eDRAMはその点にフォーカスした作りになってる。
単純な比較は困難だろうな。RSXの22.4GBという帯域はPCグラフィックと比べると少ないのは事実。
eDRAMの用途 MSAA HDRレンダリングするときのFSAA フレームバッファ Zバッファ
>CPUからXDRメインメモリへの帯域は25.6GB/secあるが、 >結局、GPUからメインメモリへのレンダリングは上りバス帯域の >15GB/secに制限されてここがボトルネックとなってしまう。 何故にRSXからXDRにレンダリングせにゃならんのだろう? 痴漢の最大限に都合よく解釈する癖はいつになったら直るんだろう
>>498 >UMA+eDRAMというのはコストパフォーマンスとしては悪くないものだし。
eDRAMにバックバッファが収まる間はね。
MSが推奨しているD4,FSAAでは、分割レンダリングが発生するんで
22.4GB/sの帯域を再消費しなければならない。
eDRAMからメインメモリへの転送コストも無視できない。
(その間は描画も止まる)
つまり、事実上FSAAノーコストと言って良いのは、D2表示以下の時だけ。
ついでに、NVIDIAは5年以上前からeDRAMアプローチを否定してきた。
(上記のような欠点があるから)
現実にD4、FSAAノーコストと言っている だからこそ標準対応
MSは全画面フルシーンFSAAを強要しているのか?
>>502 >Cellの25.6GB/sは十分なのか不十分なのか、まだ不明だと思うけどな。
Cellで足りなりないなら、より帯域を無駄に消費するXbox360CPUは
アウトですよ。22.4GB/sを使いきったら、GPUへ頂点もテクスチャも送れません。
ほんとヤベーな信者
eDRAMに収まらない、 VRAMを消費するGPU処理ってどんなのがあるの? その処理は、仮にCPUが10GB/s消費してたら、残り12.4GB/sでやりくりしなきゃならないんでそ 間に合うの?
現行のPC、Dual channel DDR2-400でも6.4GB/secだから、 それほどパワフルではない360 CPUは10GB/secも使い切れないと思う。 むしろ25.6GB/secあって、「XDRの帯域がボトルネックになるかも?」とか言われちゃう Cellが化け物。ありえない。
>>507 2xFSAAで(ほぼ)ノーコスト、4xFSAAで2xの時の95%のパフォーマンスとATi開発者が
発言しています
4xのときはノーコストじゃありません
>>508 強要しています、
D4、4x強制なのか2xでもOKなのかは不明だがFSAA対応が必須と発表されてます
>メニイコアの実装を見ていえることは、性能を確保するためには広帯域な >キャッシュ/メモリが必要とされるということである。 とりあえずメイニイコアが通常より帯域を無駄遣いすることは動かせない事実 そしてCellはそれで大丈夫なのかという問いかけをとにかく問答無用で 一刀両断しようとする、これはいったい何かね?
>>513 2xでもOと言う書き込みも有った
ソースは2chだけど。
>>499 ふーん。正確に書くとしようか?
RSX<->GDDR3:読み書き合計22.4GB/s
RSX<->Cell:読み書き合計35GB/s(RSX->Cell:15GB/s, RSX<-Cell:20GB/s)
合計すれば57.4GB/sになる。
Cell<->XDRは25.6GB/sではあるが、SPEで伸長・展開処理を行う事により、
XDRへのアクセスを越えるデータをRSXに送る事は可能。
まあ実際の所は、RSX->Cellというデータ転送はさほど発生せずに、
主にCell->RSXの20GB/sを使うことになるだろうけどね。
>>502 勿論単純な足し算ではいけないし、メモリ配置を考慮しなければならないのは確かだが、
XDR->RSXの転送においては問題になりにくい。レイテンシよりも帯域重視なバースト転送主体だろうからね。
それ以前にXbox360ではCPUの分、22.4GB/sから引き算しなければならない事を意図的に忘れてないか?
しかも君が指摘するようにマルチコアでは帯域を奪い合う。大丈夫なのか?
Cellには合計256kB*7のLSがあり、
>>496 で指摘されてるようにアーキテクチャがそもそも違うわけだが。
帯域争いは不毛だよ。 帯域どおりの結果になったためしがない。 ここだとUMAが安いだけの技術になっちまうしな。
マルチコアで帯域を奪い合うなら X2はあんなに性能を発揮できなかったはず
>>514 性能の為に必要な帯域に無駄?
必要帯域が増えないままで性能だけ上がる技術があると?
SPEがLSで処理したデータを、 一旦メモリに書き出さずに、直接RSXに送り込める?
とりあえずお前らゲーム作ってみようぜ どうせPSレベルのショボイのしか出来ないだろけど
>>513 それはコピーコストのみの計算では?
再ジオメトリ処理や再頂点、テクチャ転送まで含まれてないでしょ。
(実際にはこっちの方がネックになるわけで)
>>514 もし、帯域がネックになるなら、フルに使わなければ良いじゃんw
どんな使い方をしても、常に25.6GB/s必要だとでも思ってたの?
PS3のCELLとRSXの組み合わせが最強だということは分かった。 でも弱点というかそういうのはないの?
Cell → RSX が20GB/sなのはわかるけど、 どうして RSX → Cell が15GB/sもあるの? RSXで処理したデータがそんなに大量にCellに行くの?
>>523 たぶんそうでしょう、実際どれだけ低下がおきるかはソフト次第かと
HDR使用すると分割数も増えるので、さらに低下するでしょうし
>>524 まずその一行目の理解からしておかしいだろうね
>>514 Cellは帯域を必要とするメガブロックFFTでも優れた性能を発揮したわけだが。
確かにXDRの帯域がもっとあれば、さらに性能はよくなってたんだろうけどね。
メモリがボトルネックであったと言ってたし。
これでもまだ何かあるというなら、せめてXbox360 CPUがCellよりも
コストパフォーマンス(演算力/帯域)が高いというソースが欲しい所だけど。
>>520 出来ないと思う理由は?
XDRとFlexIOはEIBのそれぞれ反対側にあるわけだけど一旦XDRを経由する仕様なの?
>>525 RSXでXDRメモリにレンダリングする時に使うんでしょ。
バックバッファもXDRに置けるそうだし。
>>524 CELLの一番の弱点はプログラムへの環境が構築出来るまでにある程度時間と労力が必要と言う事では?
>>525 メモリが分断されてしまってるから行かざるをえない
>>509 コア構成が違うんだから比較にならないだろう。
CellはXDRを使ってまでメモリ帯域を確保したところから見て、
実装コストを掛けるだけの根拠があったのだろう。
メモリは少ないほうが安くつくし。
>>523 テクスチャなんて送らないぞ。
そんなもの送ってたら10MBではとても足らない。
フレームバッファを送って各種ピクセル処理、Z処理等を施して送り返すだけ。
フレームバッファに関するメモリ帯域の消費を抑えるメリットもある。
360のeDRAMはPS2みたいな普通のVRAM的使い方をするのでは無く、
帯域を食う処理を外に出した感じ。
PS3はHDR使うときFSAAをかけられない
360のeDRAMみたことないだろ? CPUのとなりにくっついてんだぞ ただのメモリとはわけが違う
>>534 んなわけない MSAAは確かに無理だけどな。
つまり、RSXで処理したデータをCellが参照して 再度 処理を加えるような形が想定されてるの? その場合、CellがGDDRから読むの? それともRSXが、処理したあと、GDDRでは無く、XDRに書き出すの?
どうにもこうにも、PS3はよく考えられてるな 流石にPS2の仕様から反省したか ま、PS2は本業でないCPUやGPU周りを全部自分たちでやったことに意味があるんだろうけど
PS3は全然反省してないだろ。 PS2の成功で勘違いした標準搭載BDと PS2の失敗で反省してない後付HDDじゃねーか。 頼むから反省してくれ。
>>533 >コア構成が違うんだから比較にならないだろう。
PPE3コアだと問題なくて、PPE+SPE8コアだから問題だとでも?
だから、もう少しSPEの構造を調べろっての。
>CellはXDRを使ってまでメモリ帯域を確保したところから見て、
>実装コストを掛けるだけの根拠があったのだろう。
>メモリは少ないほうが安くつくし。
これは、あなたの推測に過ぎんわけで。
ライバル機より性能を高くするための選択とは考えられない?
>テクスチャなんて送らないぞ。
>そんなもの送ってたら10MBではとても足らない。
eDRAMにテクスチャ置くなんて書いてないし。
分割レンダリングの意味理解してる?
ピクセルシェーダのテクスチャ参照と言えば理解出来るか?
まぁ・・・ そんな広い基盤でも無いし・・ CPUの隣、と言えなくも無い。
GPUコアの隣の間違いだろ 一見してDRAMには見えない
>>542 >>ライバル機より性能を高くするための選択とは考えられない?
それを言うならATI+MSはUMA 22.4GBでライバル機より性能を高くできると判断したと考えられないか?
少なくともCellにはGDDR3と同程度のコストと言われるXDRを4つ載せてる。
それだけで馬鹿にならないわけだが、盲目になって見えてないか。
Tiled Renderingで720p,4x FSAAのパフォーマンスは2x FSAA時の95%だとATIは言っている。
開発者の言葉を否定するなよ。
Killzoneはプリレンダだったのか・・・orz
Killzoneはリアルタイム。 日本の高名なジャーナリストがそういっているんだから間違いない。
5fpsの
>>547 「ハイパープレイステーション」のインタビュー記事
途中送信しちまったorz 「ハイパープレイステーション」のインタビュー記事でSCEの平井(?)という人が 「Killzoneなどのプリダレンダは実現したい目標。」 と言っている
また変なの来たな・・・ GT4素材をそのまま使ってHDレンダリングしただけの物と比べられても・・・
SCEA社長兼CEOの平井氏ですね。 blog書き直しましたよ。 もうどっちが本当なのか・・・orz (って多分、SCEのトップが言うんだからそっちが正しいんでしょうけど。) 本田氏が間違えたってことは、実機でプリレンダ流してて、 聞いても回答が(英語で)相当微妙な言い回しだったんでしょうねぇ
ID:LgeOHsHHはワンダーマンチキン。
>>545 >CellはXDRを使ってまでメモリ帯域を確保したところから見て、
>実装コストを掛けるだけの根拠があったのだろう。
>メモリは少ないほうが安くつくし。
>ライバル機より性能を高くするための選択とは考えられない?
これは、あなたの一方的な推測の仕方に対して反駁として書いたもの。
そうとも考えられないか?という問いかけに、同じ問いかけを返されても困る。
いたちごっこ。
>Tiled Renderingで720p,4x FSAAのパフォーマンスは2x FSAA時の95%だとATIは言っている。
>開発者の言葉を否定するなよ。
http://www.beyond3d.com/articles/xenos/index.php?p=05 元の文には、分割レンダリングで生じる全てのコストを含めて
算出されたとは書かれてないぞ。よく読め。
第一、それなら95%という具体的な数字は出せないだろうな。
(フレームごとに帯域消費量も演算量も違うから)
最初に、その数字を出した
>>526 さんも、その点は理解してるじゃん。
本田の記事は偏見だらけ
nvidiaは本当にGT5のような現実的な発色 箱1でも本当にそれをよく感じた 対してATIは幻想的な発色 ゴッサム3もちょっとHDRきかぜ過ぎだと思うが
おまえら帯域がホント好きなんだねえ。 帯域なんて、ちょっと足りないくらいでちょうどいいの。
GPUはレイテンシより帯域が重要、 RSXがCELL経由でXDRを使うのは十分現実的・・・ その為のCELL-RSX間の極太帯域 SCEとNvidiaがXDR、GDDR3に対し512MBの領域を透過的にアクセス しVRAMとして使えるようにしたと言っているんだがな・・ スペックはハッタリかましても仕様まではハッタリかまさないでしょう。 というかこれを認めないと、箱○のCPUの立場はどうなるねん・・ CPUこそGPUよりレイテンシが重要なのに・・。 箱○のCPUは Xenos経由でメインメモリに ア ク セ ス で き な い ん で す か? そこのところ矛盾しているんだが、お前らは・・。
同じメモリ容量なんだから、誰が見たって 帯域広い方が性能高いでしょ。 UMAでCPUとGPUが食い合う22.4GBより、 CPUとGPUそれぞれが独立して25.6/22.4GB使えて、 なおかつ相互にアクセスできる方が誰が見たって 性能が高いと思うが。一部の信者を除けば。
eDRAMが全てを逆転するらしい。。
統合シェーダーや固定シェーダーなんかを議論したほうが まだマシだと思う
かつて68000というCPUは、そのアドレッシングの対称性の高さゆえに愛されました。 技術者は対称性を愛するのです。 CellとRSXの関係もまた、そのような愛から生まれたのでしょう。
CellベースのGPUって統合シェーダーだったんだろうな。 やってほしかったな。。
>>561 アフォか、Xenos経由でメインメモリにアクセスできる。
RSXはCELL経由でXDRメモリにアクセスすして演算するには無理がある
CELLとRSXからのアクセスがXDRに集中するのは効率的に良くないからね。
それに外部プロセッサー経由をレイテンシが発生する。
少しは勉強しろよGK
>>563 これすごいよな。Cellだけでの描写はあっているがリアルタイムではなかったはず。
PS3は効率が悪い せっかくGPUも128bitで台無し
俺、頭おかしくなったのか? 569の発言を読むとなんか矛盾しているような気がするのだが・・
>>567 画像サイズやHDRの有無の違い、それにGatewayはE3の時点でリアルタイムで
動いていた物で、その画像は最近公開された物と違いが多すぎるので、
単純に画像だけ見て比べても意味無いかと
>>570 カメラをコントローラーで動かしてたと思いましたが、勘違いかな
360CPUはXenos経由でGDDR3メモリにアクセスすして演算するには無理がある 360CPUとXenosからのアクセスがGDDR3に集中するのは効率的に良くないからね。 それに外部プロセッサー経由をレイテンシが発生する。
>>569 >RSXはCELL経由でXDRメモリにアクセスすして演算するには無理がある
>CELLとRSXからのアクセスがXDRに集中するのは効率的に良くないからね。
>それに外部プロセッサー経由をレイテンシが発生する。
↓
>xenonCPUはXENOS経由でGDDRメモリにアクセスすして演算するには無理がある
>xenonCPUとXENOSからのアクセスがGDDRに集中するのは効率的に良くないからね。
>それに外部プロセッサー経由をレイテンシが発生する。
・Cell・・・・・・・・・・・ Cell[内蔵メモリコントローラ] ⇔ XDR(原則 排他使用)
・xenonCPU・・・・・・xenonCPU ⇔ XENOS[内蔵メモリコントーラ] ⇔ GDDR(常時 UMA共用)
XENOSにはeDRAMというアクセス是正策があるが、xenonCPUには特に無い。
なんでこう痴漢って低レベルなんだろう、 この帯域の話題をテンプレにでもしてくれ、 ループは嫌だ。 箱信者PS3帯域について攻撃 ↓ 箱○の構成をその論法に当てはめると自爆
Xbox360は効率が悪い せっかくGPUもUMA 128bitで台無し
>>567 リアルに見えるのは写真をべた張りしてるから。
eDRAMと統合Shaderの優位性だけを語ってりゃいいものを・・・
箱○統合シェーダーで128bitでも安心 さらにeDRAMでもっと安心
箱はメイニーコアじゃないからね
>>576 RSXがCellと連携するのは、256MBを越えるサイズのメモリをNUMAとして使う場合か、
SPEの演算能力を使いたい場合に使う物でしょ?
それで25.6GB/sのXDRの帯域を全部使い切るわけではないでしょ。
つか、背景なんて光源位置が変わるわけでもないんだから、写真そのままで破綻も無いんだよな。
PS3は XDR-I/O-Cell-I/O-I/O-シェーダ-I/O-GDDR3 360は GDDR3-I/O-CPU-I/O \ / I/O-GPU これなら、どちらが効率的な構造か一目でわかるだろう
幼稚園児でもわかることなのになにGKは必死に なってるんだ?
とりあえずGF6800UltraのSLIではGears of warは10フレ出ない そしてRSXがGF6800UltraのSLIと同等以下 もうわかるな?
ちがうだろ 360は GDDR3-I/O-GPU-I/O-I/O-CPU
360のGears of warがどこまで劣化するか楽しみだな
ATI関係者が「実機では60fpsで動く」と断言してるし 実際に実機に及ばないと言われるβ開発機ですら40fpsが出たと、 開発者自身が海外のゲーム雑誌のインタビューに応えている
メモリ帯域とパイプライン数をひっくり返す程Xenosのアーキテクチャー が優れているのなら、最高級GPUのR520に採用されてるってw ってかR520買う気うせるわ・・ あと家庭用機はハード専用の最適化できるからな PCと比べて比較するのは少し無理があるかもな・・
だから帯域はスレ違いだって。
>>1 にも書いてあるだろ
チップ内部バスをどう扱うかだな XBOX360の場合GPUの内部にメモリロジックのクロスバーがあるけれども、 これだって内部バスな訳で、CellのEIBをI/Oと扱うならこっちもI/Oとして扱わなければ おかしい もちろんレイテンシや帯域の差はあるけれどね
7800GXTなんて買ってみりゃいいじゃん もう性能なんて一目でわかるだろう G80が統合シェーダーだったならG70は なんていわれるだろう・・
7800GXTもR520も買うやつは馬鹿
R520はSM2.0+α なんか見劣りするよな
>>591 毎度のことで悪いが・・
ソースください。
>>591 で、それで?
所詮そこらへんは現時点の開発機の性能、ゲームの完成具合によるものに過ぎない。
単純に性能の比較が出来るものではない。発売時期も違うというのに。
そもそも
>実際に実機に及ばないと言われるβ開発機
実際にどういうスペックかわからないから全く判断材料にならないし、
発売まで半年を切ってる現時点で未だ実機に及ばないというのは、
スケジュール的に微妙かと思われるのだが。
自作板じゃベンチマークだけの地雷扱い>GF7800GTX しかも肝心のベンチマークさえまともに差が現れるのは、 お遊び扱いされている、ゆめりあベンチだけ
発売時期はあんま変わらないよな PS3が北米で遅くなるだけで
FlexIOとEIBはクロック高そうだし、そんなにレイテンシでかく無さそう。
一応発売時期は半年ほどの違いがあるのだが
この板に長くいるが
>>591 がいう話は初めて聞いたのだが・・
Gears of warはCPUがボルネックになっていないのかな・・
それならβ開発機で飛躍的に伸びたのも分かるような気がする。
>>600 ゆめりあベンチは完全にGPU依存のベンチなので
ネタあつかいするなよ
Longhornは関係ない
シェーダー性能 PS3:400GFLOPS XBOX360:240GFLOPS すまんがこの差とてもアーキテクチャー云々で ひっくり返せないような気がするのだが、
地雷GPUはどうひっくり返っても 性能UPなんか望めない。
>>608 そもそも地雷だと決め付けてる基準が曖昧なことについて
>>608 箱のもな・・しかもUMAというオマケつき
地雷どころか、R520は遅れに遅れてるのでそもそも比較できないしな。
シェーダー性能なんて指標が曖昧すぎるな やっぱり実機で動かしてみないことにはわからないな HL2はRadeon推奨だし
PS3のように固定機能まで計算に入れると、360はeDRAMのロジック部を足さなくても500Gflopsを超えるんだが
WGFはWindowsの話で、ゲーム機には関係無し。 統合シェーダを採用するかは、実行性能との兼ね合い。 性能が出なければ、統合シェーダの出番無し 数値だけなら RSXの「ピクセルシェーダ」の演算性能は XENOSの「統合シェーダ」の演算性能より ずっと高い。 頂点シェーダは、現在PCでも余り気味で、それほど問題は無い。 もちろん、eDRAMとかがあるから、XENOSがダメとか不利とか いうことは直ちには言えない。
>>605 G70はベンチの際にCPUがボトルネックになっていると言われていたが、
ゆめりあベンチで高い結果が出ると言うのはそういうことなのか。
360はR520じゃないだろ
>>613 固定機能は計算に入ってませんがナニカ?
どこの部分が固定機能なんですかね?
そしてその500GFLOPSとやらの
残り260GFLOPS分がどこにあたるのか教えてくれ
>>613 ID:LgeOHsHHがいつもの人のIDか。
シェーダー性能
PS3:400GFLOPS
XBOX360:240GFLOPS
これはフルプログラマブル部分だけしかカウントしてない。残念。
固定機能勝負は既にやってるだろ。 XENOS・・・・・1Tflops RSX・・・・・・・・2Tflops チップ内部の全ての固定機能を加算したらこうなる。 プログラマブルシェーダ部分は 400 vs 240
ちょっと疑問なんだけど、ATIって何でそんなに素敵な性能で量産もうまくいきそうなR500をPC用に投入しないの? eDRAMないと糞なのかなぁ。
>>615 逆にFFベンチ等はCPU依存度が高め
だと言う声は自作板で良く聞く。
R600で投入の予定
あーあーまた、俺たちGKの勝利で終わったか・・・。 きんもちいい!!
>>622 いや、R520でつまづいてるんでしょ。
R500のほうがずっと高性能っぽくて生産もうまくいってるってのになんでかなぁと思って。
計画どおりに順番に出してかないといかん物なの?
固定機能勝負(ハッタリ合戦) XENOS・・・・・1Tflops - 115Gflops(CPU) - 240(shader) = 645Gflops RSX・・・・・・・・2Tflops - 218Gflops(CPU) - 400(shader) = 1382Gflops
626 :
名無しさん必死だな :2005/07/05(火) 22:57:32 ID:WSkqbPwF
>>614 頂点シェーダーは今のところ水面の波紋やキャラクターの関節などの限定的な使われ方しかしていないから足りているだけで、ディスプレーストマップなどを使いだすと全然足りない。
PS3は時代遅れなバンプマップしか使わないからいいのかもしれんが(w
627 :
名無しさん必死だな :2005/07/05(火) 22:58:21 ID:sBh+Fsu1
>>624 G70が目も当てられない地雷だったんで、
省電力化のために再設計する余裕ができたんよ
>>626 ディスプレイスはCPU側で計算しても問題ないわけだが。
>>628 違うの?当たり前のように語られてるからそう思ったんだけど。
違うんなら意味のない質問でした、すいません。
631 :
名無しさん必死だな :2005/07/05(火) 23:13:24 ID:siDuKHkS
>>628 β開発機でシェーダーを書き変えているという話だからGPUは載せ変えたみたいだね。
>>626 RSXは頂点シェーダに44Gflops使える。
これで足りないということは、50〜80Gflopsくらい使うの?
でもXENOSのシェーダ演算性能は240Gflopsしか無いので
残りは200Gflops以下。 ピクセルシェーダ性能が全く足りなくなるよ?
RSXはピクセルシェーダだけで356Gflopsあるし。
あと、CellはSPEでもテッセレーション出来るけど、xenonCPUじゃ無理でしょ
XENOSは48シェーダ:240Gflopsで頂点処理した次のクロックで 48シェーダ:240Gflopsでピクセル処理ができるんだよ。
635 :
名無しさん必死だな :2005/07/05(火) 23:23:43 ID:sBh+Fsu1
48シェーダ:240Gflopsの演算性能。 これなら満足か?
XenosはeDRAM容量の関係で分割レンダリングが必須だから、 頂点シェーディング能力はRSXの数倍が必要。テクスチャフェッチの帯域も数倍が必要。 単純なピクセルフィルはeDRAMのおかげで高速だろうけどね…。
だからeDRAMの用途が特殊だとあれだけ言われてまだなお・・・
>>633 RSXは8シェーダ:44Gflopsで頂点処理し、同時に24シェーダ:356Gflopsでピクセル処理した次のクロックで
やはり 44Gflopsで頂点処理し、同時に24シェーダ:356Gflopsでピクセル処理できるんだよ
てか、Flopsの"ps"は"PerSecond"だぞw
サイクルじゃない。
君の計算だと、ピクセルシェーダ処理は 2クロックで XENOSが240、RSXが712 になるぞ。
頂点処理とピクセル処理は並列処理がされることは 現実的用途じゃほとんどないってATI幹部が言ってるだろうに
>>637 おそらく、分割レンダリング時に無駄な頂点演算処理を減らすような
機構くらいはあるんじゃないかな?
(スクリーン座標内に収まったポリゴンの演算結果は保持しとくとか)
なんであろうとATIの幹部が95%の落ち込みって言ってんだろ
>>638 用途が特殊って何よ?Z処理やAA処理を行うロジック付きeDRAMは、
単純なピクセルフィルレートを上げるには有効だけれど、
頂点シェードやテクスチャ付きピクセルシェードなどの演算には寄与しないでしょ。
mata hanasi wo motikaesita
eDRAMのおかげでテクスチャフェッチやモデルリストのロードなどGPUコアの負担がなくなってんだよな。 そう憤らなくてももうすぐ発売だから買って確認しなさいな。
>>638 >だからeDRAMの用途が特殊だとあれだけ言われてまだなお・・・
eDRAMの用途が特殊と言うより
eDRAMチップ(3Dmemory)に備わってる機能が特殊なのでは?
(MSAA処理やトーンマッピング?などがeDRAMチップで可能)
用途に関しては、バックバッファとして使うのが主かと。
http://www.beyond3d.com/articles/xenos/ テクスチャユニットにも繋がってないようだし。
何か追加技術情報があるなら、是非教えて下さいな。
eDRAMの容量で何かに不備が出ることは無い単純に+しかないよ
>>640 パイプラインってことば知ってる?
ついでにいうとATIの幹部が言っているのは
シーンにおいて
頂点高負荷時はピクセルも高負荷になるような
シーンは無い(逆の例もしかり)といっているだけであって
並列とかそういう話ではない
>>645 公開されているブロック図を見ると、eDRAMはレンダリングターゲット専用で、
eDRAMからのテクスチャフェッチやジオメトリリードはできないようだけど?
>>649 ああ、逆っすよ。
eDRAMでメモリアクセスの重い処理を受け持って、コアではテクスチャフェチなどのピクセル処理。
もう箱のeDRAMはなんちゃらユニットと違う名称で呼んだ方がいいんじゃないか eDRAMなんて言うから勘違いするやつが出る
また、出鱈目君か。
箱○のeDRAMは初期の頃のディスプレイ側についてたメモリに近いのでは?
>>650 テクスチャフェチの方がGDDR3からのレイテンシ大きいんじゃないの?
>>640 言ってねーよ。
頂点処理とピクセル処理は並列処理がされるのは当たり前だろ。
そうしないとスピードが出ない。
まさかピクセル処理してるとき、頂点シェーダ止まってると思ってんのか?
つか、じゃ、頂点シェーダはいつ動けばいいんだよ?
頂点処理 → ピクセル処理 ってパイプライン構造なんだから、
これまでボトルネックになってた処理を速めれば性能アップにも繋がる。
統合シェーダもそのための構造だろ。
>>650 コアの負担の軽減というより、VRAMバスの負担の軽減ね。
テクスチャやジオメトリはUMAでCPUとシェアするメインラムに置くわけだから、
そうしないとCPUの処理の足を引っ張るからまずいわけだけど。
6800SLIで10fpsか こりゃRSXにも期待しないほうがいいな
>>649 テクスチャーやジオメトリはGDDR3から読み込む。
ただしテクスチャーはビットマップだけでなくGPUで生成したプロシージャル
テクスチャーも使うし、ジオメトリも読み出しはローポリゴンでディスプレー
ストマップやインスタンスで細かいレンダリングを行いeDRAMのポスト処理に
回すという流れになる。
661 :
名無しさん必死だな :2005/07/05(火) 23:55:07 ID:pUATjyJy
>>655 レイテンシ隠蔽のために今回のGPUのシェーダ構造には工夫がある。
>>657 そうそう。帯域の軽減ね。それとカリング。
UMA512MBだからテクスチャデータをフルに使おうとすればフェッチ割合がでかくなって
FSAAやZに帯域使ってられないってのもあんだろね。
その気になればHDDも仮想メモリとして 使えるぞ
お前ら同じ話を一体何度繰り返せば気が済むのかと
アホがこのスレに流れ着く以上、それは避けられない運命
>>663 帯域なんて十分足りてるって
問題はレイテンシー
>>663 HDDぐらいの転送速度じゃたいした負荷でもないだろ。
今HDDってどれぐらいだっけ?転送速度。133MB/s?
>>666 やっぱそっちか。。。
マチガイ スマソ orz
使い方によっては仮想メモリとしても使えるということだろ 死体が残るとか壊したものが残るとか
>>1 が何故 帯域の話を禁じたかを知らないのか・・
普通にチップの帯域の話をするぶんには
かまわないんだよ
だからと言って HDDがすぐにそのスピードを出せるわけでは無いんだろう?
>>641 その分割レンダリングを考慮したアーキテクチャの情報がでていないのが気になる。
ブロック図を見ても、PowerVRのタイリングアクセラレーションのような機構も、
頂点シェーディング結果を保持するためにメインメモリに書き戻すような仕組みもないし。
単純に同じディスプレイリストを描画枠だけを変えて数回にわたって描き直せというだけなら、ATIに幻滅するが。
RSXはもうほとんど情報が出尽くした。 問題はxenosことR500だな。 いったいどんなGPUが想像がつかん。
>>667 >>672 転送速度は民生用のSATA2で3Gbpsの物が既に出ているが、ディスクに読み書きする
速度の制限で2.5インチのハイエンドモデルで80MB/s弱が最大値
実際には、ディスク上の位置によって速度が変わる&ファイルシステムのオーバーヘッド
があるので、実用上だと20〜30MB/sが限度
もうnvdiaの社員が7800ベースと言っちゃってるんだな
>>674 基本はそれ、もちろんなるべく無駄は省くように工夫されているが
このスレの過去ログに推測されるXenosのレンダリング方法が書いてある
箱には分割処理用のハードウェア(というかロジック)は存在します。 たしかに負荷無しではありませんが、これによって得られるメリットが大きすぎるので、 文句は無いかと。 全体的に見て箱GPUは、かなり練りこまれたアーキテクチャをもってます。 αキットのX850とは根本的にものが違います。
>>677 ああ、初めてそこ読んだとき器の小さいおれなんかは感動したよ。
ゲーム機でここまでやる時代なんだなと。
>>681 具体的に機構を書いてくれ。
テクノロジスレーで煙にまくような発言なんていらないから。
統合シェーダーが練りこまれたアーキーなのは分かるが、 前例が無いだけに、プレイアブルが出るまで妄想の幅が広すぎて大変だ。
>>685 そうそう。そこらへんどうなんだろうなと思うね。
失敗か成功かなんだろうけど成功なら並以上の恩恵がある可能性もあるんだよな。
板垣氏はその答えを知っててあのインタビューをしたのだろうか。
αキットからβキットまでの性能の上がり方はどう説明できるんだろ
>>685 本格的WGF2.0世代GPUに備えた実験段階に見えなくもない。
枯れてない技術を大事な場面で投入されるのは怖いな。
90nmに手こずってる様子を見るとなおさら。
箱1もまさに実験段階だった nVIDIAの・・ 結果は・・・
ATiのFx16っていいね、48dbのダイナミックレンジがとれるみたい。
>>687 その辺のZ-onlyパスとかの推測は分からなくもないけど、どうも現実性に欠ける気がする。
すべての描画コマンドにタイルチェックのタグを付けてメインメモリに送り返すとしたら、
テッセレータやディスプレースメントマッピング適用後のジオメトリはものすごい量になるはず。バッファ量的にも帯域的も負荷が高い。
D4解像度4xAAで画面の3分割が必要だとしたら、その膨れたコマンドストリームを3度も読まなければならないし、
プリZテストでカリングが効いてピクセルシェーダ負荷が抑制されたとしても、テクスチャデータを3度読まなければならないのは変わらないし。
そもそも分割レンダリングの時点で、フィードバック型のブラー処理とかはかなり辛いわけだけど。
最初の1回目はZ深度をeDRAMの階層バッファに書き込んでタイリングとタグ付け。 テッセレータとかそれ以上のことはここではやってないはず。 2度目に遮断物に隠れていないような処理の必要があるものだけを eDRAMの対象タイルバッファに頂点処理→ピクセル処理で格納。 じゃないの? 既出しまくりかも。
695 :
名無しさん必死だな :2005/07/06(水) 01:48:29 ID:UUJYanqg
>>692 αキットの2.6倍程度。
αキットで実機の30%の性能と言われていたので、βキットは実機の78%ぐらいの性能と
いうことになる。
βキットではGPUが変更になっているので、これのせいか?
>>693 >そもそも分割レンダリングの時点で、フィードバック型のブラー処理とかは
>かなり辛いわけだけど。
モーションブラーとMSAA処理(ついでにHDRも)を併せて使いたい人は
eDRAM側のMSAA処理機能は使わずに、自前でピクセルシェーダ使って
実装しそうだけどね。(的外れならスマン)
>>695 ソース欲しいな。
それとも、695さんとこのベンチ結果?
Pen4 3.6G積んでたのはどのキットだったんだろ?
>>694 テッセレータとかのモデル形状が変化する処理は、当然スクリーン上の位置やZ値も変わってくるから、
最初のZパス前に処理しておかなければ駄目のはず。ようするに頂点シェーダー全般だけど。
>694 タイリングでタグ付け、の時点でポリゴン分割されて無いといかんので、テッセレータはこの時点ですんでいると思う。 まあ、>693のテクスチャー3回読みは激しく謎だけど、それ以外は間違っていないんじゃない? ○のeDRAMがフィードバックエフェクトにめちゃくちゃ弱いのは構成的に明らかだし、タイリングアーキテクチャが半透明のかさねあわせで効果が出ないのはDCの例を見ればわかる。 ○のeDRAMの使いどころは大量の不透明ポリゴンをいっぺんに描くときだと思う。
仮に映像面で同等だとしても CPUでは圧倒的な差があるから 高度な物理演算やAI等ではPS3が遥かに上回るんだよね。
1920x1080って解像度はゲームに使うには実用的じゃない気がするのだけど、RSXなら超余裕なの? なんか1920x1080を2画面って話も出てるし。
704 :
名無しさん必死だな :2005/07/06(水) 02:02:01 ID:UUJYanqg
>>693 ディスプレースメントマッピングはインスタンスで参照しながらやるので
フレーム内のオブジェクト全部のジオメトリを持つ必要は無い。
オブジェクト毎にテッセレーションして描き込む事も出来るよ、CGアプリでは
当たり前にやってる処理です。
インスタンスという単語の意味が判らない人が多いので説明しておくと
鳥の大群など同じ形状のオブジェクトすべてのジオメトリを持つのは無駄なので
位置情報だけのオブジェクトを作って、参照オブジェクト(この場合は鳥)を
もとに直接フレームバッファーに描き込んでいく(ジオメトリデータは存在しない)
この場合テッセレーションするのは参照オブジェクトだけでいいのでZバッファーに
描き込むオブジェクトの出番が回ってきた時だけポリゴン分割すればいいです。
ビルとか森などいろいろ応用出来る技術です。
705 :
701 :2005/07/06(水) 02:02:06 ID:XlttkCxH
>701 かぶったし…
706 :
705 :2005/07/06(水) 02:02:38 ID:XlttkCxH
>700だし…
>>695 現在のPS3のベータ(アルファ?)キットって実機の何%なんだろう?
もうG70ベースってのは決まりだし、CPUの性能も3.2に上がるだけだとすると、
なんか360の方が実機は性能よさげな気がするが。
しかもあげてるし…orz
>>703 そんなゲーム絶対出ないから安心しろ。
PSPつないでサブモニタ代わりにする便乗商法に使うだけ。
高度なAIで298人www あと箱○の開発機はhabox搭載
>>707 メモリ帯域やFlexIOの帯域など圧倒的に違うけどね。
>>702 映像面(具体的に何を指すのか不明だけど)ではPS3が上回るんじゃない?。
逆に高度な物理演算やAIは
>>702 がSPE活用した疑似コードでも書かないと「遥かに上回る」って誰も信じないと思うよ。
っていうか比較するだけならVSスレの方が良いのでは?
713 :
710 :2005/07/06(水) 02:07:32 ID:w3otbY/5
havok○ habox×
>>710 havok(だよな?)が箱タイトルは無料で使える?
ソースは?
>>700 なるほど。となるとテッセレータする場合は・・・
1.GPUでテッセレータしたデータをメモリに格納。全て用意が出来た後にZオンリー→ピクセル処理。
2.テッセレータしながらZオンリーしてデータは破棄。その後再度必要なデータだけテッセレータ→ピクセル処理。
3.CPUでテッセレータしたものをメモリに格納。それらを拾ってZオンリー→ピクセル処理。
>>701 ってことならば上の場合の1か3かな。
透過ポリゴンは弱いんだ?
ATIの階層型バッファにはそこらへんの処理も考慮されているってだけで効率は悪いのかな。
>あと箱○の開発機はhabox搭載 ソフトウェアを機材に搭載とはこれいかに? まさかファームウェアに!
>704 >963の言ってることはそういうことじゃないと思う。 タイルレンダリングで、タイルごとにポリゴンのタグ付けするならテッセレータで分割してなきゃならんってことです。 バンプマップのように大元のポリゴン(インスタンス)の形状を維持したまま内部だけ分割するなら>704の通りですが、それじゃポリゴン分割の意味が失われるのでは?
>>701 画面を3分割して、位置を変えて始めから3回描き直すから、当然テクスチャも3回読むはず。テクスチャキャッシュは有限だし。
>>704 ここでは実際にピクセル(Z値)を描くことについて話しているので、ポリゴン分割はしなくてはならないわけで。
テクスチャキャッシュってタイル1枚分でも入れ替えしなきゃいけないんじゃない? 容量全然ないイメージなんですけど。
Havok SDK 3.0が標準かしらないが 使えるらしい。ソースはどこかの英語サイト もちろんもうそれを使ったタイトルも開発中らしい
現在のPS3のβキット状況 CPU 75%(2.4/3.2) GPU 78%(430/550) CPU-GPUバス 5%(2/35)
723 :
701 :2005/07/06(水) 02:19:53 ID:XlttkCxH
>719 3回(3倍?)テクスチャーを読まなきゃならないのは、3分割されたバッファそれぞれに同じポリゴンが書かれた場合だけのはず。 (理論的には。実際は描画内容とキャッシュ効率のバランスしだいでしょうが)
725 :
名無しさん必死だな :2005/07/06(水) 02:25:53 ID:UUJYanqg
>>697 −698
Gears of war のフレームレートから算出した値。
αキットで15フレーム、βキットで40フレーム出ているそうなので
>>592 参照。
>>707 こっちはよく判らない、CPUは2.4GHzで実機の75%、GPUが81%以下で帯域は
1/20なので実機よりかなり低い上SPEをあまり使っていないらしいので。
>>723 3回テクスチャを読むというよりは
テクスチャキャッシュのヒット率の問題ですね。
分割することで、どれだけ損してるのかという。
ただ、頂点リードと頂点演算に関しては、結果を保持する以外は
避けようがない。
>>723 実際には1モデルに大きなテクスチャが何枚かマップされてたりするのだから、
そのモデルがバッファ間をまたがなければいい、ということになるけれど、
普通にまたぐでしょ、建物とか。キャッシュはテクスチャ1枚分もないんじゃないかな。
>>725 >Gears of war のフレームレートから算出した値。
なるほどね。
プログラムが同一で、開発機がGPUだけ交換されたと仮定すれば
推測の根拠にはなりますね。
ただ、CPUやバスまで変更された場合は
元のプログラムのネック要因が解らないので、何とも言えませんが。
>727 だから、理論的には、って書いたんですよ。 実際、分割しなくても何度も読み直す場合も多いわけですし、分割してもキャッシュに乗ってれば読まないわけで。
730 :
723,729 :2005/07/06(水) 02:38:25 ID:XlttkCxH
>723修正 同じポリゴン>同じメッシュ の方がしっくりくる?
>>725 ・フレーム数というのは、リニアに性能が反映するとは限らない。
・開発が進んでソフトウェア的に改善された分増えたfpsは?
性能を求める根拠としては薄いと言わざるを得ない。
732 :
730 :2005/07/06(水) 02:39:53 ID:XlttkCxH
がぁ〜またあげてしまった。今日はもう寝ます。
>>729 分割レンダリングしていたら、キャッシュに載っているということはないでしょ。
1024x1024x32bitの普通のテクスチャ1枚でも4MB。
圧縮してもノーマルマップとかスペキュラマップとかマルチレイヤは当たり前だし。
同程度のトランジスタ数のCPUでも4MBキャッシュとかありえないし。
>>728 単純にβキットのボトルネックが解消されただけ、と言う線は?。
たとえばソフトウェアエミュレーションされていたGPUの機能が実
装されたとか。
fpsの増加と性能の増加には相かnうおなにおするやめろl;:fkgbdss:;:ssf::aals
>>735 まあ,相関関係はあるでしょうね.当たり前の話です.
>>733 >分割レンダリングしていたら、キャッシュに載っているということはないでしょ。
テクスチャキャッシュは雀の涙サイズですからねぇ。
後で必要になるテクスチャは、既にほとんど破棄されてると
考えるべきでしょうな。(予測してロックでもかけない限り)
>>734 確かに、それは有り得ますね。
DirectXの考え方とも一致するし。
738 :
728 :2005/07/06(水) 02:59:00 ID:XlttkCxH
>733 テクスチャドリブンな描画コマンドの発行をすればそうかもしれないけど、普通はモデルドリブンでしょ? そうすると描画コマンドの最初のメッシュのテクスチャと最後のメッシュのテクスチャが同一の場合もあるわけで。 この場合、分割しなくてもテクスチャの読み直しが起こることは間違いないし、分割した場合1枚目の最後から2枚目に移ったときにはキャッシュに乗っていて読み込まない可能性が高いわけで。 寝るといったのに、答えてる俺。orz
>>734 αキットの構成だと、780Pの4xFSAAも
僅か20GB/secのUMAでやる事になるしね。
>>734 ええ,つまり性能が向上したと言うことですね.
まぁ相関関係を元にした断定的な主張をするのはNG・放置の方向で。
帯域の話を絡めないと、実効性能の推測は絶対に不可能。 スレ立てた人が、早とちりしたんだろうなぁ。
>帯域の話を絡めないと、実効性能の推測は絶対に不可能。 お前はただvsしたいだけちゃうんかと
>>744 >>735 自分で煽っといてなにいってるんだか.
fpsは定性的な性能の指標になりうると思いますよ.
748 :
名無しさん必死だな :2005/07/06(水) 03:17:12 ID:vGUpnWxW
725のUUJYanqgはソースも何もない脳内ソース書き込みを信じて 書き込みを続けているのか・・周りもそれに乗ってるし・・ このスレもうだめだな
>>738 >テクスチャドリブンな描画コマンドの発行をすればそうかもしれないけど、普通はモデルドリブンでしょ?
>そうすると描画コマンドの最初のメッシュのテクスチャと最後のメッシュのテクスチャが同一の場合もあるわけで。
通常、手前から描画していくんで、最後に描画されるものは
奥の方にある小さく表示されるオブジェクトです。
ですんで、分割レンダリング境界を跨いでる可能性は低いですね。
仮に跨いでたとしても、全体としては誤差レベルのメリットしかないです。
UUJYanqgは前スレのアレな人ほどじゃないと思ったからねー遊んでみただけ
>>736 989 名前:名無しさん必死だな :sage :2005/07/03(日) 08:23 ID:bfTXsA5w
>>981 どうしてそれが真実だといえる?
個人的な思い込みをもちだして
あまつさえ、当たり前だから調べる気にもならない
等と誤魔化して逃げるような奴が
統計的な見地を述べようってのが無理ありすぎる
統計というのは詳細な個々の条件について勘案しないかわりに
統計的に意味のある十二分に大きな母体数を前提とし
必要十分なサンプリング結果を持ってきたとき
はじめて妥当性を論じられるもの
その程度の基礎が理解できていないようだから
もう統計的になんて話はしない方がいいよアンタ
>>752 心配しなくてもID:UUJYanqgが
>>725 でソース晒した時点でα比2.8倍の性能UPなんて数字を
信じる人はもはやいないよ。
>>738 テクスチャドリブン?って、テクスチャごとにモデル表示するて事?
なら、今の殆どのハードでは常識。
(テクスチャ切り替えのストールが凄まじいから)
GCだけは特殊だけど。
>>583 > RSXがCellと連携するのは、256MBを越えるサイズのメモリをNUMAとして使う場合か、
なんで256MB超えなきゃいかんのん?
例えばRSXに多くの帯域を与えたいならCELL側の比較的遅くてもOKなデータ、
ディスク裏読み用のバッファとかサウンドデータとか、
そういうのをCELLから見て遠いGDDR3に置いておけば、
256MBとかの枠にとらわれず帯域を引き出せるんじゃない?
極端な話、そんな具合にCELLのデータの内遅くてもいい方から順に
片っ端からGDDRに置くようなやり方で例えばRSXから見てデータは64MBしか無いけど
帯域は(37.6GB?)目一杯使うとかそういう設計も可能なんじゃない?
細かいデータ配置の最適化はUMAの場合よりもソフト開発者の労力がいるんだろうけど。
タイリングで性能劣化が少ないのは、 ・ほぼ全てGPUで処理されるため、CPU負荷はほとんど増えない。 ・ピクセルがレンダリングされないポリゴンは全てのシェーダーアレイがVSに回るためものすごい速度で処理される。 ・別のタイルに書く必要が無い場合は次のタイルからスキップされる。 ・eDRAMからメインメモリへの転送は解像度に依存しますがそれでも十分に早い。 というのが大雑把な説明になります。 シェーダーはほとんどの場合テクスチャリードが多いPSがボトルネックになるので、 それが無いと言うのはかなり大きいです。 統合シェーダーの賜物といえるのではないでしょうか。
テクスチャキャッシュの効率なんて状況次第で
どうにでも変わるのに、語ってもしかたないんでないの?
そもそもテクスチャキャッシュの容量なんて数十KB程度なのでは。
なんか
>>719 はテクスチャキャッシュが、テクスチャ一個まるまる
収まるものであると勘違いしてるような気が。
それと、一回目のZオンリーレンダリングのとき、変換後の頂点を
メモリに書き出すことを前提になんか話が進んでるけど、
それは普通にありえないだろ。
次世代クラスの頂点情報を収めるにはメモリ容量も帯域も食いすぎる。
物体がどのタイルに乗るかは、ポリゴン単位じゃなくて
もっと荒い単位でタグ付けして、テッセレーションも
頂点変換も同じ事を丸々二回やると思われ。
書き忘れたことがあるので追記します。 タイリングで頻発するZテストはボトルネックにならないと言う意味でコストフリーです。 ネガティブファクターは、タイリングによって頂点ストリームの読み込みが増大するので、 あまりにもリッチな頂点フォーマットや頂点数は帯域を大量消費してしまう。という部分だけです。 SCEIの社長が突っ込んでたトライアングルセットアップも十分に早いのでボトルネックにはなってません。
UE3を使った内製ベンチでスクショを晒せず恐縮ですが、 αKitで20〜25fpsだったものが、βKitでは85〜90fpsは出るのは事実です
ゲームみたいな使い方だと、ローカルメモリだろうがL2キャッシュだろうがデータがデカすぎて収まらず、 結局メモリ-CPU間のバースト処理勝負。 だから、NUMAだろうがUMAだろうがバスをMAXまで使い切ることになり、NUMAの意味がない (ちなみにNUMAは「メインのバスの負荷を下げる」小手先技)。 で、バースト処理時のネックは帯域、つまりデータを最大どれだけ送れるかじゃない。 メモリがDRAM内のタテヨコ座標確定の後プリチャージを行い、一塊のデータを読み出してCPUに送信するまでに何ナノ秒掛かるか、が問題。 これは例えれば、道路幅が100車線でも、料金所でクルマが一台通るのに1時間待たされるなら道路はがら空きだろう、という状態。 つまり、帯域幅を強調されてもそれは理論値でしかなく、例えば「1ワードのデータ読み出すのに何ナノ秒掛かるか」が 正確に把握できないと、実測値にはならない。
UE3を使った内製ベンチでスクショを晒せず恐縮ですが、 αKitで20〜25fpsだったものが、βKitでは15〜20fpsになっちゃいました
>>759 ナムコの人?
30フレでもいいからフレームシティなんとかせいや
箱といっしょでHDDの利用を推奨してないのかな
EA社員がβで飛躍的に向上したといってるのにな βKitで性能低下なんて誰も言っていない
>>765 単にソースの明示できない書き込みは信じるに値しないと言う事を皮肉ってるだけかと
普通、ディスプレイは60fps以上出ても意味ないし、カタカナを半角にしている時点で・・・
>>765 間違えてた、訂正しますね
UE3を使った内製ベンチでスクショを晒せず恐縮ですが、
αKitで20〜25fpsだったものが、βKitでは850〜900fpsは出るのは事実です
まあ20→85fpsはいかにもありそうな値だが、そうなると今度は βにどんなブツが塔載されててその数値差になるのかが気になるところだ。
いや、85fpsなんて言ってる以上、信じるに値しないでしょうw
772 :
名無しさん必死だな :2005/07/06(水) 09:12:44 ID:5jL0arH+
開発は、次世代機用にハイビジョンそろえたんだろうなあ。
> 普通、ディスプレイは60fps以上出ても意味ないし、 ベンチマークにその指摘は無意味。 別にPS3との相対比較じゃないんだから、落ち着け。 しかしβ機をE3に間に合わせてプレイアブルにしときゃ、インパクト違ったかもな。 TGSで日本人相手に見せても意味がない。
次世代機 loop34 えっと - 2005/07/04 18:30 No.128115 [SxBAE] 2chの”俺らね、ソニーのPS3はぶっコケると思うよ。14”の -- 972 :名無しさん必死だな :2005/06/29(水) 10:14:08 ID:cmajOfSs まあ、参考になるかは分からないが UE3を使った負荷実験を最新の360開発機とPS3開発機で実行したんだが、結果は 360開発機:161fps PS3開発機:44fps PS3の方はGF7800のスペック通りだったけど まさか、360が100fpsを超えるとは思わなかったよ -- ならコピペ元は俺です。 正しくは 360開発機:1.61fps PS3開発機:44.00fps で、小数点が故意に消されたみたいですね。 単純計算でPS3開発機は箱360開発機(MacG5)の27倍の計算性能です。
>>ならコピペ元は俺です。
>>正しくは
>>360 開発機:1.61fps
>>PS3開発機:44.00fps
>>で、小数点が故意に消されたみたいですね。
>>単純計算でPS3開発機は箱360開発機(MacG5)の27倍の計算性能です。
ワラタw
結構見かけるコピペだったが、こんなウラがあるとは
>>774 で、ソースは?
うちの開発機だと、360で180fp(ry
いやいや、、 360開発機:161fps PS3開発機:44.00fps ↓ 正しくは 360開発機:1.61fps PS3開発機:4400fps で、小数点が故意に移動されたみたいですね
360のハードはほぼ3万円で決定 問題はPS3だな いろいろ買ってたら5万はいきそうだ
そもそもどうやったら共通のベンチマークって作れるかなぁ。 似てるようで意外に比べるのが難しい二機種な気がする。
普通開発者はそんなことをしない
360開発機16.1fps PS3開発機44.0fps が一番現実的な数字。
>>770 基板は最終バージョンKitと同じ、動作周波数がCPU:2.8Ghz、GPU:430Mhzとなっているとの説明を受けています
ならコピペ元は俺です。 正しくは 360開発機:1.61fps PS3開発機:44.00fps で、小数点が故意に消されたみたいですね。 単純計算でPS3開発機は箱360開発機(MacG5)の27倍の計算性能です。 でどこのスレにちゃんと書かれていたものなのか・・
ほんとはこっちとかどうでもよくないか? どっちであろうがその結果を信じてる人はいるのか。 次世代機の2chリークなんていままで無いじゃん。
972 :名無しさん必死だな :2005/06/29(水) 10:14:08 ID:cmajOfSs まあ、参考になるかは分からないが UE3を使った負荷実験を最新の360開発機とPS3開発機で実行したんだが、結果は 360開発機:161fps PS3開発機:44fps PS3の方はGF7800のスペック通りだったけど まさか、360が100fpsを超えるとは思わなかったよ ↑この文面みる限り、100fps超えるのを画面上でみたといえる文面だな。 でも、なんの信憑性もない。そのあとに数字や小数点のかわったレスも 色々みるがこんなの信じられないな。 まぁおおまかにわかってるのは360もPS3も開発キットより実機は性能が いい。開発中のゲーム動画でみるゲームより実際はもっと良くなるだろう ってこと。
>>760 ゲームみたいな使い方だと、ローカルメモリだろうがL2キャッシュだろうがデータがデカすぎて収まらず
えっとーどうしましょうw
データーが大きければ分割して処理すれば良い。SPE+LS&X○GPU+eDRAM
・・要するに、レイテンシが大事だ、と言いたいのか?
実はDDR2になっても性能がほとんど上がらなかったケースは多い 915,GFFXしかり
759,782の情報でだいたいそれっぽいと思うが、スルーなのか?
控えめだから「それっぽい」だけでなんの意味もなかろ
新規ネタも出てこないし 360はLonghorn睨んだ先進のつくりのはずが 実のところはコスト圧縮優先の半端モノ PS3はゲーム機のクセに 中身はゲーム機というよりハイエンドPCそのまんま こういう理解で良いよね。
PS3はHPCの廉価版
>>791 PS3は開発が難航してなかなかプレイアブルにまで至らないから、箱○の開発が
上手くいっているといったたぐいの情報をGKや信者は全部スルーしたいんだよ(w
箱○のα開発キットが3000台配布されたのが本体発売の1年半前、それに比べて
PS3のα開発キットは発売1年前に配られている。
箱○は実機性能に近いβキットを6月に配布、αと同数配る筈だから歩留まりも
悪く無い、PS3もβになったもののGPUをG70に変更しただけで実機には遠く及ばない
性能でバス周りの構造も違うまま、開発ツールもあまり出来はよくないとの事。
発売半年前のTGSでPS3のプレイアブルが出品されなかったら2006年春頃の発売は
無いと見ていいな、箱○の発売日が遅れるように祈っているぐらいだからPS3は
かなりやばいんだろう。
噂レベルの話を掻き立てて推測されても説得力ないわけで
数少ない 「○が有利だ」と思われる情報を必死でかき集めてきたのか それともコピペ?
> PS3はゲーム機のクセに > 中身はゲーム機というよりハイエンドPCそのまんま 既存のハイエンドPCはCellのように演算能力に特化したCPUを載せていないし、 CPU-メモリ間もCPU-GPU間もPS3よりずっと帯域が狭い。 GPU単体はPS3の方がPCに近く、CPU含む全体の構成は360がPCに近い。 要するに、どっちもPCには似てない。
てかこんな所に具体的なfpsなんかの値書くわけ無いじゃん 上司、同僚が見たらパツイチ自分たちの事だと判っちまうんだから
開発機が3000台ってなぁ、なんか多すぎる様な。 PS2に参入してる会社って、単なる販売会社も全て含めて1100社程度よ? 北米だったら一社二本くらいしかタイトル出してない計算になるくらい、あらゆる会社を入れてソレ。 360ってどんだけ参入すんのよ・・・? つか、単にワークステーションとしてMacあげますだから参入してね、みたいな お中元的内容も含めてるんじゃ?
>>796 で、発売まで後半年切ってるというのに完成品がないのを突っ込まれまくってたんだが。
>>801 一社1台なわけないだろ。
大手なら50台以上開発機導入するべ
>>801 の発言で顕著なように、このスレには脳内開発者しかいません
805 :
名無しさん必死だな :2005/07/06(水) 12:36:26 ID:sZ90cCGl
発売5ヶ月前で量産試作品があってクロック低いだけなら、そんなもんかなあと思う。 PS3も360もスケジュール通りじゃね? 大きな得失点差がつかないのは、後攻めながら総取りを狙うPS3にとっては痛いかもしれんが。
550 名前:名無しさん必死だな 投稿日:2005/07/05(火) 20:48:52 ID:cJC0PW5/ 「ハイパープレイステーション」のインタビュー記事でSCEの平井(?)という人が 「Killzoneなどのプリダレンダは実現したい目標。」 と言っている おいおい、キルゾーンが目標って…実現しても既にGoWよりショボイのに
50 名前: 名無しさん必死だな [sage] 投稿日: 2005/06/29(水) 10:43:39 ID:Z33LGD6E 嘘かほんまかわからんけど↓ 972 :名無しさん必死だな :2005/06/29(水) 10:14:08 ID:cmajOfSs まあ、参考になるかは分からないが UE3を使った負荷実験を最新の360開発機とPS3開発機で実行したんだが、結果は 360開発機:161fps PS3開発機:44fps PS3の方はGF7800のスペック通りだったけど まさか、360が100fpsを超えるとは思わなかったよ 109 名前: 名無しさん必死だな [sage] 投稿日: 2005/06/29(水) 19:41:38 ID:cmajOfSs そもそも、 G70は32bitSIMD(4way) x2 x24 360GPUは128bitSIMD(4way) x48 演算精度が全く違うよ 141 名前: 名無しさん必死だな [sage] 投稿日: 2005/06/30(木) 00:57:00 ID:IePo3y7f ほんとにな。しかしcmajOfSsの自爆にはワラッタw
えーと、ここはテクノロジスレだよね?
根っこはただのVSスレです
>>809 GK的に気に入らないレスでもあったんだろ
>>760 動画のストリームを扱う場合のような処理にはデータが連続して
やってくるのでスループットを上げるために帯域が勝負です。
つまり、こんな「バースト処理」には帯域が大事です。
ゲームでも、3D計算では、モデルの連続データを扱うことになり、
帯域は重要でしょう。
むしろ、Apacheなどの小さなトランザクション処理には、レスポンスを
あげるために、レイテンシーが逆に大事になります。
次のTGSでもβ開発機の性能からしてPS3のまともなプレイアブルは無いだろな。 FFTベンチで箱○の2倍をアピールして終りという気ガス。 あとはデモぐらいかな?今度はどんなデモで笑わさせてくれるのか楽しみだ(w
メカと女が踊るムービーだしょう
360開発機:1.610fps PS3開発機:44.00fps が元ネタで少数点を故意に消されたのがコピペされてるらしい。
暗黒太極拳。しかも3Dで。
817 :
名無しさん必死だな :2005/07/06(水) 13:39:57 ID:b714sAqo
アヒルでHDRじゃないかと。
勝手にフレームレートに小数点なんてつけるな どこにそんな小さい誤差まで計れる測定機械があるんだ?
Killzoneのリアルタイムムービー。 でも登場人物が全部アヒル。
>>818 fps測定する機械などこの世に存在しないと思うぞ
普通はソフトの中の人が一生懸命描画した回数をかかった時間で割る
>>812 >ゲームでも、3D計算では、モデルの連続データを扱うことになり、
帯域は重要でしょう。
アドレス的に連続してるかぁ?
ありえん。
>>815 少数点を付けるとき1.61と書くべきで1.610とは書かない。
この時点で操作されているのが明白。
ぶっちゃけ
>>784 が一番恥ずかしい
そんな細かく書くわけねーじゃん
>>808 なるほど
> G70は32bitSIMD(4way) x2 x24
> 360GPUは128bitSIMD(4way) x48
> 演算精度が全く違うよ
cmajOfSsは、こんなdデモ発言して時点でUE3 161fpsネタ
に信憑性皆無なのがよくわかったw
この人って、手を替え品を替え、脳内リーク情報を捏造しては
張ってた人がいたけど、その人かな?
俺は○が素晴らしい性能だと信じているが、この板の○擁護が痛すぎて萎える('A`)
827 :
名無しさん必死だな :2005/07/06(水) 13:59:41 ID:PFq172rL
>>824 同じUE3エンジンを使っているGearOfWarでαで15fps出ているのに、これはありえませんな。
GK乙。
cmajOfSsでぐぐるとコピペされたものしか出てこない。 まぁ、どっちも信じてるのがアホだが。 どっかからのコピペと思わせカキコ ↓ それをさらにコピペ ↓ 今度は改変コピペ
そしてソニー信者がコピペ元は俺だと言い張り登場 ↓ 捏造
開発者の言葉とSSが一番だな 理論値の性能以前にこれぐらいの絵が動くという 指標さえわかればいい この板でも3機種発売された後からでも いつまでも性能論争が絶えなかった つまりソフト次第
つまり、UE3がとても良い物だとしても、ナムコの「フレームシティ」は大丈夫か、と。 そういうことかな?
最初のID:cmajOfSsのカキコが無いんだから… んでID:Z33LGD6Eのカキコということになり。 ぐぐると同じスレでこんなこと書いてる奴。 692 :名無しさん必死だな :2005/06/29(水) 09:45:11 ID:Z33LGD6E なんでもないようなことがー GKのことだとおもーうー 理屈にあわないこーとーもー 奴らの仕業とおもーうー
箱1がだしたSSもE3のであろうと今振り返れば ハッタリは少なかった。 ゴッサム2やHALO2.でさえも やっぱりそこから判断していくしかないな
>>813 FFTベンチでは2倍では済まないんだけどな。10倍以上と推測される。
835 :
名無しさん必死だな :2005/07/06(水) 15:07:15 ID:mjj5uJcp
>>最初のID:cmajOfSsのカキコが無いんだから… テクノロジースレ8にあるよ、 板全体のログもっているからUPしようか?
836 :
名無しさん必死だな :2005/07/06(水) 15:20:00 ID:mjj5uJcp
7だった
>>831 作り手のセンスだからどうしようもないかと
確かに同じエンジンとは思えないがこの開発チームは・・・
きっと鉄拳&リッジに人員割いてるのでしょう・・・
839 :
名無しさん必死だな :2005/07/06(水) 15:42:26 ID:5jL0arH+
ガンダムも作っているかもねー
痴漢って、箱○のGPUの開発の遅れの話が出てて来ると、αキットの話に すり替えるが、αキットってマックG5+nVIDIAの6800SLIでしょ? 既存の 半導体を流用しているんだから、1年以上前に配布できて当たり前。 以前の後藤さんの記事では、R500は本当は年末に完成していないといけ ないんだよね。それが半年遅れ。普通に考えて、箱○の発売は来年に延 期でしょ。
箱○GPUの開発の遅れって、設計段階なのか製造段階での遅れなのか どっちなの?
単なる「ライバルが遅れてると都合いいな」という願望だと思うが。 両陣営とも、明確な遅れを示す徴候は何もない。
遅れてるのはR520でXbox360ではない
根拠のない願望かくところじゃないんだがな・・・・ また遅れる遅れないなんかこのスレ的にはどうでもいいはず。
納期の遅れと品質の低さは相関(←なぜかNGワード)があり、 「遅れて来たけど優れた技術」というのは少ないものだ。
>831 >837 >838 フレームシティーは、ナムコのアメリカの子会社が作ってる
フレームシティはナムコが作ってると思うから腹が立つ。 バンダイの子会社が作ってると思いねぇ。 するとあら不思議。 「意外に頑張ってるじゃないか」 「バンダイもゲーム会社として成長してきたな」 「新しい事をやろうとしてるその心意気は良し」 暖かな感想が心の底からわき出てきます。
箱○のフレームシティといい PS2のクリティカル ベロシティといい ナムコではへぼいグラフィックでゲーム出すのが流行ってんのか? 開発が同じチームだったりして
>>848 アメリカの子会社が作ってるというのは本当か知らないが、
統括してるのは日本人でも不思議はないかと。
普通に日本で作ってると思われ
>>852 フレームシティ 開発者
プロデューサ:川島健太郎
ディレクター:国森将生
結構な人材が集まっているのにあの出来って事は
実際の開発は外注か?
お前らボロクソ言ってるが、GTAタイプのゲームであのレベルのグラを 持ってるんなら十分たいしたもんだと思うんだが・・・要求水準タカスwww 細かい所を見るとアラはあるが高水準だとは思うよ。ただ驚きのレベル!って 印象は微塵も受けなかったが。
GTA形式ならそれこそHDD積んでる360の面目躍如って奴で、がんがんHDDから 高速裏読みして高水準なテクスチャ貼りまくりの超リアル街作れば良いのに。
857 :
( ● ´ ー ` ● ) はスバラシイ :2005/07/06(水) 17:43:10 ID:ayV7We+8 BE:35962188-###
画面の隅にあるコップ一つ手を抜けない(ソニチ中氏)と言われる次世代機で 手抜き素材ばかりで構成したら、どんな評判になるかって言う良い例ですね。 でもゲーム自体は結構面白そう。
物量が足りねえってwwwマジでGTAレベルで売れるならそういう真似も出来るんだろうが。 あとHDDが無くてもいけるだろ。低速な現行機でもやってるくらいだし。 ま、この話って次世代機のソフトが大小の差はあれど確実に直面する問題なんだよなー。 実際ビッグタイトル系とその他じゃ結構絵のレベルに差がついて来てる。 俺は個人的にはハード性能はPS3が上だと思うが、その辺の大手のPS3ソフトと MSのビッグタイトルあたりとの比較になれば、確実に後者が上になると思う。
ファーストが弱い方がサードにとっては参入しやすいの法則
ソフト麺ではSCEIは弱いんだが、ハード面で一人勝ちしてるからなぁ…
>>822 オブジェクト内では連続してるよ。
ストリップメッシュ化もされてるし。
ただ、ピクセル処理でつまるんで、頂点演算処理だけ速くても
意味ないけどね。
>>863 フレームシティに比べて特別なにがどーということも無いよーな
>>865 GTAの話が出てきたからポインタとして書いただけ
まぁフレームシティもっと頑張れよって事です
あのナムコがのこレベル?って悲しいじゃん
かなり前から内部崩壊しているのは知ってるけどさ、、、orz
てか、この手のゲーム見るとやっぱ、、えーとなんだっけヤクザミッション?
いや、日本名えーとえーと、、、ダブスチか、ダブスチ、あれ結構凄いやね。
逐次読み込み型にするとダブスチ開発者が作ってもやっぱしょぼくなんのかな。
>>863 とか(スクショの解像度低いけど)ぱっと見ダブスチのがよく見える。
ダブスチ2はともかく1はFSAAかかってないからギザギザが目立つ 今となっては箱ソフトでも凄い訳ではないよ
>>867 ダブスチは好きだよ、箱初期の時から凄い画面出してたし箱庭最高
ただ次に繋がらないってのと、タイミングが悪い
ダブスチ2も箱360でLive対応だったら最高の箱庭ゲームになったと思う
世の中上手く行かないね、ジャパンサミットで何か出ないかな
あ〜もったいない
ダブスチは夜だけ凄い
というか、ダブスチは「ぶんか社」販売ってのがスゴイって記憶しかない。
ダブスチは凄いがおもんない。 何が悲しくて車でアスレチックせなならんの。
モーションブラーはかかってないよ 持ってる人間ならわかると思うけど
高輝度部分が流れてるのをモーションブラーと勘違いしてたみたいだ 開発者がやってなと言ってるし
いっそ潔く車ゲーとFPSだけに特化したハードウェアは作れないんだろうか。北米用に。
ダブスチ2、普通に360のゲームですって言われても信じるなぁ。
HDTV(D4)対応であの画面だせるのか 一画面内のジオメトリのオブジェクト量の少なさが気にならないようなSSを選んでる気は するけど、それでも64Mのメモリでここまでできるんだな・・・
つーかダブスチ2ぶんか社じゃなくなちゃったの・・? これは謝罪と賠償を要求せねばなるまい・・
開発はぶんか社だよ、パブリッシャーはマイクロソフトだけど
882 :
名無しさん必死だな :2005/07/06(水) 20:42:22 ID:W7yrMnxY
>>876 GK沈黙。
ちょっと刺激が強杉たようだ(w
プリレンダにあっさり騙されて大喜びの痴漢カワイソス
ダブスチ2にプリレンダなんか存在しないよ
>>883 いゃあ、それが違うんだなぁ(笑
ダブスチ1をやった俺にはわかる。
リアルタイムフィルタとかプラグインっぽい扱いでできて欲しいな、次世代機
グラフィック=性能と捉えるのであれば、 単純比較はできないけど、PS3はXBOX360の1.5倍ぐらいのピクセル処理、 法線系の処理が特に凄まじいです。 レイヤが薄いシェーディングプログラムであれば、両機種とも差は開かないですね。 もしろXBOX360の方が組みやすい分有利ですね。 ちなみにPS3でも帯域は足りません、 プロセッサ性能に帯域が追いついていません。 まぁそこが腕の見せ所ですが・・ でわでわ
てか次世代機スレでなんで現世代機の話が盛り上がるんだよ PS2よりかなり遅れて出たハードがPS2よりすごい事できなかったら それこそすごいことになっちまうだろうが、自爆信者ども
NVIDIAのGPU凄いねと言うべきか、開発力凄いねというべきか。 いずれにせよ次世代機テクノロジとは関係ないわな。
>>891 ダブスチで開発された技術のいくつかは箱○に搭載されるとの事だから
少しは関係あるのでは。
そりゃ少しは関係あるかもしれないけど、 そのXbox360向けに使われる技術の詳細でもわからなければ ネタにしようがないような。
てか、ダブスチの人(と言うか会社)ってMSと独占契約でも結んでるのかな、 SCE辺りが開発費出してセカンド化とかしないんだろうか。
895 :
名無しさん必死だな :2005/07/06(水) 22:32:55 ID:ruoSxLc1
川瀬さんはAlchemyんとこに行きましたよ。
>>876 質感がオモチャっぽい。いいところまで行ってるが残念。
ダブスチのチームは高い技術を持ってるかも知れないが、箱陣営に
居るうちは日陰のままだな。
メモリ64Mでシェーダーにも制限のあるXBOXと次世代機の映像比べちゃダメさ
ダブルスティールはPS2で出なかったっけ?
964 :名無しさん必死だな :2005/07/06(水) 22:58:14 ID:SCpZX+sX
>>936 PS3の開発環境には触れる機会がないので、断言は出来ませんが
360βKitのGPUと個人的に所有しているGF7800GTXでは、360βKitの方が倍近く強力に感じます
PC上でGF7800GTXを使った開発を仕事でしている訳ではないので、全く主観的な感想ですが
PS3云々じゃなくPen4と360CPUの差じゃねぇのか?
今まさに360βキットを叩いて開発中の奴が現時点でわざわざGF7800GTXを買うわけが無い。 しかも仕事でもないのに。主観的な感想ですが。
いい加減この手の話題を構うのやめれ
>>901 え!そうなの? やっぱPS3の性能ハットリか。
このパターンはもういいがな
相関騒動以降無駄にスレ消費してるな・・・
毎日毎日、 よくもまぁ飽きもせず 新作を考え出すなぁ・・ (^ω^;) これはどこから? いつものvsスレからじゃ無いようだけど?
次スレPS3とXbox360に分けない? メリット ・話題が半分になるのでループが減る ・荒らしの分量も半減する ・vsスレときっちり住み分けが出来る(現状ほとんど出来ていない)
>>912 これ以上分けてもしょうがないと思う。
それに、その内容だったらPS3スレとXBOX360スレでやればいいことだし
>>914 つまり、GF6とGF7はSM3.0対応かとおもいきやマイナーチェンジに終わったRadeon9800とX800の関係みたいなもんか。
>>915 どこを、どう読んだら…
NV40の時点でSM3.0対応してるよ。
ディスプレイスメントの実装が中途なのは、ぶっちゃけ必要性少ないから。
モーフィングはボーンでも、モデルの合成でも出来るし。
ディスプレイスメントマップだと、普通に良くある頂点単位のボーンウェイトとかが、まともにできないからな。 ノーマルマップでも似たようなもんだが、こっちはジオメトリはいじらないから、それほど変でもない。
>>914 要は、
関係者っぽい情報を書く -> 他スレに別IDでコピペ
のサンロクマル信者マッチポンプ君が来なけりゃそれでいいわけで。
この人はここ半年くらいずっと同じことやってるし。
予想が当たれば偉いが悉く外れてるのが微笑ましいけどw
>>916 どこをどう読んだらそうなるんだよ…orz
SM3.0対応しなかったってのはRadeonX800の話。
>>919 >GF6とGF7はSM3.0対応かとおもいきや
これは突っ込まれて仕方ないくらい、わかりにくい。
「GF6とGF7は、SM3.0対応かとおもいきやマイナーチェンジに終わったRadeon9800とX800の関係」 「GF6とGF7はSM3.0対応かとおもいきや、マイナーチェンジに終わったRadeon9800とX800の関係」 いわゆるアレっすね、論理的にも二重の意味になってしまう曖昧な日本語の問題点。
つまり、GF6とGF7は[SM3.0対応かとおもいきやマイナーチェンジに終わったRadeon9800とX800の関係]みたいなもんか。 なんだろ
つーかなにを例えているのかさっぱりわからん。 性能は3倍になってるんだが。
>>919 -
こういうアホなやり取りを1/2の確率で見ないで済むなら
スレ分割も悪くはないな。
まぁ、「通常の8倍」よりも「通常の3倍」の方がピンと来る人もいるんじゃないんですか? 一億円出されるよりも百万円出されるほうが現実感を憶える人も居るらしいですし。
>>925 多分両方で見かけるから精神的には2倍増えたように感じるかも。
G5でSLIのマッキントッシュなんてあったっけ?
ないよ?
そもそもPCIexpress搭載のMacが…
>>928 E3でのGears of Warはフレームレートが改善されていたので質問したら実は
GeForce6800のSLIのx86 PC上で動いていた、という話。つまるところ、現在の
ハイエンドPCにターゲットを絞ってゲームを作ればGears of War並の絵は出せる
ということ。
それはXNAで開発していれば、CPU&GPUが異なっていても、容易にコンバート出来るという話だな
>>現在のハイエンドPCにターゲットを絞ってゲームを作れば これはあり得るな PCゲーの宿命とも言えるけど、完全に最上位機種にチューンして出せないからな どのみち○GPUより性能が上の7800が売り出されてる事を考えれば、無理はない
>>932 XNAじゃないよ。
UE3使ってればスクリプトやアートアセットは流用可能になる。
当然UE3はPCで開発が先行しているんだからそっちで動かした方が簡単だ罠。
Xenosはソフトウェアから見ると普通にDirectXで扱えるの? 昔タイリング採用したPowerVRは互換性に苦しんでたけど。
>Xenosはソフトウェアから見ると普通にDirectXで扱えるの? 気をつけなきゃいけない点がPCと違うだけで、関数等はDirectXと同じじゃないのかな。 アラードたんがそんな事言ってた気がする。 さすがに完全にソースコード互換って訳は無いと思うけど。
XBOX360の開発者は何故ネットや2ちゃんねるに やたら出没するんでしょうか?
メモリは、理論値どおりに1ナノ秒でデータを吐き出すわけではなく、 実際には10ナノ秒(1T-SRAM)とか40ナノ秒(XDR)程度で吐き出す。 だから、帯域というか「1ナノ秒でデータを読み出すと仮定して算出した値」 を見ても、実測値は分からないよね。
本当の開発者は馬鹿らしくてゲーハー板なんか来ない。 来るのはゲーム開発に興味のあるアマチュア。 アマチュアのXbox開発者やPS2/3開発者というのは居ないが、 PC上でDirectXかじっただけのアマチュアはいっぱいいる。 PC上のMesaでOpenGLかじった人もちょっとはいると思う。いないか。
例えばXDRの16bit幅なら、6.4Gbytesの帯域というのが公称値。
東芝のXDRはサイクルタイム(要は待ち時間)が40ナノ秒。
http://www.toshiba.co.jp/about/press/2005_03/pr_j3001.htm 40ナノ秒が何を意味するかといえば、
400MHz(40ナノ秒周期)以上のクロックには対応できず、後のクロックは全てムダであるということ。
だから、実測値が欲しいなら以下の通り。
400000000Hz相当の性能 * 16bit / 8bit = 800000000bytes
よって、XDRは800Mbytes/secの性能だと判断できる。
これは大体、DDR初期レベル〜中期レベルの性能だよ。
結局、メモリがデータ吐くのはあまりにも遅いから、帯域が幾ら広かろうが意味が無いわけだね。
で、apacheとかが喜ぶといった点について。
コプロセッサが通信回りをやってくれるならば、PPEは通信専用スレッド張ったりしなくて良くなる。
そうすればPPEは通信専用スレッドのためにタスク切り替えの時間を取られないよね、ってこと。
この辺はCellそのもののアーキテクチャの話だから、本当にタダの蛇足だよ。
eDRAMに物凄い魔法が込められてると思いこんでた香具師は、今なにしてんだろうな
いやいや、UMA+eDRAM+統合シェーダは、コスト的には有効な技術。 PS3が価格差に見当った性能差を表現できないうちに、 値下げをテコに普及台数の拡大を図られると、 北米市場のPS3はそうとうにヤバイと予想。SCEに有効な対策はあるのかな。 任天堂みたいに縮小均衡路線もとれないし。
>いやいや、UMA+eDRAM+統合シェーダは、コスト的には有効な技術。 それについては具体的な提示はなされておらず 脳内予想を立てられてもな
360はローンチに十分な台数を用意出来ないのではないかと報道されているようだが。
もう捏造君は勘弁してくれ
947 :
名無しさん必死だな :2005/07/07(木) 10:28:06 ID:BFQ0V07B
DRAMへのRequestをしてからデータが出てくる時間と 配線を流れるデータ量(帯域と)と無関係だよ・・ その理論だと今後出てくるシリアルメモリは、PC100にすら勝てないんですが・・。
>いやいや、UMA+eDRAM+統合シェーダは、コスト的には有効な技術。 GCもこんな感じ?
というかUMA+eDRAM+統合シェーダ これ実はPS2と同じなんだよね。 XBOX360のアーキテクチャって CPU+GPU親(shader)+UMAメモリ+GPU娘(eDRAM+PixelEngine) PS2のアーキテクチャは、 CPU(汎用ユニット+shader用途のVU)+メインメモリ+GPU(eDRAM+PixelEngine) XBOX360のCPU+GPU親がPS2のCPUに対応して、メインメモリを使う。 XBOX360のGPU娘がPS2のGPUに対応する。
きみは向いてなさそうだ
>>943 現状脳内予想なのは肯定派も否定派も同じだろ。
ソースなしに断言することが、妄想 このスレには否定派が存在するんじゃなく、妄想肯定派を否定してるだけ
VUはピクセルシェーダにも頂点シェーダにもなりうるから、統合シェーダだといえなくもない。
xbox360の統合シェーダ=ベクタユニット1つ+スカラユニット1つが同時実行可能 PS2 EEのVU=ベクタユニット1つ(厳密にはスカラユニット4つ)+スカラユニット1つが同時実行可能 もちろんPS2はVUを2つしか持ってないのに対し、 xbox360は統合シェーダを48個搭載してるいるので、性能は同じではない。 でもアーキテクチャはソックリ。
その恥ずかしいタイトルは何だ
>>945 KenJEKe7は知っててわざと書いてると思うよ。
>>943 1Gbit品がリーズナブルになればDRAM8個から4個にシュリンクできる。
PS3もシュリンクできるぞ、とクタタンは言いはってるけど、
PS3専用品になるのはコスト面で不利だ。
こういうのは脳内予想じゃないよな?
つか、360のGPUって将来的にワンチップに出来るのかね? eDRAMの製造ならNECだけど、GPUのまでの製造をやれるかやらせるか?って感じもするし、 TSMCにeDRAM(3DRAM?)の技術をライセンスするんだろうかと言うのもよー分からん。 まぁ、そんなに大きなチップでもないし統合しなくても小さくなっていけばそんなコストでも 無いのかも知れないけど。
XDRは実質的にPS3専用みたいなものだからコストアップにならないかも 知れないと後藤ちゃんは書いているな。
コストアップにはならないが、 コストダウンにもならない、と。 PS3にしか需要が無いチップだし。 DRDRAMだって、結局消えて、 PS2専用に 128Mbit品を延々と作り続けている・・ それでもPSだけでかなりの需要だから 元は取れてるだろうけど 将来はPS専用にSCEが自社にラインを作ったらどうだろう?>メモリ メインチップを作れるのに、メモリを作れないってことは無いだろう。 確実に需要があるラインなんだから
メモリはいっぱい投資していっぱい作る汎用品なので、ソニーが手がける意味がない。
963 :
名無しさん必死だな :2005/07/07(木) 12:26:38 ID:OpSRJYBN
PS3のメモリ構成は 512Mb-XDR-DRAM×4 (x16bit ×4) 512Mb-GDDR3-DRAM×4(x32bit ×4) だよな?1Gbのチップにシュリンクしたとして、 x32bitのXDRとかx64bitのGDDR3って規格存在したか? 周波数上げて理論帯域を一致させても、 pin幅変えたら実効大域はずれるよな。
>>961 >将来はPS専用にSCEが自社にラインを作ったらどうだろう?>メモリ
DRAMプロセスとCMOSロジックプロセスは設備からしてかなり違うから。
サムソンとか世界的大手のDRAMベンダは、莫大な設備投資と
莫大な生産量で、厳しい薄利多売競争をやってて、投資的には
リスクが高い割に旨味は少なそうに思うけど。
(だからかつてDRAMで世界市場を支配してた日本企業はほとんど撤退した)
XDRの32bit規格は現在は無いが、 何しろほぼ唯一の顧客がPS3。 唯一の顧客が「規格を広げてくれろ」っつったら何とかなるのでは。 ラムバスも製造3社も対応するでしょ。 よって将来は XDR 32bit 1024Mbit 4個 GDDR3は 既に32bit。 64bitは どうだろう・・ もう無理じゃないかな。 S.I.P.でXENOSみたいにパッケージの中に入れちゃうというのが クターが発言してたひとつの案。 が、10MBではなく、256MBというのが・・
ちがった XDR 32bit 1024Mbit 2個 ですた
967 :
963 :2005/07/07(木) 12:44:04 ID:OpSRJYBN
>>965 XDRの特徴は小さいpin幅で帯域を得られる事だと思うんだがな。
ついでに言うと、あえてpin幅を狭める事で高速動作を可能にしていると聞いた事があるような。
しかしシュリンクする頃には爆発的な需要は過ぎていると思うが、ただでさえ需要の少ない
XDRに新しいラインを作るんだろうか?ARMとかの組み込み系が対応してくれればいいんだが。
XDRなんかは特に後にコストダウンすることも契約にいれてると思うけどね。
970 :
名無しさん必死だな :2005/07/07(木) 13:01:59 ID:TwkhsFgr
契約の関係でCellとRSXをワンパッケージに出きるとクタが言っていたけどな、メモリのシュリンクは当分無理だろう。
>>949 360のGPU娘はROPだけだから、PS2とはやはり違う。
PS2のVertex処理はVU(CPU)だが、360はGPU親が受け持つし、
360のVRAMはUMA+eDRAM。
>>970 PS2では250nmプロセスで250平方mm近くのチップ2つが90nmプロセスでやっと一体化。
PS3のCell+RSXをワンチップに出来るのは30nmプロセスになってからからだろうか。
PS3の売れ行きにもよるだろうけど、メモリのシュリンクの方が早いんじゃないかな。
どんどんプロセス移行は難しくなってるから、 5年では45nmプロセス量産まで到達できない気がしてる。
プロセス移行が難しくなってるから デュアルコアなんだよ そのうちGPUもデュアルコア
いや、デュアルコアなのは ・ プロセス移行しても消費電力が下がらずクロックを上げられない ・ ILP(Instruction level parallelism)の向上が限界に達したために、これ以上複雑なコアにしても意味がない せいでございます。 プロセス移行できないと、マルチコアで性能向上のアプローチも成立しないし。 トランジスタあたりの性能向上、という意味では、Cellはよくやってるな。 Xenonも上手くやってるのかもしれないが、ベンチマークの公表が欲しいところ。
Cellなんかappleに蹴られた時点で 疑いをかけるべき Itanium2みたいなプロセッサなんだろ そんなに優れてるならなぜPC向けに 量産しない?
組込みと違って、PCではバイナリ互換性が最重要だから。
PCで一番必要な事は互換性 CellはCPUとして優れていたとしても、既存のソフトがそのまま使えない現状では PC向けCPUには成り得ない それに、同じPPCコアを積んでるとはいえ、Cellの能力を生かすには移行の為の研究を しないとならない 5年以上前からIntelへの以降を準備してきていたAppleがいきなり採用を持ちかけられても 蹴って当然
いや性能面で一般向けOSには普通に向かないだろ
一般向けOSで走らせる重い処理が、映像とかのCellが得意とするストリーム処理に なりつつある現状では、一概に向かないとは言えない。ただAppleが欲していたのは ノートPC用のCPUだったから。それはPowerPCやCellのロードマップにはなかった。
仮にノート向けだとしても基本的に電圧下げて少しクロック 落としてやれば十分だろう AthlonXPでさえノート向けに存在してたんだから linuxが動くなのになぜwinsowsでは駄目なんだ? linuxが動くならmacOSでも動くはずだ PPCでもwinsowsは動くのに 基本的にcell対応したドライバだけを作ってやればいい ソフト対応なんてソフトメーカーが順序対応していくだろう それらのソフトが全く動かないわけじゃないだろ
PPEの基本性能明らかに低いし。 SPEに最適化された一部のアプリのマルチメディア系の処理が速いから それ以外の遅さは我慢してくれじゃ通らないね。
>>981 そんなに単純にCPUの移行ができるならAppleが5年間も研究する必要無い訳で・・・
>>980 PPEや360のCPU1コアだけ使うとかできなかったのかな?
といってもそれじゃただのPPCの機能削減版か。
仮にマルチメディア用途でもcellでlinux動くならMAYAやsoftimage、filmbox も動くだろ。なぜベンチマークを公開しない? speがくっついているせいで性能発揮できないのか?
PS3のサードパーティに「PS3にはCellが塔載されます、プログラムをSPE用に書いてください」 と言ったらみんなちゃんと書いてくれる。 でもAppleのサードパーティに「今度のPowerMacはCell塔載ですので、SPE用に書いて ください」といっても、書いてくれない。 まず様子みて、Cell塔載PowerMacのシェアが過半数になったら考えましょう、 と言われてしまう。 そこが組込みであるゲーム機とPCの違い。
PS3が普及した後で、PS3用のソフトが簡単に移植出来ますとなれば Macも載せたかも?
spe書いてくださいといってもそこまで めちゃくちゃ手間隙かかるわけでもないだろ intelのHTTもSSE2も結構速くソフトメーカーは対応した PPC3.2Gの3個よりもダントツに性能いいなら なぜやらないのか? CPU最適化なんてソフトの1つや2つそんなに大変じゃないだろ
>>985 SPE使用するように書き直す必要があるから
Linuxが動いてるというのはPPE上であってSPEはデバイスとして表現されている
単にコンパイルしなおすだけじゃ3.2GのPPEの性能が出るだけでCellのベンチマークとして
意味を持つ数値ではない
oycdOqFPの理解の範疇を越えたところに そうはならない大人の事情がいろいろある、ということで勘弁。
SSEはShadeが延々対応しなかった思い出しか無いな・・・ アレはメーカーが糞だったんだろうが
>>988 めちゃくちゃ手間隙かかります、もちろん金も
広く一般に販売されるかどうかも解らないCellPCの為に、現段階でコストをかけて対応する
利点がソフト会社側には無いから
ソフト会社的にはCellPCの販売が決まってからでも対応するのは遅くないしね
最適化といっても実験段階の最適化なんて 昨今のソフトでもいくらでもある それでうまく性能発揮できてなかったりエラーもでる バグも存在するがするがwindowsでさえもそれは 当たり前、下手したらwindows自体CPUに最適化されて なかったりもする cellも別にそれでいいと思うが とkにかくcellの性能は未知数
windowsでさえ× winアプリでさえ○
とりあえず、誰か翻訳してくれないか?
とりあえずベンチマークは出てるけどね ラージサイズFFTでIntel製CPUとの比較で100倍性能出したというのと、 Mpeg2SDストリーム48本同時リアルタイムデコードをしたという物が
Mayaでのリアルタイムクロスシミュはやったんじゃなかったっけ?
>>988 Powerプラットフォームそのものがまとめて蹴られたのだから、
3.2GHz 3コア PowerアーキテクチャCPUを引き合いに出すのは間違い。
appleが採用しなかった理由で上げられてる他にありそうな理由として、
現状のCellの性能はともかく、その後が提示されてたかどうかというのがある。
ゲーム機は5年程同じスペックで闘うが、PCの世界は短い周期でグレードアップする。
そのグレードアップパスが十分にあったかどうかだな。
もしくはAppleが望むカスタマイズ契約が成立するか。
契約というのは双方に旨味がないと成立しない。
Apple側の旨味もSony側の旨味もね。
>>997 やってたね
Cellブレードサーバーを試作しているんだし、そのうちサーバー系ベンチの結果は
出てくるんじゃないかな
ハ,_,ハ m ? ,:' ´∀'; ノ r 、 l^ヽ'"'"~/^i'ツ'∧_∧ / ヾ 'ミ, ) __ ミ ´ ∀ ` と, ヽ ==--- ̄ ̄ ッ _ "ミ__> ====---- (´彡,. (,,_,ノ _ヽ_)_) "'"'゙''""''''゙""´ ばふっ
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。