【ゲームハード】次世代機テクノロジー10【スレ】
前スレ
【ゲームハード】次世代機テクノロジー9【スレ】
http://game10.2ch.net/test/read.cgi/ghard/1120348765/
無闇に他機種間の比較をする書き込みはスルーの方向で
【ゲームハード】次世代機テクノロジー9【スレ】
http://game10.2ch.net/test/read.cgi/ghard/1120348765/
無闇に他機種間の比較をする書き込みはスルーの方向で
|
|
|
2 ：名無しさん必死だな：2005/07/07(木) 12:58:35 ID:UtbtAPl4
2get！
http://www.pcpop.com/doc/0/90/90528.shtml
sm4.0対応で今後5年間でxenosに勝るGPUなし
sm4.0対応で今後5年間でxenosに勝るGPUなし
SM4.0ってなんだ？
DirectX 10と同じ様なもんかと。
cellはおかしいんだよ
なぜ低消費電力で理論値上性能もメチャクチャ高く
PS3に載る位に価格も安いのに実態がでてこないのか・・・
360CPUもかなり無理してきただろうからね
それを最適化うんぬんでPCには使えませんなんて
基本的にlinuxなんか使う奴は1つや2つぐらいの用途でしか
使わないしそれ一つだけの最適化なんていくらでもできるだろ
基本的にワークステージョンの考えに近いだろうからね
cellはSGIのCPUみたいだ
なぜ低消費電力で理論値上性能もメチャクチャ高く
PS3に載る位に価格も安いのに実態がでてこないのか・・・
360CPUもかなり無理してきただろうからね
それを最適化うんぬんでPCには使えませんなんて
基本的にlinuxなんか使う奴は1つや2つぐらいの用途でしか
使わないしそれ一つだけの最適化なんていくらでもできるだろ
基本的にワークステージョンの考えに近いだろうからね
cellはSGIのCPUみたいだ
シェーダーモデル4.0、シェーダーモデルというのはピクセルシェーダーと
バーテックスシェーダーがどれだけの機能を持つかという基準で、
マイクロソフトの定めた物・・・だったかな
規定されている機能を満たしていればそのバージョン対応って事になる
まぁ、GPUの性能はSMだけで決まる訳じゃなく、対応してても遅くて使い物に
ならないとかもあるので、あくまで対応している機能の最低限の目安だが、
PCでDirectXを使う場合は使えるのがこの範囲に制限される
OpenGLやゲーム機の独自APIでGPUを使う場合は、GPUの持っている能力を使い切る
ためにSMに縛られる事は無い
バーテックスシェーダーがどれだけの機能を持つかという基準で、
マイクロソフトの定めた物・・・だったかな
規定されている機能を満たしていればそのバージョン対応って事になる
まぁ、GPUの性能はSMだけで決まる訳じゃなく、対応してても遅くて使い物に
ならないとかもあるので、あくまで対応している機能の最低限の目安だが、
PCでDirectXを使う場合は使えるのがこの範囲に制限される
OpenGLやゲーム機の独自APIでGPUを使う場合は、GPUの持っている能力を使い切る
ためにSMに縛られる事は無い
>>7
使えませんなんて誰も言ってないよ
現にCell搭載のコンピューターシステムは開発されている
ttp://pc.watch.impress.co.jp/docs/2005/0629/mercury.htm
まぁパーソナルコンピューターとは色々と違うだろうが
で、結局君は何が言いたいんだね？
使えませんなんて誰も言ってないよ
現にCell搭載のコンピューターシステムは開発されている
ttp://pc.watch.impress.co.jp/docs/2005/0629/mercury.htm
まぁパーソナルコンピューターとは色々と違うだろうが
で、結局君は何が言いたいんだね？
つーか、RadeonX850 はSM2.0だしね。
>>7
採用CPUは必ずしも性能・消費電力では決まらない。
もしそれで決まるのであればMacでも、IntelよりむしろAMD採用するでしょ。
DD1テープアウトが去年夏、DD2テープアウトが今年春、ここから量産開始して、
少なくともソニー生産分はPS3に載るし、他も回される可能性は十分ある。
現状家電、PC等他に大量供給しづらいという事情もあるし、
そもそも登場したばっかりなのだから情報が少ないのも仕方ないでしょ。
でもIBMがオープン化と言ってるので、これから情報が色々出てくる。
採用CPUは必ずしも性能・消費電力では決まらない。
もしそれで決まるのであればMacでも、IntelよりむしろAMD採用するでしょ。
DD1テープアウトが去年夏、DD2テープアウトが今年春、ここから量産開始して、
少なくともソニー生産分はPS3に載るし、他も回される可能性は十分ある。
現状家電、PC等他に大量供給しづらいという事情もあるし、
そもそも登場したばっかりなのだから情報が少ないのも仕方ないでしょ。
でもIBMがオープン化と言ってるので、これから情報が色々出てくる。
12 ：名無しさん必死だな：2005/07/07(木) 15:48:48 ID:k4OpcKdD
>>7
はいはい。そうだといいですねｗ
はいはい。そうだといいですねｗ
つまりだ
性能がかなりハッタリ臭いんだよ
N64も大々的にワークステーション用の
凄いCPUだと宣伝したが実態は
PSのシャギをとったようなソフトばっかりだけ
メモリの問題もあったんだろうが・・・
つまり次世代機のゲーム戦争はCPUの性能
なんかあまり問題ではなくGPUで決まるんだよ
cellは糞だということだ
性能がかなりハッタリ臭いんだよ
N64も大々的にワークステーション用の
凄いCPUだと宣伝したが実態は
PSのシャギをとったようなソフトばっかりだけ
メモリの問題もあったんだろうが・・・
つまり次世代機のゲーム戦争はCPUの性能
なんかあまり問題ではなくGPUで決まるんだよ
cellは糞だということだ
途中の説明のせいでまったく説得力なくなっちゃったけど^^
まだ1行書き捨てていった方がましだったかもね
まだ1行書き捨てていった方がましだったかもね
結論はCellがクソだとしてもPS3が最強だということか。
判りにくいな。
判りにくいな。
>>10
確かSM2.0bだかの2.0拡張だったような
>>13
実際にIntelCPUの100倍の性能を叩きだしたCPUがハッタリですか・・・
ま、何が言いたいかは理解しましたが、主観のみで構成されている
そのような意見はvsスレで思う存分どうぞ
確かSM2.0bだかの2.0拡張だったような
>>13
実際にIntelCPUの100倍の性能を叩きだしたCPUがハッタリですか・・・
ま、何が言いたいかは理解しましたが、主観のみで構成されている
そのような意見はvsスレで思う存分どうぞ
PS3はGPUも糞だよ。
>PSのシャギ
19 ：名無しさん必死だな：2005/07/07(木) 16:01:16 ID:xwndrQzn
日本人が話している気がしねえ(；´Д｀) ・・・
R4300は高性能CPU。
コプロセッサも優秀。
だがプログラマーの負担を考えて無かった
いきなりマリオ64を出したから
あれくらいできて当たり前かと思わせた
コプロセッサも優秀。
だがプログラマーの負担を考えて無かった
いきなりマリオ64を出したから
あれくらいできて当たり前かと思わせた
そもそもCell（だけに限らない）が、ある用途においては相当な能力を持ち
向かない用途においては糞であるなんざ、当たり前すぎる話じゃないのか？
てかこのご時勢で同程度の価格（面積）をもつｼﾘｺﾝで全てにおいて
最高性能であるなんて魔法の技術があるわけないじゃん。
でｹﾞｰﾑ用途にしぼったらCellはそこそこいいｱｰｷﾃｸﾁｬｰなんじゃねって事で
ﾜｰｸｽﾃｰｼｮﾝだのPCだので最高である必要はさらさらないと思うがな
向かない用途においては糞であるなんざ、当たり前すぎる話じゃないのか？
てかこのご時勢で同程度の価格（面積）をもつｼﾘｺﾝで全てにおいて
最高性能であるなんて魔法の技術があるわけないじゃん。
でｹﾞｰﾑ用途にしぼったらCellはそこそこいいｱｰｷﾃｸﾁｬｰなんじゃねって事で
ﾜｰｸｽﾃｰｼｮﾝだのPCだので最高である必要はさらさらないと思うがな
>>実際にIntelCPUの100倍
300GHz相当とすると、メモリやL2とか全てがボトルネックになるような気が。
PS2が出るときも似たような事いってたけど比較に使われたPen3と大差ないXBOXより遅かったし。
知識無いので聞きたいんだけど、どんな用途の場合に100倍の差が出るの？
300GHz相当とすると、メモリやL2とか全てがボトルネックになるような気が。
PS2が出るときも似たような事いってたけど比較に使われたPen3と大差ないXBOXより遅かったし。
知識無いので聞きたいんだけど、どんな用途の場合に100倍の差が出るの？
cellは凄い→じゃなぜintelに対抗できないの→最適化できないから→
最適化なんてやればできるよ→linuxだし大変だから→それでもcellは凄い
EEの二の舞だな
最適化なんてやればできるよ→linuxだし大変だから→それでもcellは凄い
EEの二の舞だな
Cellを300GHz相当とみなすより、
Cellが3GHz×7なのに対してP4が200MHz相当の働きしかしていない、と考えた方が
100倍の差がどうして生じるか考えやすいかも。
メモリとCPU速度のギャップがありすぎて、伝統的な階層型キャッシュ機構だけでは
せっかくのCPUの速度が死んでしまうのですよ。(ストリーム処理の場合、ね)
Cellが3GHz×7なのに対してP4が200MHz相当の働きしかしていない、と考えた方が
100倍の差がどうして生じるか考えやすいかも。
メモリとCPU速度のギャップがありすぎて、伝統的な階層型キャッシュ機構だけでは
せっかくのCPUの速度が死んでしまうのですよ。(ストリーム処理の場合、ね)
>>23
>cellは凄い→じゃなぜintelに対抗できないの→最適化できないから→
>最適化なんてやればできるよ→linuxだし大変だから→それでもcellは凄い
大間違い。
正しくは、cellは凄い→じゃなぜintelに対抗できないの→土俵が違うから
最適化に関してもPCにおける最適化とゲーム機の最適化は違う。
>cellは凄い→じゃなぜintelに対抗できないの→最適化できないから→
>最適化なんてやればできるよ→linuxだし大変だから→それでもcellは凄い
大間違い。
正しくは、cellは凄い→じゃなぜintelに対抗できないの→土俵が違うから
最適化に関してもPCにおける最適化とゲーム機の最適化は違う。
というか、Linuxだから大変とは誰も言ってないし。
”高性能だったら全ての用途において最高でなければウソ”ですか。
凄い理論ですね～。
凄い理論ですね～。
我慢して64の二の舞っていってたのにもうEEの二の舞になっちゃったｗ
こらえ性のない妊娠だなぁ
こらえ性のない妊娠だなぁ
違うだろゲームパフォーマンスも優れているなら
PCとしても優れているということはある程度説明できる
PenMや64みてもしかり
それにPCアプリなんてそんな複雑な計算するわけでもない
cellは凄い→じゃなぜintelに対抗できないの→ハッタリだから
PCとしても優れているということはある程度説明できる
PenMや64みてもしかり
それにPCアプリなんてそんな複雑な計算するわけでもない
cellは凄い→じゃなぜintelに対抗できないの→ハッタリだから
なんか、凄い展開になってきた
>>24
実際には２００MHｚとかありえないわけで。
PPE＋SPE*7 = Pen4*100 が成り立つとして、PPE単体でPen4の約12倍ってありえるの？
クロックは3.2Gとしてさ。
100倍差が出るのはストリーム(頂点ストリーム？)だけ？
物凄く局所的な部分で100倍なだけですよね？
実際には２００MHｚとかありえないわけで。
PPE＋SPE*7 = Pen4*100 が成り立つとして、PPE単体でPen4の約12倍ってありえるの？
クロックは3.2Gとしてさ。
100倍差が出るのはストリーム(頂点ストリーム？)だけ？
物凄く局所的な部分で100倍なだけですよね？
32 ：名無しさん必死だな：2005/07/07(木) 16:23:41 ID:xwndrQzn
CELLは、座標変換（3DCG）や掛け算（ワークステーション）では使用するが、
PCのアプリでは使用しない浮動小数点計算が得意なんだよ。
PCのアプリでは使用しない浮動小数点計算が得意なんだよ。
技術的な話ができないのならVSスレに行けば良し。
ID:oycdOqFPが面白すぎる件について
でも、PC用にも問題ないでしょ。なんといってもパワーPCの3.2GHｚなわけだから
Windowsと言うOS、ドライバの部分でのロス
PCアーキテクチャのロスも含まれるでしょ。
CS機の効率の良い理由には。
PCアーキテクチャのロスも含まれるでしょ。
CS機の効率の良い理由には。
> 実際には２００MHｚとかありえないわけで。
いやいや。それぐらい、昨今のCPUがキャッシュミスのペナルティで止まってる時間は
意外に長いのです。そのボトルネックの解消を試みたのがSPEのLSとDMA。
いやいや。それぐらい、昨今のCPUがキャッシュミスのペナルティで止まってる時間は
意外に長いのです。そのボトルネックの解消を試みたのがSPEのLSとDMA。
キャッシュ通さなくてもベースクロックの４００～１０３３とかで動かせるんですが･･･
DRAMはレイテンシがあるでしょ。データ出せといってすぐ出てくるわけじゃない。
というか「メインメモリはCPUよりかなり遅い」ということがいいたかっただけなので、
200MHzという数字にはあまりこだわらないでいただけると有難く。
というか「メインメモリはCPUよりかなり遅い」ということがいいたかっただけなので、
200MHzという数字にはあまりこだわらないでいただけると有難く。
PPCがGCに採用されてそこそこ性能発揮できているので
悪くはないと思った。
それがいくら３コアであろうと開発者は意地でも最適化してくる
でしょ。問題はわけのわからないCPU,cell
あとゲーム機になるとめちゃくちゃレイヤーが薄くなり性能が
ケタ違いに上がると思ったら大間違い
PS2はほとんど640x480の処理してないし箱は640x480で精一杯
その当時のハッタリベンチ
http://www.watch.impress.co.jp/mobile/column/ps2/2000/03/14/comp.jpg
悪くはないと思った。
それがいくら３コアであろうと開発者は意地でも最適化してくる
でしょ。問題はわけのわからないCPU,cell
あとゲーム機になるとめちゃくちゃレイヤーが薄くなり性能が
ケタ違いに上がると思ったら大間違い
PS2はほとんど640x480の処理してないし箱は640x480で精一杯
その当時のハッタリベンチ
http://www.watch.impress.co.jp/mobile/column/ps2/2000/03/14/comp.jpg
>>22
その辺の話題は、CELL スレの 34 か 35 辺りで出た。
100倍というのは FFT 処理の時で、その IBM のプレゼン資料は、
http://www.beyond3d.com/forum/viewtopic.php?t=23845&sid=b5addcbd654a97e434ffd98af6358cc3
で見れるよ。
その辺の話題は、CELL スレの 34 か 35 辺りで出た。
100倍というのは FFT 処理の時で、その IBM のプレゼン資料は、
http://www.beyond3d.com/forum/viewtopic.php?t=23845&sid=b5addcbd654a97e434ffd98af6358cc3
で見れるよ。
んで、結局100倍差が発生するケースってのは・・・
>>43
メモリの速度に引っ張られるわけですよね。
今つかってるPCはメモリクロック４００MHｚなんで４００MHｚ相当になる、と。
SPEは3.2GでLSも3.2Gで動作ですか？
DMAでデータを書き戻し・読み取りで発生するストールは小さいにしてもあるわけですし、
ストリームだとデータの再利用が薄い分、キャッシュの効果が出にくいと思うんですが。
なんか初心者丸出しの質問ばっかりで申し訳ないんですが・・・。
ROMってた方が良いですかね、やっぱり。
>>43
メモリの速度に引っ張られるわけですよね。
今つかってるPCはメモリクロック４００MHｚなんで４００MHｚ相当になる、と。
SPEは3.2GでLSも3.2Gで動作ですか？
DMAでデータを書き戻し・読み取りで発生するストールは小さいにしてもあるわけですし、
ストリームだとデータの再利用が薄い分、キャッシュの効果が出にくいと思うんですが。
なんか初心者丸出しの質問ばっかりで申し訳ないんですが・・・。
ROMってた方が良いですかね、やっぱり。
なんで今更FFTベンチを知らない奴が居るんだこのスレに・・・
FFTってキャッシュ速度に影響されやすいベンチだろ
> DMAでデータを書き戻し・読み取りで発生するストールは小さいにしてもあるわけですし、
その遅延はダブルバッファで隠蔽できる。片方でDMAがメインメモリと読み書きしつつ
もう片方でコアが計算。
その遅延はダブルバッファで隠蔽できる。片方でDMAがメインメモリと読み書きしつつ
もう片方でコアが計算。
高速フーリエ変換 【FFT】
1965年にベル研究所のJames W. Cooley氏とJohn W. Tukey氏が考案した、
離散的フーリエ変換と逆変換を高速に計算する手法。
画像や音声、映像などのマルチメディアデータの処理で多用される 重要なアルゴリズムである。
大規模FFT演算の実行性能をライバル社の3.2GHzのCPU・PCシステムで実行比較。
ttp://img126.echo.cx/img126/634/slide150on.jpg
キモはやはりアルゴリズムとメモリアクセスにあるそうな。
1965年にベル研究所のJames W. Cooley氏とJohn W. Tukey氏が考案した、
離散的フーリエ変換と逆変換を高速に計算する手法。
画像や音声、映像などのマルチメディアデータの処理で多用される 重要なアルゴリズムである。
大規模FFT演算の実行性能をライバル社の3.2GHzのCPU・PCシステムで実行比較。
ttp://img126.echo.cx/img126/634/slide150on.jpg
キモはやはりアルゴリズムとメモリアクセスにあるそうな。
フーリエ変換ってゲームであんまり使わないような気がするんだけど･･･。
>>48
なるほど・・・。
つか、Gekkoにもロックドキャッシュがあったかと思うんですが、小さいなりに同等なことができるって事すかね。
となると、箱○やレボでも出来ておかしくない気が。
>>48
なるほど・・・。
つか、Gekkoにもロックドキャッシュがあったかと思うんですが、小さいなりに同等なことができるって事すかね。
となると、箱○やレボでも出来ておかしくない気が。
>>49
SRAMは元々互換性維持によるプログラムの負担減らす為、
性能犠牲にして自動化してキャッシュとなったんだけど。
CELLは単一ハードって事で性能重視のプログラマブル化したから。
ここら辺最適化すれば単純なスペック以上の差が出るんだろうな。
SRAMは元々互換性維持によるプログラムの負担減らす為、
性能犠牲にして自動化してキャッシュとなったんだけど。
CELLは単一ハードって事で性能重視のプログラマブル化したから。
ここら辺最適化すれば単純なスペック以上の差が出るんだろうな。
まあ、intelにかなわない理由はただ一つ、Windows互換じゃないから。
appleが採用しない最大の理由は、ノート向きじゃないから。
appleが採用しない最大の理由は、ノート向きじゃないから。
フーリエ変換は まさに画像・動画のエンコだね。
この分野では文字通り ケタ外れに速い予感・・
あー エンコカード出せーーっ！！
この分野では文字通り ケタ外れに速い予感・・
あー エンコカード出せーーっ！！
まだわけのわからないことやってんのか
フーリエ変換でエンコが速いならなぜPen4が
普及した？
そのベンチはappleがG3やG4の時にやっていたペテンベンチ
に近いものがある
フーリエ変換でエンコが速いならなぜPen4が
普及した？
そのベンチはappleがG3やG4の時にやっていたペテンベンチ
に近いものがある
>>54が任天堂信者なのは理解出来た
>>29
君は既に自分で答えに近づいている。
> それにPCアプリなんてそんな複雑な計算するわけでもない
そう。複雑な計算をしなければCellの力は意味が無い。
既存のアーキテクチャのCPUで十分だし向いている。
性能が必要な複雑な計算を必要とする時に、
そのタイトループをSPEに移して最適化する事がCellのキモなわけ。
そうすればFFTのベンチやMPEG2同時48本再生のように力を発揮する。
既存のコードをそのまま走らせて高速化するわけじゃないからね。
君は既に自分で答えに近づいている。
> それにPCアプリなんてそんな複雑な計算するわけでもない
そう。複雑な計算をしなければCellの力は意味が無い。
既存のアーキテクチャのCPUで十分だし向いている。
性能が必要な複雑な計算を必要とする時に、
そのタイトループをSPEに移して最適化する事がCellのキモなわけ。
そうすればFFTのベンチやMPEG2同時48本再生のように力を発揮する。
既存のコードをそのまま走らせて高速化するわけじゃないからね。
oycdOqFPはどちらかと言えば痴漢に見える
> フーリエ変換でエンコが速いならなぜPen4が
>普及した？
Intelの政治力。あとPentium4はエンコードにおいて速いCPUとされてるよ。
特にSSE2/SSE3なんかに最適化されたソフトではAMDよりも速い。
今の時点のCellに対して、既に市場投入されて数年経過して十分枯れているCPUを
持ち出しても仕方ないだろ。君は議論をする前に、自分の論理の破綻に気付け。
>普及した？
Intelの政治力。あとPentium4はエンコードにおいて速いCPUとされてるよ。
特にSSE2/SSE3なんかに最適化されたソフトではAMDよりも速い。
今の時点のCellに対して、既に市場投入されて数年経過して十分枯れているCPUを
持ち出しても仕方ないだろ。君は議論をする前に、自分の論理の破綻に気付け。
>>54
ん？
MPEG動画やJPEG画像は ひとまとまりの画素データに対して
複雑なフーリエ変換を行い、その後 量子化してデータサイズを減らすんだぞ。
P4もAthronも このフーリエ変換処理に演算能力を費やし、エンコに膨大な時間がかかるのだ。
＞フーリエ変換でエンコが速いならなぜPen4が普及した？
悪いが、何を言ってるのか全く意味不明・・
ん？
MPEG動画やJPEG画像は ひとまとまりの画素データに対して
複雑なフーリエ変換を行い、その後 量子化してデータサイズを減らすんだぞ。
P4もAthronも このフーリエ変換処理に演算能力を費やし、エンコに膨大な時間がかかるのだ。
＞フーリエ変換でエンコが速いならなぜPen4が普及した？
悪いが、何を言ってるのか全く意味不明・・
単にx86系だったからだろ
> なんで Intel CPU は普及して、DEC の Alpha は駄目だったんでしょうね。
ボリュームマジック。Alphaには開発コストを正当化できるだけの用途がなかった。
CellもPS3の需要があってこそ開発が可能だった。
ボリュームマジック。Alphaには開発コストを正当化できるだけの用途がなかった。
CellもPS3の需要があってこそ開発が可能だった。
[email protected]と [email protected]では カタログスペックには15～20倍程度の差しかないのに、
例えばマルチメディア処理の典型であるFFT演算などで ここまでの大差が開いたのは
アルゴリズムもさることながら、やはりメモリアクセスによる無駄・ボトルネックを
徹底的に低減するアーキテクチャを採ったからではないか。
マルチメディア処理の申し子のようなCPUだとは言える。
ただ、その他のどんな処理でも速い、というわけでは無いのは当然。
「何を強めるか？何を捨てるか？」ってのが 設計段階で徹底的に考慮されたのだろう。
だから、オフィスPC用途には 多分向いて無い。
Macには・・ あるいは向いていたかもしれんが、
インテルには それに勝る魅力があったのだろう。
価格とか、供給能力とか、チップの絶え間ない高速化とか。
例えばマルチメディア処理の典型であるFFT演算などで ここまでの大差が開いたのは
アルゴリズムもさることながら、やはりメモリアクセスによる無駄・ボトルネックを
徹底的に低減するアーキテクチャを採ったからではないか。
マルチメディア処理の申し子のようなCPUだとは言える。
ただ、その他のどんな処理でも速い、というわけでは無いのは当然。
「何を強めるか？何を捨てるか？」ってのが 設計段階で徹底的に考慮されたのだろう。
だから、オフィスPC用途には 多分向いて無い。
Macには・・ あるいは向いていたかもしれんが、
インテルには それに勝る魅力があったのだろう。
価格とか、供給能力とか、チップの絶え間ない高速化とか。
社長秘書が美人だったとか
>>63
オフィス用途には無駄な機能の付いてない、素っ気無いPCが向いている。
OA機器に過ぎないPCがマルチメディア用途を飲み込もうとして肥大化
したが、結局はそれも頭打ち。今後は事務用途とマルチメディア用途で
二分化するだろう。
オフィス用途には無駄な機能の付いてない、素っ気無いPCが向いている。
OA機器に過ぎないPCがマルチメディア用途を飲み込もうとして肥大化
したが、結局はそれも頭打ち。今後は事務用途とマルチメディア用途で
二分化するだろう。
ベンチ一つじゃ駄目だ
appleのようにフォトショのぼかしフィルタ一つだけで
比べても駄目だ
どうせ性能はどっこいどっこいだろうが
appleのようにフォトショのぼかしフィルタ一つだけで
比べても駄目だ
どうせ性能はどっこいどっこいだろうが
>>66
じゃあ、箱○のCPUでMPEG2の48本同時再生をやってみる必要があるな。
じゃあ、箱○のCPUでMPEG2の48本同時再生をやってみる必要があるな。
ベンチという一つの指標を無視するというのであれば、
他に根拠を持ってこないと意味が無い。
>どうせ性能はどっこいどっこいだろうが
無根拠にこういう事を言い出すのはVSスレ向き。
他に根拠を持ってこないと意味が無い。
>どうせ性能はどっこいどっこいだろうが
無根拠にこういう事を言い出すのはVSスレ向き。
西川善司の3Dゲームエクスタシー GeForce 7800 GTXのパイプラインを細かく見てみる（後編）
http://www.4gamer.net/specials/3de/050706_gf7800/002/050707_gf7800_02.shtml
http://www.4gamer.net/specials/3de/050706_gf7800/002/050707_gf7800_02.shtml
>>66
IBMの大規模FFTデモを
実際のアプリケーションの形で実演したのが
東芝のMPEG2再生デモ。
DVDサイズで48本、HDTVサイズで12本、同時デコード可能。
ベンチ１つではまだわからない、というのは同感だが、
では君は 何のベンチをして欲しい？
これは、というものがあれば示して欲しい。
IBMの大規模FFTデモを
実際のアプリケーションの形で実演したのが
東芝のMPEG2再生デモ。
DVDサイズで48本、HDTVサイズで12本、同時デコード可能。
ベンチ１つではまだわからない、というのは同感だが、
では君は 何のベンチをして欲しい？
これは、というものがあれば示して欲しい。
>>50
ロックして高速ローカルメモリとして使う事はできるかもしれませんが
メモリによるボトルネックが解消された場合は、純粋に処理能力の勝負になるわけで
そうなると理論値が高いほうが有利になる事はわかりますよね
つまりCellはボトルネックによる影響をできる限り減らして、高い演算性能を高いまま
有効活用できるように作られたと
ロックして高速ローカルメモリとして使う事はできるかもしれませんが
メモリによるボトルネックが解消された場合は、純粋に処理能力の勝負になるわけで
そうなると理論値が高いほうが有利になる事はわかりますよね
つまりCellはボトルネックによる影響をできる限り減らして、高い演算性能を高いまま
有効活用できるように作られたと
普通の人間の考え方
Pen3 なかなかいい
PenM 15wの消費電力の割にはすごい計算能力だ
Pen4 電力食いずぎ性能もイマイチ
これをすべてほぼ同じ性能になるようにクロックアップ
Pen3 電力食いすぎ、熱すぎ
PenM 期待はずれ
Pen4 電力食いずぎ性能もイマイチ
つまりCPUなんて所詮は消費電力なんかと大いに相関関係があって
intelはPen4を捨てPen3のプロセス技術を上げたのやPenMOC版投入して
これるだろう。だがそういうことはしないしできない
なぜなら夢のようなコアなんて存在せずcellもまさにそれ
クロック分の仕事しかできない
Pen3 なかなかいい
PenM 15wの消費電力の割にはすごい計算能力だ
Pen4 電力食いずぎ性能もイマイチ
これをすべてほぼ同じ性能になるようにクロックアップ
Pen3 電力食いすぎ、熱すぎ
PenM 期待はずれ
Pen4 電力食いずぎ性能もイマイチ
つまりCPUなんて所詮は消費電力なんかと大いに相関関係があって
intelはPen4を捨てPen3のプロセス技術を上げたのやPenMOC版投入して
これるだろう。だがそういうことはしないしできない
なぜなら夢のようなコアなんて存在せずcellもまさにそれ
クロック分の仕事しかできない
>>74
どこから突っ込んでやったらいいんだろう・・・ｗ
どこから突っ込んでやったらいいんだろう・・・ｗ
＞＞これをすべてほぼ同じ性能になるようにクロックアップ
Cellでこれをやると、同じ性能になるようにクロック”ダウン” だよな？
すると、「低消費電力なのに、高性能」ってことになるのでは。
Cellの電力が低いとは言わんが、性能/電力比は 凄い優秀だと思われ・・
P4よりずっと低いと思われる消費電力で、遥かに高いマルチメディア性能。
・・・つーか、一体何が言いたいのだ？( ´ω`)
Cellでこれをやると、同じ性能になるようにクロック”ダウン” だよな？
すると、「低消費電力なのに、高性能」ってことになるのでは。
Cellの電力が低いとは言わんが、性能/電力比は 凄い優秀だと思われ・・
P4よりずっと低いと思われる消費電力で、遥かに高いマルチメディア性能。
・・・つーか、一体何が言いたいのだ？( ´ω`)
>>75
NGワード含むのでスルーが正解かとw
NGワード含むのでスルーが正解かとw
Σ（￣□￣；） うわやばい！ コイツ”相関関係”だッ！！
逃げろっ！
|彡
逃げろっ！
|彡
意味がわからないかなぁ
クロックも上げれて性能/電力比もめちゃくちゃよくて
低発熱なんていうCPUなんて存在しないんだよ
クロックも上げれて性能/電力比もめちゃくちゃよくて
低発熱なんていうCPUなんて存在しないんだよ
>>74は性能＝消費電力と強引にこじつけてアーキテクチャの優劣を無視して
CellをPentium4と「どっこいどっこい理論」に持ち込みたがっているようだけど
Intelの各CPUの比較を出してきた時点でアーキテクチャ無視のこじつけを
いきなり自分で破綻させてしまってるぞｗ
CellをPentium4と「どっこいどっこい理論」に持ち込みたがっているようだけど
Intelの各CPUの比較を出してきた時点でアーキテクチャ無視のこじつけを
いきなり自分で破綻させてしまってるぞｗ
>>73
純粋にクロック辺りの命令効率ってCellの方が箱360やレボより高いんですかね。
SPEが沢山乗ってるCellの方が高そうな気はするんですが、PPCベースである以上
大きな差は出ないと思うんですけど。
flopsでは箱360の倍近くPS3lの方が上回っていましたけど、３コア対1コア+7ですから
キャッシュの恩恵が大きいなら数値上もう少し離れても良いような気がするんですが。
純粋にクロック辺りの命令効率ってCellの方が箱360やレボより高いんですかね。
SPEが沢山乗ってるCellの方が高そうな気はするんですが、PPCベースである以上
大きな差は出ないと思うんですけど。
flopsでは箱360の倍近くPS3lの方が上回っていましたけど、３コア対1コア+7ですから
キャッシュの恩恵が大きいなら数値上もう少し離れても良いような気がするんですが。
RSX is G70, 90 nanometre tweaked
http://theinquirer.net/?article=24445
ATI taped out R520, again
http://theinquirer.net/?article=24446
http://theinquirer.net/?article=24445
ATI taped out R520, again
http://theinquirer.net/?article=24446
つか、CellってPen4より性能高くて低発熱だから、性能/電力比はめちゃくちゃ良いと思うけど…
>>82
とりあえずこれくらいは読んでおけ。
ttp://pc.watch.impress.co.jp/docs/2005/0218/kaigai158.htm
ttp://pc.watch.impress.co.jp/docs/2005/0225/kaigai159.htm
>Cellが取ったようなヘテロジニアスマルチコアでストリーム型データ処理の性能を高めるアプローチは、
>飛躍的にパフォーマンス/電力を向上させることができる。既存のPC向けCPUのアプローチでは、この効率には追いつけない。
>現状のx86系CPUで、Cellの256GFLOPSを達成できるマルチコアCPUを現状で作ろうとしたら、膨大な消費電力、
>それこそ1,000WクラスのCPUになってしまうだろう。
みんな呆れてるし。
とりあえずこれくらいは読んでおけ。
ttp://pc.watch.impress.co.jp/docs/2005/0218/kaigai158.htm
ttp://pc.watch.impress.co.jp/docs/2005/0225/kaigai159.htm
>Cellが取ったようなヘテロジニアスマルチコアでストリーム型データ処理の性能を高めるアプローチは、
>飛躍的にパフォーマンス/電力を向上させることができる。既存のPC向けCPUのアプローチでは、この効率には追いつけない。
>現状のx86系CPUで、Cellの256GFLOPSを達成できるマルチコアCPUを現状で作ろうとしたら、膨大な消費電力、
>それこそ1,000WクラスのCPUになってしまうだろう。
みんな呆れてるし。
Pen4は例え PPCも絡んでくるけど
設計に無駄がなくてもathlonのように
糞みたいに発熱するCPUもある
CPUは発熱すると安定動作ができなくなるため
さらに電圧を上げなれければならない
そしてさらに発熱する
コア毎に性能/電力のベストな状態が存在する
設計に無駄がなくてもathlonのように
糞みたいに発熱するCPUもある
CPUは発熱すると安定動作ができなくなるため
さらに電圧を上げなれければならない
そしてさらに発熱する
コア毎に性能/電力のベストな状態が存在する
91 ：名無しさん必死だな：2005/07/07(木) 18:32:12 ID:BFQ0V07B
ttp://www.4gamer.net/news.php?url=/specials/3de/050706_gf7800/002/050707_gf7800_02.shtml
>ピクセルシェーダプログラムの実行が実質的にストールする（止まる）と，そのピクセルシェーダが別のピクセルの処理を行うようにスレッドは切り替えられるとのこと。
なんだ、G70もXenosと同じでテクスチャーフェッチのストールを無くすスケジュール機能を実装しているのね。
あらら箱信者が必死にXenosの優位性を語っていた部分が崩れた。
>ピクセルシェーダプログラムの実行が実質的にストールする（止まる）と，そのピクセルシェーダが別のピクセルの処理を行うようにスレッドは切り替えられるとのこと。
なんだ、G70もXenosと同じでテクスチャーフェッチのストールを無くすスケジュール機能を実装しているのね。
あらら箱信者が必死にXenosの優位性を語っていた部分が崩れた。
>>87
上のまとめ
RSXはnVIDIAに十分な時間を与えずに短期間でG70を転用。
しかし、XENOSとどっちが優れているかはまだ何とも言えない。
下のまとめ
ATi は2度目のR520の設計手直し。600MHz以上で駆動させることを目指している。
しかし、それでも90nmプロセスでの歩留まりがどうにも上がらない。
R500も同じプロセスだろう？
一体どうやって何百万個のXENOSをMSに供給できるというのか？
上のまとめ
RSXはnVIDIAに十分な時間を与えずに短期間でG70を転用。
しかし、XENOSとどっちが優れているかはまだ何とも言えない。
下のまとめ
ATi は2度目のR520の設計手直し。600MHz以上で駆動させることを目指している。
しかし、それでも90nmプロセスでの歩留まりがどうにも上がらない。
R500も同じプロセスだろう？
一体どうやって何百万個のXENOSをMSに供給できるというのか？
>>89
Cellの成功によって、現在のCellプロセッサ以外にもCell型のアプローチが広まる。
SPE型CPUコアを搭載し、Cellライクな構造を持ったCPUが、
現行Cell以外にも多数登場し始める。PowerPC G5クラスのリッチな
PowerPCコア＋SPEを搭載したMacintosh向けのCPUや、もっとシンプルな
PPEと4個程度のSPEを載せた廉価組み込み版などもありうるかもしれない
蹴られちゃった・・・
Cellの成功によって、現在のCellプロセッサ以外にもCell型のアプローチが広まる。
SPE型CPUコアを搭載し、Cellライクな構造を持ったCPUが、
現行Cell以外にも多数登場し始める。PowerPC G5クラスのリッチな
PowerPCコア＋SPEを搭載したMacintosh向けのCPUや、もっとシンプルな
PPEと4個程度のSPEを載せた廉価組み込み版などもありうるかもしれない
蹴られちゃった・・・
>>90
そうですか。それを前提としてあなたは何を言いたいのですか？
そうですか。それを前提としてあなたは何を言いたいのですか？
>>94
cell脂肪
cell脂肪
96 ：名無しさん必死だな：2005/07/07(木) 18:41:19 ID:fm/HWvJG
オオサンショウウオ２５６匹確認、兵庫県が保護対策委
http://www.yomiuri.co.jp/main/news/20050707i307.htm
http://www.yomiuri.co.jp/main/news/20050707i307.htm
256なんてキリのいい数字だからって張らないように。
>>84
CellのSPEはPPCベースじゃなく、完全に新しいアーキテクチャだよ
SPE1つあたりの処理能力理論値は 4要素x2演算x3.2G回＝25.6Gflops
CellのPPEは (4要素+2要素)x2演算＝38.4Gflops
PS3はPPE+SPEx7で 38.4+25.6ｘ7＝217.6≒218Gflops
XBOX360はPPEを3つ積んで 38.4x3＝115.2Gflops
Cellの設計ではSPE一つあたりではPPEで負けても、数を増やす事で演算能力を
強化する方向を選んだと
それから理論値にはキャッシュの効果は全く関係無いよ
CellのSPEはPPCベースじゃなく、完全に新しいアーキテクチャだよ
SPE1つあたりの処理能力理論値は 4要素x2演算x3.2G回＝25.6Gflops
CellのPPEは (4要素+2要素)x2演算＝38.4Gflops
PS3はPPE+SPEx7で 38.4+25.6ｘ7＝217.6≒218Gflops
XBOX360はPPEを3つ積んで 38.4x3＝115.2Gflops
Cellの設計ではSPE一つあたりではPPEで負けても、数を増やす事で演算能力を
強化する方向を選んだと
それから理論値にはキャッシュの効果は全く関係無いよ
>>91
既にGPUで○＞PS3なんて崩れてると思うが
既にGPUで○＞PS3なんて崩れてると思うが
>>920
実はR520はR500(Xenos)と同じかどうかまだ分かってないんだよね。
それにXenosはコア部分は2億ちょっとで、eDRAMが1億くらい占める。
が、eDRAMを搭載できないR520はコアだけで3億あると言われてる。
だからR420の進化系だという話もある。
実はR520はR500(Xenos)と同じかどうかまだ分かってないんだよね。
それにXenosはコア部分は2億ちょっとで、eDRAMが1億くらい占める。
が、eDRAMを搭載できないR520はコアだけで3億あると言われてる。
だからR420の進化系だという話もある。
> R500も同じプロセスだろう？
> 一体どうやって何百万個のXENOSをMSに供給できるというのか？
これは「大きなお世話」な気がするな…。違うチップなのに。
> 一体どうやって何百万個のXENOSをMSに供給できるというのか？
これは「大きなお世話」な気がするな…。違うチップなのに。
>>92の間違い。
>>100
もちつけｗ
もちつけｗ
R500はNECがつくる
>>95
そのCell型アプローチで作られたCPUがXBOX360に乗るわけじゃないでしょ
もしかしたらレボリューションには載るかもしれないけど ;-p
まぁ、Cell型が有効だと判明してから設計始めたんじゃ出てくるのは当分先だし
Cellの普及には影響しないだろうね
そのCell型アプローチで作られたCPUがXBOX360に乗るわけじゃないでしょ
もしかしたらレボリューションには載るかもしれないけど ;-p
まぁ、Cell型が有効だと判明してから設計始めたんじゃ出てくるのは当分先だし
Cellの普及には影響しないだろうね
Cellはやっぱり他のどこかが採用してくれないと
EEと同じ道を辿るような気がする。
EEと同じ道を辿るような気がする。
>>107
だから両者には”相関関うわ何をするqｗせｄｒｆｔｇｙふじこｌｐ；＠
だから両者には”相関関うわ何をするqｗせｄｒｆｔｇｙふじこｌｐ；＠
>>107
自分がダメだと思うからダメだと言ってる奴なんて所詮そんなものですよ
自分がダメだと思うからダメだと言ってる奴なんて所詮そんなものですよ
R520については悪い噂が聞こえてくるのに、R500については聞こえてこないなら、
Xenosの生産は順調、と考えるのが順当なんじゃないのかねえ。
ATI/TSMCの歩留り情報はダダ漏れ、という前提で。
Xenosの生産は順調、と考えるのが順当なんじゃないのかねえ。
ATI/TSMCの歩留り情報はダダ漏れ、という前提で。
>>98
互換性があるっぽいんでPPCベースかと思ってました。
>それから理論値にはキャッシュの効果は全く関係無いよ
そうでしたか。
てことは、キャッシュがガッツ次第で有効活用できるCell、
従来のCPU同様のキャッシュ効率の箱360のCPUでは、
Cellの方が実効値は落ちにくく、差はもうちょっと開くってことすかね。
つか、サイズの問題が出ると思いますけど、箱360タイプで各コアにロック可能なキャッシュと
DMAが付いた構成が出来れば、Cellより柔軟で実効値もそこそこなCPUになりませんかね。
理想論なんですけど。
互換性があるっぽいんでPPCベースかと思ってました。
>それから理論値にはキャッシュの効果は全く関係無いよ
そうでしたか。
てことは、キャッシュがガッツ次第で有効活用できるCell、
従来のCPU同様のキャッシュ効率の箱360のCPUでは、
Cellの方が実効値は落ちにくく、差はもうちょっと開くってことすかね。
つか、サイズの問題が出ると思いますけど、箱360タイプで各コアにロック可能なキャッシュと
DMAが付いた構成が出来れば、Cellより柔軟で実効値もそこそこなCPUになりませんかね。
理想論なんですけど。
>>106
とりあえず
Cell搭載のIBM製ブレードサーバーに
ttp://pc.watch.impress.co.jp/docs/2005/0629/mercury.htm
こんなのにも採用が決まってるから、EEみたいに外販できないって事は無いかと
・・・なんかcellスレの方がふさわしい気がしてきた
とりあえず
Cell搭載のIBM製ブレードサーバーに
ttp://pc.watch.impress.co.jp/docs/2005/0629/mercury.htm
こんなのにも採用が決まってるから、EEみたいに外販できないって事は無いかと
・・・なんかcellスレの方がふさわしい気がしてきた
oycdOqFPに構ってやってるあんたらやさしいね
R520とXbox360のGPU（R500）が全く違うものなら
なぜ「R5xx」という開発コードにしたのか疑問なところだが
>>110
R520は元々は春発表で7月には発売してるという話だったから量産→90nmプロセスでリーク電流
という話が出たんだろう
R500の量産開始は8月～9月ころだろうからR500自体の問題は出ようがないだろう
なぜ「R5xx」という開発コードにしたのか疑問なところだが
>>110
R520は元々は春発表で7月には発売してるという話だったから量産→90nmプロセスでリーク電流
という話が出たんだろう
R500の量産開始は8月～9月ころだろうからR500自体の問題は出ようがないだろう
ロック可能なキャッシュと言っても、コヒーレンシの問題とかもあるしなぁ。
mpeg2を48本同時デコード、縮小して、動いているサムネイルを並べて1080動画に
して見せているっていうのはcellが得意な処理だから出来ているだけで、
別の処理させたらPen4に余裕で敵わないなんていうことはないのかしら。
して見せているっていうのはcellが得意な処理だから出来ているだけで、
別の処理させたらPen4に余裕で敵わないなんていうことはないのかしら。
R520が苦労してるのはリーク電流。新設計＋９０nmプロセスを同時に行った為と言われる。
XenosのほうがTr数が少ないとはいえ新設計＋９０nmプロセスであることは同じある上生産数が
桁違いな以上、かなり量産に赤信号が灯っていると考えるのはおかしくないと思う。
XenosのほうがTr数が少ないとはいえ新設計＋９０nmプロセスであることは同じある上生産数が
桁違いな以上、かなり量産に赤信号が灯っていると考えるのはおかしくないと思う。
>>117
もちろん、SPEにオフロードしてない/できない処理は余裕で敵わない。
Cellの優位は、プログラム中のホットスポット(頻繁に実行する個所)を
SPE向けにC/C++で書き直す、というのが大前提。
もちろん、SPEにオフロードしてない/できない処理は余裕で敵わない。
Cellの優位は、プログラム中のホットスポット(頻繁に実行する個所)を
SPE向けにC/C++で書き直す、というのが大前提。
120 ：名無しさん必死だな：2005/07/07(木) 19:09:30 ID:GLxm2rCd
スティーブ・ジョブス氏がCELLプロセッサに失望
http://news.teamxbox.com/xbox/8504/Steve-Jobs-Not-Impressed-with-the-Cell-Processor/
New York Timesによると、アップル CEOのスティーブ・ジョブズ氏がPS3に搭載されるCELLプロセッサに厳しい評価を下したそうです。
ジョブズ氏はSCEの久多良木氏からCELLプロセッサ採用の働きかけを受けたものの、そのデザインに落胆し、PowerPCより低効率だと判断したとか。
アップルは今後インテルのCPUへ転換することを明らかにしています。
http://news.teamxbox.com/xbox/8504/Steve-Jobs-Not-Impressed-with-the-Cell-Processor/
New York Timesによると、アップル CEOのスティーブ・ジョブズ氏がPS3に搭載されるCELLプロセッサに厳しい評価を下したそうです。
ジョブズ氏はSCEの久多良木氏からCELLプロセッサ採用の働きかけを受けたものの、そのデザインに落胆し、PowerPCより低効率だと判断したとか。
アップルは今後インテルのCPUへ転換することを明らかにしています。
>>116
コヒーレンシの問題って、
・今の内容の書き戻し
・必要なデータの取り込み
・処理
の手順で行うから同一性に問題は出ないと思うけど・・。
ロックしないくなった時点でキャッシュのフラッシュすればいい訳だし。
って違う問題ですか？
コヒーレンシの問題って、
・今の内容の書き戻し
・必要なデータの取り込み
・処理
の手順で行うから同一性に問題は出ないと思うけど・・。
ロックしないくなった時点でキャッシュのフラッシュすればいい訳だし。
って違う問題ですか？
122 ：名無しさん必死だな：2005/07/07(木) 19:14:13 ID:GLxm2rCd
844 名前：Socket774[sage] 投稿日：2005/06/18(土) 00:03:04 ID:NywvqZB5
761 ：It's＠名無しさん ：2005/06/15(水) 10:24:51
>>757
まあその”箱360の倍以上”の処理能力はあくまで机上の理論値で
実使用上ではほぼありえない値でしかなく、アプリベースではその
処理能力の60%が遊んでしまっているお粗末なハード設計＆SDK
なんだけどな。しかもハードの仕様上の問題（欠陥と言っていい）
だから、今後もこれに関しては大幅な改善の見込みはなく、
現状の”使えるところだけを使う”アプリ設計を続けるしか手はない。
360についてはそういった無駄な設計（屋根の上に屋根を作るみたいな）がなく、
しかも開発環境がこなれているから、現時点でも労せずしてハードが持つ70～80%ほどの
パフォーマンスを発揮させられるし、ハードの解析がすすめばもう少し上乗せも可能、のはず。
レボにいたってはコンスタントにハードのパフォーマンスの80%以上を出せるみたいだぞ？
（任天堂に関してはノータッチなのであくまで伝聞）
761 ：It's＠名無しさん ：2005/06/15(水) 10:24:51
>>757
まあその”箱360の倍以上”の処理能力はあくまで机上の理論値で
実使用上ではほぼありえない値でしかなく、アプリベースではその
処理能力の60%が遊んでしまっているお粗末なハード設計＆SDK
なんだけどな。しかもハードの仕様上の問題（欠陥と言っていい）
だから、今後もこれに関しては大幅な改善の見込みはなく、
現状の”使えるところだけを使う”アプリ設計を続けるしか手はない。
360についてはそういった無駄な設計（屋根の上に屋根を作るみたいな）がなく、
しかも開発環境がこなれているから、現時点でも労せずしてハードが持つ70～80%ほどの
パフォーマンスを発揮させられるし、ハードの解析がすすめばもう少し上乗せも可能、のはず。
レボにいたってはコンスタントにハードのパフォーマンスの80%以上を出せるみたいだぞ？
（任天堂に関してはノータッチなのであくまで伝聞）
>>112
そんな感じじゃないかな
CellのSPE内のLSはL1キャッシュ並の速度、レイテンシで256KBもの容量積んでると
考えると、LS内で済む処理は実行性能が高そうと想像できるでしょ
リッチなコアを載せると消費電力やダイ上のサイズの問題が出てくるので、
性能が伸びる可能性はあるけれど、発熱や歩留まりが問題になる可能性が高い
Cellは単純に性能だけを考えた訳ではなく、生産性や消費電力の事も考慮にいれて
作られてるからね
そんな感じじゃないかな
CellのSPE内のLSはL1キャッシュ並の速度、レイテンシで256KBもの容量積んでると
考えると、LS内で済む処理は実行性能が高そうと想像できるでしょ
リッチなコアを載せると消費電力やダイ上のサイズの問題が出てくるので、
性能が伸びる可能性はあるけれど、発熱や歩留まりが問題になる可能性が高い
Cellは単純に性能だけを考えた訳ではなく、生産性や消費電力の事も考慮にいれて
作られてるからね
90nmプロセスでの生産について言えば、SONY+東芝だって3億トランジスタの巨大GPUを作った経験は
ないよね。EE+GSが5000万トランジスタぐらい?
Cellの第一世代はIBMの工場だろうし(歩留まり問題は過去にいろいろあった)、
綱渡りなのはどこも一緒じゃないかと。
ないよね。EE+GSが5000万トランジスタぐらい?
Cellの第一世代はIBMの工場だろうし(歩留まり問題は過去にいろいろあった)、
綱渡りなのはどこも一緒じゃないかと。
発売延期までして再設計したってことはATIの90nmプロセス世代のリーク電流に対する見通しが甘かったということなんだろう
これがATIの一つのチームの問題だったとするのなら良いんだが、
社内全体で認識が甘かったということだと、同じ90nmプロセスで新アーキのR500にも設計上で同じような問題が
とか言ってみたり
これがATIの一つのチームの問題だったとするのなら良いんだが、
社内全体で認識が甘かったということだと、同じ90nmプロセスで新アーキのR500にも設計上で同じような問題が
とか言ってみたり
スルーすべきだけど、ちょっとだけ
実行性能で理論値の40%出るならCellは 218x0.4≒87Gflops、
1コアはOS専用らしいXbox360CPUは 38.4x2x0.8≒61Gflops
って事でいいのかな？;-p
実行性能で理論値の40%出るならCellは 218x0.4≒87Gflops、
1コアはOS専用らしいXbox360CPUは 38.4x2x0.8≒61Gflops
って事でいいのかな？;-p
Cell,RSX共に90nm最大の問題であるリーク電流に関して対策をする必要が無い
これだけでもアドバンテージは大きいぞ
これだけでもアドバンテージは大きいぞ
歩留まりの話も荒れるからするな
360の「1コアOS専用」ってのは、
「システムコールでカーネルモードに遷移できるコアが特定コアだけ」
の意味だと思うんだけど、どうなのかなあ。
360のカーネルって、NTカーネルだけどXboxのものの拡張版っていうから、
おそらくSMP対応してないものでしょ(オーバーヘッドあるから)。
スレッドはコアに固定で割り付けられるんだと思うんだけれども。
「システムコールでカーネルモードに遷移できるコアが特定コアだけ」
の意味だと思うんだけど、どうなのかなあ。
360のカーネルって、NTカーネルだけどXboxのものの拡張版っていうから、
おそらくSMP対応してないものでしょ(オーバーヘッドあるから)。
スレッドはコアに固定で割り付けられるんだと思うんだけれども。
なんか、３６０は別に一コアをOS専用にしなくても良いって書き込みを見たが
よくわかんね
よくわかんね
MSは最近性能には口を閉ざしLiveを猛烈にプッシュしてる
どういう事情に置かれてるのかは推して測るべしだな
どういう事情に置かれてるのかは推して測るべしだな
>>123
なるほど、おかげさまで形が見えてきました。
Cellの肝になるSPEですけど、コード領域ってやっぱりLSに置かれるんですかね。
突っ込んだ話になりますけど、LSに置かれるとなるとプログラムの入れ替えは実行中の
位置に上書きできるとも思えないので、PPEからの入替えになると予想しますが、
そうなるとPPEに割り込みをかけて入替えリクエスト発行・SPEをスリープ・
DMA終了割り込みでSPE起動、みたいな手順が予想されますが、
入替えが頻発するような場合はPPEの処理が結構阻害されてしまうように思えます。
あくまで予想なんですけど、なんかパフォーマンスを引き出しにくい作りの様な気がします。
コード領域がメインメモリに取れるなら全然問題ないんですけど。
なるほど、おかげさまで形が見えてきました。
Cellの肝になるSPEですけど、コード領域ってやっぱりLSに置かれるんですかね。
突っ込んだ話になりますけど、LSに置かれるとなるとプログラムの入れ替えは実行中の
位置に上書きできるとも思えないので、PPEからの入替えになると予想しますが、
そうなるとPPEに割り込みをかけて入替えリクエスト発行・SPEをスリープ・
DMA終了割り込みでSPE起動、みたいな手順が予想されますが、
入替えが頻発するような場合はPPEの処理が結構阻害されてしまうように思えます。
あくまで予想なんですけど、なんかパフォーマンスを引き出しにくい作りの様な気がします。
コード領域がメインメモリに取れるなら全然問題ないんですけど。
>>130
普通に考えたら特定コアの1スレッドを、OS呼び出しでスレッド切り替えが起きる
オーバーヘッド回避の為に予約って事だと思うんですけどね
まぁ、>127は、ソースも無いネタにはネタレスって事で
普通に考えたら特定コアの1スレッドを、OS呼び出しでスレッド切り替えが起きる
オーバーヘッド回避の為に予約って事だと思うんですけどね
まぁ、>127は、ソースも無いネタにはネタレスって事で
アプリケーション用コード領域もダブルバッファにするとか。
そうすればDMAで自立的にコードとデータを取ってきて処理できる。
メモリのヤリクリは更に大変だけれど。
そうすればDMAで自立的にコードとデータを取ってきて処理できる。
メモリのヤリクリは更に大変だけれど。
こんなスレわざわざ貼るまでのソース
なんか必要ないよ
まじめに討論したきゃcellスレ逝けよ
もっとも過疎化が進んでいるがｗｗ
なんか必要ないよ
まじめに討論したきゃcellスレ逝けよ
もっとも過疎化が進んでいるがｗｗ
PPE用コードとSPE用コードは違うのでは？
>>134
ゲームプログラムに限定すると、SPEのスレッド（プログラム部）を
頻繁に入れ替えたりしないでしょ。複数のスレッドを置いとくことも出来るし。
（どのスレッドを実行するかの指定は必要だろうけど）
シェーダの動的分岐対応にしたって、シェーダの頻繁な入れ替えを
嫌う側面もあるわけで。
ゲームプログラムに限定すると、SPEのスレッド（プログラム部）を
頻繁に入れ替えたりしないでしょ。複数のスレッドを置いとくことも出来るし。
（どのスレッドを実行するかの指定は必要だろうけど）
シェーダの動的分岐対応にしたって、シェーダの頻繁な入れ替えを
嫌う側面もあるわけで。
141 ：名無しさん必死だな：2005/07/07(木) 19:44:03 ID:16+jBJbE
>>132
その話何所で聞いた？
その話何所で聞いた？
>>121
Xbox360 CPUの詳しい仕様を知らないのでなんともなんだけど、
そういう使い方が出来るものなの？
ある特定の実メモリと、L2キャッシュの領域それぞれを指定してロックするわけ？
>>130
SMP未対応のカーネルでどうやって3コア動かすの？
だとするとSMTも駄目なわけだし。
Xbox360 CPUの詳しい仕様を知らないのでなんともなんだけど、
そういう使い方が出来るものなの？
ある特定の実メモリと、L2キャッシュの領域それぞれを指定してロックするわけ？
>>130
SMP未対応のカーネルでどうやって3コア動かすの？
だとするとSMTも駄目なわけだし。
1コアOS専用なんてデマだろうに。大体OS専用って具体的に何するんだよ。
ちなみに俺が聞いたのは問題の1コア2スレッドの内、
1スレッドはLIVEで、1スレッドはサウンド。
まあどっちにしろ開発者の裁量に任されてるだろうけど。
ちなみに俺が聞いたのは問題の1コア2スレッドの内、
1スレッドはLIVEで、1スレッドはサウンド。
まあどっちにしろ開発者の裁量に任されてるだろうけど。
スレッド数は多ければよい
なぜならうまくやれば性能低下が防げるから
N64はCPUでサウンドをまるまる処理したので
実行性能が低下しまくった
なぜならうまくやれば性能低下が防げるから
N64はCPUでサウンドをまるまる処理したので
実行性能が低下しまくった
>>137
概ね134の認識は間違ってないと。
スレッド切り替えを抑える形となると、定型処理で回すのが現実的なんですかね。
モーション周りや、カリング・コリジョン・シェーダーとかかなと。
この辺りのデータって物によっては256KBじゃすまないしと思うんですが、分割して
取り込んでいくとデータの扱いが結構大変な気がしますが・・・。
なんか、妄想するととキリがないようなｗ
概ね134の認識は間違ってないと。
スレッド切り替えを抑える形となると、定型処理で回すのが現実的なんですかね。
モーション周りや、カリング・コリジョン・シェーダーとかかなと。
この辺りのデータって物によっては256KBじゃすまないしと思うんですが、分割して
取り込んでいくとデータの扱いが結構大変な気がしますが・・・。
なんか、妄想するととキリがないようなｗ
>>144
それはサウンドで１スレッド使ったって事ですやん
それはサウンドで１スレッド使ったって事ですやん
> SMP未対応のカーネルでどうやって3コア動かすの？
カーネルへの遷移が許された(ハードウェア)スレッドが一つあって、
それ以外の5つのスレッドは基本的にOSの管理外になる、ということ。
もちろん、コンテキストスイッチや排他制御はOSが面倒みてくれるだろうけど、
SMPカーネルのように、カーネル内でスレッドが複数動いて、複数のI/Oを
同時に処理したりはできないよ、と。
カーネルへの遷移が許された(ハードウェア)スレッドが一つあって、
それ以外の5つのスレッドは基本的にOSの管理外になる、ということ。
もちろん、コンテキストスイッチや排他制御はOSが面倒みてくれるだろうけど、
SMPカーネルのように、カーネル内でスレッドが複数動いて、複数のI/Oを
同時に処理したりはできないよ、と。
>>145
そこをいかにうまくやるかがcellプログラミングのキモでしょ。
まぁ256KBもあれば大抵のことはやれるとおもう。
ゲームプログラマというのは4KBとか8KBでも何とかしてきた人達なので。
そこをいかにうまくやるかがcellプログラミングのキモでしょ。
まぁ256KBもあれば大抵のことはやれるとおもう。
ゲームプログラマというのは4KBとか8KBでも何とかしてきた人達なので。
840XEも悪くないCPUなんだろうけどね
現段階では最適化できてないんでしょ
現段階では最適化できてないんでしょ
>>134
SPEが実行できるのはLS上のプログラムだけです
SPEは単体でDMA経由のメインメモリアクセスできるので、基本的にはPPEに割り込みを
かける必要は無いでしょう
で、確かに入れ替えの頻発するような状況だと性能低下は避けられないと思いますが
そのような状況にならないように利用するのがCellの有効な使い方でしょうね
それからプログラムの有名な法則として10－90の法則というのがありまして、
>たいていのプログラムの場合、プログラムの一部分（約10％）が
>ほとんどの処理時間（約90%）を消費しているという法則だ。
なので、重い処理の部分だけを抜き出せば256KBで十分と設計者が判断したのでしょう
SPEが実行できるのはLS上のプログラムだけです
SPEは単体でDMA経由のメインメモリアクセスできるので、基本的にはPPEに割り込みを
かける必要は無いでしょう
で、確かに入れ替えの頻発するような状況だと性能低下は避けられないと思いますが
そのような状況にならないように利用するのがCellの有効な使い方でしょうね
それからプログラムの有名な法則として10－90の法則というのがありまして、
>たいていのプログラムの場合、プログラムの一部分（約10％）が
>ほとんどの処理時間（約90%）を消費しているという法則だ。
なので、重い処理の部分だけを抜き出せば256KBで十分と設計者が判断したのでしょう
SMP対応カーネルっていっても、カーネル内プリエンプションするとは限らないわけで。
FreeBSDやLinuxの古いバージョンなんかはカーネル内はジャイアントロックしかなく、
カーネル内では複数のスレッドは走らない構造だったしね。
今のバージョンでは粒度の細かいロックを使うようになってプリエンプションできるようになったけどね。
それにカーネル内プリエンプションする方が、
リソース待ち時間の隠蔽できるしいいと思うんだけどな。
> それ以外の5つのスレッドは基本的にOSの管理外になる、ということ。
システムコールとか使えなくなるし、ちょっと厳しいような。
FreeBSDやLinuxの古いバージョンなんかはカーネル内はジャイアントロックしかなく、
カーネル内では複数のスレッドは走らない構造だったしね。
今のバージョンでは粒度の細かいロックを使うようになってプリエンプションできるようになったけどね。
それにカーネル内プリエンプションする方が、
リソース待ち時間の隠蔽できるしいいと思うんだけどな。
> それ以外の5つのスレッドは基本的にOSの管理外になる、ということ。
システムコールとか使えなくなるし、ちょっと厳しいような。
>>143
218 名前：名無しさん必死だな[sage] 投稿日：2005/06/20(月) 20:52:14 ID:CLMnUZDz
>>211
NEの記事じゃないかな。
7個に決まる前は最悪のケースも考慮して6個も検討してた模様。
それよりもこっちの内容の方が気になる。これもNEの記事からなんだが、
箱がPPE3つの内1つをWinNTカーネルに基づくOSに割り当てて、
残り2つをゲームプログラマに開放する。(ってことは既に既出だが)
それに関連して、PS3でもｸﾀによれば「SPEのうち6つをゲーム
プログラム用に確保した上で、残り1つを専用OSの実行に使う」
んだって。このOSのPPEで動くOSとの関連は不明とのこと。
218 名前：名無しさん必死だな[sage] 投稿日：2005/06/20(月) 20:52:14 ID:CLMnUZDz
>>211
NEの記事じゃないかな。
7個に決まる前は最悪のケースも考慮して6個も検討してた模様。
それよりもこっちの内容の方が気になる。これもNEの記事からなんだが、
箱がPPE3つの内1つをWinNTカーネルに基づくOSに割り当てて、
残り2つをゲームプログラマに開放する。(ってことは既に既出だが)
それに関連して、PS3でもｸﾀによれば「SPEのうち6つをゲーム
プログラム用に確保した上で、残り1つを専用OSの実行に使う」
んだって。このOSのPPEで動くOSとの関連は不明とのこと。
>>145
その辺の処理だとデータのアクセスがシーケンシャルアクセスに近くなるので、
ダブルバッファとDMA裏読みでなんとかなるかと
完全にランダムですと厳しいでしょうけど、その場合はSPEが2スレッド動かせるのを
利用して片方の読み込み遅延中はもう片方が処理をすれば、DMAレイテンシを
隠蔽できますし
その辺の処理だとデータのアクセスがシーケンシャルアクセスに近くなるので、
ダブルバッファとDMA裏読みでなんとかなるかと
完全にランダムですと厳しいでしょうけど、その場合はSPEが2スレッド動かせるのを
利用して片方の読み込み遅延中はもう片方が処理をすれば、DMAレイテンシを
隠蔽できますし
カーネルをSMP対応させると排他制御が複雑になり、オーバーヘッドが無視できないほどある。
サーバ用OSはSMP機でカーネル処理をスケールさせなきゃいけないのでそれも仕方ないが、
ゲーム機なら大半がユーザプログラムの演算処理だから、カーネルはシンプルなままでいい。
でないとリアルタイム処理なんてできない。
360でも、マルチコアで増えた分のスレッドは、
演算処理をメインスレッドからオフロードさせる用途で使うのが主ではないかと。
サーバ用OSはSMP機でカーネル処理をスケールさせなきゃいけないのでそれも仕方ないが、
ゲーム機なら大半がユーザプログラムの演算処理だから、カーネルはシンプルなままでいい。
でないとリアルタイム処理なんてできない。
360でも、マルチコアで増えた分のスレッドは、
演算処理をメインスレッドからオフロードさせる用途で使うのが主ではないかと。
>>152
いや、実行中のSPEのコードの入替えははすがに無理じゃないのか、という意味です。
自分を上書きした後に先頭から実行できる機構があれば出来そうですが。
>>150
さすがに昔とはやっていることの難易度も大きさも違うと思いますが、
その手のカリカリチューニングがPS2で嫌われていた、敷居をあげていたところが
あると思うんですけどね。
そこまでやらずともスペックを引き出せるのが理想ですし。
>>156
モーションってシーケンシャルに出来ます？
階層を行ったりきたりするので入替えは慎重にやらないといけないと思うんですが。
いや、そういうデータは扱わなければ良いのか。
いや、実行中のSPEのコードの入替えははすがに無理じゃないのか、という意味です。
自分を上書きした後に先頭から実行できる機構があれば出来そうですが。
>>150
さすがに昔とはやっていることの難易度も大きさも違うと思いますが、
その手のカリカリチューニングがPS2で嫌われていた、敷居をあげていたところが
あると思うんですけどね。
そこまでやらずともスペックを引き出せるのが理想ですし。
>>156
モーションってシーケンシャルに出来ます？
階層を行ったりきたりするので入替えは慎重にやらないといけないと思うんですが。
いや、そういうデータは扱わなければ良いのか。
>>157
PS3なんかはPCのゲームとの互換性みたいなものを気にしなくていいけど、
PCプラットフォームのゲームだとSMP/SMT対応のカーネルを使って、
どのスレッドもシステムコールの発行ができるようにするよね。
Xbox360がシングルなカーネル上で動くとなるとPCとの互換性が無くなるでしょ。
そういう戦略をPS3側が取るならわかるんだけど、Xbox360でやるんかな？
PS3なんかはPCのゲームとの互換性みたいなものを気にしなくていいけど、
PCプラットフォームのゲームだとSMP/SMT対応のカーネルを使って、
どのスレッドもシステムコールの発行ができるようにするよね。
Xbox360がシングルなカーネル上で動くとなるとPCとの互換性が無くなるでしょ。
そういう戦略をPS3側が取るならわかるんだけど、Xbox360でやるんかな？
>>159
PCでも1メインスレッド+複数演算スレッド という使い方が主になるのではないかと。
http://www.itmedia.co.jp/pcupdate/articles/0507/01/news030.html
PCでも1メインスレッド+複数演算スレッド という使い方が主になるのではないかと。
http://www.itmedia.co.jp/pcupdate/articles/0507/01/news030.html
>>158
SPE内のプログラムが自分で、自分のコードの一部を入れ替えする事は、不可能じゃ
無いとは思いますけど、やる意味があるんでしょうか・・・？
モーションと言われても色々あるのでどのモーションかにもよるとは思いますけど、
LSの256KBあれば、数キャラ分のデータは乗り切りるんじゃないでしょうか？
SPE内のプログラムが自分で、自分のコードの一部を入れ替えする事は、不可能じゃ
無いとは思いますけど、やる意味があるんでしょうか・・・？
モーションと言われても色々あるのでどのモーションかにもよるとは思いますけど、
LSの256KBあれば、数キャラ分のデータは乗り切りるんじゃないでしょうか？
単にコードが大きすぎてLSに収まらないなら、それはPPEで実行する性質のものだと思う。
耐タンパ性のために、外部から遮断されたSPEが、暗号化された実行コードを自己書換えして
復号する、というのはあるだろうね。セキュリティのための仕掛けは非公開でいろいろ
用意されていそうだが。
耐タンパ性のために、外部から遮断されたSPEが、暗号化された実行コードを自己書換えして
復号する、というのはあるだろうね。セキュリティのための仕掛けは非公開でいろいろ
用意されていそうだが。
>>160
それぞれの組み方はともかく、MSが明示的にスレッドの扱いを限定しておかないといけないわけだけど、
現状のPC方面でそういう通達とかでも出てる？
無ければ、互換性に苦しむハメになると思うのだけど。
まあXbox360がそういう方向性でいくとなれば、
大分Cellとの親和性の高い考え方な気はするな。
それぞれの組み方はともかく、MSが明示的にスレッドの扱いを限定しておかないといけないわけだけど、
現状のPC方面でそういう通達とかでも出てる？
無ければ、互換性に苦しむハメになると思うのだけど。
まあXbox360がそういう方向性でいくとなれば、
大分Cellとの親和性の高い考え方な気はするな。
>>161
よく考えたら7つもあるからほかのSPEに任せればいいんですね。
稼働率を上げまくるなら、手が空き次第プログラム入れ替えてでも
ぶん回すのかなーと思ってたんですが、ちょっと頭が足らなかった感じです。
コードは個別に３２KB程度でもキャッシュを持ってメインメモリから実行できれば
かなり柔軟になる気がするんですけど、諸々あって今の形になったんだろうなー。
よく考えたら7つもあるからほかのSPEに任せればいいんですね。
稼働率を上げまくるなら、手が空き次第プログラム入れ替えてでも
ぶん回すのかなーと思ってたんですが、ちょっと頭が足らなかった感じです。
コードは個別に３２KB程度でもキャッシュを持ってメインメモリから実行できれば
かなり柔軟になる気がするんですけど、諸々あって今の形になったんだろうなー。
東芝はCELL開発環境にこんな仕組みを実装
■256KBのLS容量にが収まらないことが考えられるため、「SPEオーバーレイ」と呼ぶ仕組みを実装。
プログラムやデータを主記憶上に配置し、その一部の関数だけを実行時にLSに動的にロードして実行する。
SPEオーバーレイにおける関数の入れ替えは、DMAコントローラが行う。
■256KBのLS容量にが収まらないことが考えられるため、「SPEオーバーレイ」と呼ぶ仕組みを実装。
プログラムやデータを主記憶上に配置し、その一部の関数だけを実行時にLSに動的にロードして実行する。
SPEオーバーレイにおける関数の入れ替えは、DMAコントローラが行う。
「Powerは今、ユビキタスな状態になっている」――日本IBM、
“Power Everywhere Forum 2005”を開催
http://ascii24.com/news/i/topi/article/2005/07/07/656844-000.html
デュアルコア版の『PowerPC 970MP』
http://ascii24.com/news/i/topi/article/2005/07/07/images/images779599.jpg
“Power Everywhere Forum 2005”を開催
http://ascii24.com/news/i/topi/article/2005/07/07/656844-000.html
デュアルコア版の『PowerPC 970MP』
http://ascii24.com/news/i/topi/article/2005/07/07/images/images779599.jpg
cellは忘れ去られました
cellもpowerなんだが。
PPEは無しで、SPE10個のほうがゲーム機に向いていると思う。
ヘテロコアのPPEにあたる部分って単に互換をとるだけでこれ以上性能が上がる見込みがないのにじゃまなだけ。
ヘテロコアのPPEにあたる部分って単に互換をとるだけでこれ以上性能が上がる見込みがないのにじゃまなだけ。
今、IBMがHD世代AV機器向けに、家電各社に売り込みしているのはCELLじゃなくて360CPUの1.6～2.4Ghz版だからなぁ
CELL家電はソニーからしか出ないだろうね
CELL家電はソニーからしか出ないだろうね
>>171
（ ´,_ゝ`）
（ ´,_ゝ`）
どこの各社だよｗ
>>170
何と互換とるんだよｗ
何と互換とるんだよｗ
>>170
SPEが直接メインメモリ参照できたらね。
ゲームプログラムでストリーム処理可できる箇所は
多いものの、１００％というのは絶対に有り得んし。
PPE2つ、SPE4つ辺りが個人的にベストだと思う。
SPEが直接メインメモリ参照できたらね。
ゲームプログラムでストリーム処理可できる箇所は
多いものの、１００％というのは絶対に有り得んし。
PPE2つ、SPE4つ辺りが個人的にベストだと思う。
ちなみに、LSが512KBなら 同じチップ面積を維持しながら SPE 6個、
LSが1MBなら 4個くらいの計算になります。
いかが？
LSが1MBなら 4個くらいの計算になります。
いかが？
>>180
＞いや、メインメモリぐらいDMAで参照できるって。
知ってますがな。
＞直接メインメモリ参照
だから、直接と断わってるわけで。
DMAで参照する限り、広範囲のランダムアクセスは厳しいだろうから
連続したデータのストリーム処理中心になるだろうということ。
＞いや、メインメモリぐらいDMAで参照できるって。
知ってますがな。
＞直接メインメモリ参照
だから、直接と断わってるわけで。
DMAで参照する限り、広範囲のランダムアクセスは厳しいだろうから
連続したデータのストリーム処理中心になるだろうということ。
>>178
そのまま搭載、とか
そのまま搭載、とか
>>165
SPEオーバーレイか、関数管理の仕組はどうなっているのかな
例のタグ単位管理でも関数のサイズ制限を越える場合はどうするのか
実行中のコードスワップはしないだろうし、処理結果による分岐処理で関数
コールする場合DMAのロード待ちが有ると、その間は他のSPE回って事か
XDR大忙しだね
PPE -> XDR <- DMA -> LS (256KB) <- SPE x7
SPEオーバーレイか、関数管理の仕組はどうなっているのかな
例のタグ単位管理でも関数のサイズ制限を越える場合はどうするのか
実行中のコードスワップはしないだろうし、処理結果による分岐処理で関数
コールする場合DMAのロード待ちが有ると、その間は他のSPE回って事か
XDR大忙しだね
PPE -> XDR <- DMA -> LS (256KB) <- SPE x7
メモリアクセスは妥協だ。
スパコンのようにはいかんよ。
今ある分で我慢するしかない。
Cellは まだマシな方だろう・・
Cellも苦しいが、 xenonなどもっと悲惨だし。
スパコンのようにはいかんよ。
今ある分で我慢するしかない。
Cellは まだマシな方だろう・・
Cellも苦しいが、 xenonなどもっと悲惨だし。
970MPの1.6GHz時熱設計消費電力は出ないのか
れぼりゅーしょーん
れぼりゅーしょーん
>>185
PPC970は電力効率が悪いから、レボはPPC750ベースで来るような気がちょっとする
PPC970は電力効率が悪いから、レボはPPC750ベースで来るような気がちょっとする
187 ：名無しさん必死だな：2005/07/07(木) 23:01:44 ID:1P+4WlnU
せっかく帰ってきたのに、ID:oycdOqFPたんが居なくなってて(´･ω･｀)
oycdOqFPじゃないけど、ここは「次世代機テクノロジー」スレなのに、FFTベンチやMPEG2同時48本再生がうれしい理由って何？
ここがCELLスレなら理解出来るけど、次世代ゲームってムービー沢山同時に再生したり動画エンコードするものなのか？
ここがCELLスレなら理解出来るけど、次世代ゲームってムービー沢山同時に再生したり動画エンコードするものなのか？
そういうことができる、ってのも次世代機のテクノロジーに含まれるからじゃない？
その性能がゲームにどう役立てられるかを考えるのも作る人の仕事でしょ。
その性能がゲームにどう役立てられるかを考えるのも作る人の仕事でしょ。
使い方次第で文字通り桁外れの性能を叩き出せる面白いプロセッサであることは確か。
次世代機テクノロジーの話題としては中心に位置するといっていい。
次世代機テクノロジーの話題としては中心に位置するといっていい。
>>188
＞FFTベンチやMPEG2同時48本再生がうれしい理由って何？
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
＞FFTベンチやMPEG2同時48本再生がうれしい理由って何？
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
それって任天堂いわく、「新しい遊び」が提供できるかもってことじゃないの。
どこかのスレの住人みたいに「俺のとこのがすごい」「いや、すごいのはこっちだ」と
言い合ってても水掛け論なので、定量的な指標でお互いの性能を評価しようとすると
まずはMIPS, FLOPSというようなピーク性能であり、次にFFTやMPEGのアルゴリズムを
実際に実行することになるわけだ。実際にそれを使うかどうかではなくて。
Cellだけでなく、他のハードウェアでも結果が公表されれば、もっと理解が深まるのだが。
言い合ってても水掛け論なので、定量的な指標でお互いの性能を評価しようとすると
まずはMIPS, FLOPSというようなピーク性能であり、次にFFTやMPEGのアルゴリズムを
実際に実行することになるわけだ。実際にそれを使うかどうかではなくて。
Cellだけでなく、他のハードウェアでも結果が公表されれば、もっと理解が深まるのだが。
PCと違って不利な側は公表しないだろうね。
PS3は、PS3-Linuxも出るわけだし、発売後はPS3-Linux上でのベンチなんかも出るだろうね。
PS3は、PS3-Linuxも出るわけだし、発売後はPS3-Linux上でのベンチなんかも出るだろうね。
>>191
音声は浮動少数はつかわんですよ。
頂点･光源もCPUは最近はやら無くても良いんじゃない？GPUの方が速いし。
物理演算は恩気ありまくり。超ありまくり。
他にもいろいろ恩恵あるでしょ。
というかスペックがあげれるならあげれる方が良いし。
釣られて定価が上がりまくっても困るけど。
音声は浮動少数はつかわんですよ。
頂点･光源もCPUは最近はやら無くても良いんじゃない？GPUの方が速いし。
物理演算は恩気ありまくり。超ありまくり。
他にもいろいろ恩恵あるでしょ。
というかスペックがあげれるならあげれる方が良いし。
釣られて定価が上がりまくっても困るけど。
PS3のCPUは不良品だということをお忘れなく
つーか、xenonに関して何の情報も入ってこないのがアレなんだよ・・
どーしたIBM。
さっさと情報を出せ
どーしたIBM。
さっさと情報を出せ
>ゲームプログラムだと恩恵有りまくりですよ。
その割に擬似コードの一つも見たこと無いので、本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
役に立つか確証は無いが、すごいテクノロジーなのは確定なのでスレ的にはオッケーって事なのかな。
CELLスレだと結構懐疑的に見られてるので、えらい温度差あるなぁと思って質問した次第です。
もしかしてスレ的にCELLを褒め称えてる訳ではなくウザイ痴漢がいるので、相対的にそう見えるだけなのか？
その割に擬似コードの一つも見たこと無いので、本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
役に立つか確証は無いが、すごいテクノロジーなのは確定なのでスレ的にはオッケーって事なのかな。
CELLスレだと結構懐疑的に見られてるので、えらい温度差あるなぁと思って質問した次第です。
もしかしてスレ的にCELLを褒め称えてる訳ではなくウザイ痴漢がいるので、相対的にそう見えるだけなのか？
Cellは外販もする汎用CPUだけど、360 CPUは特定製品向けの組込CPU扱いで、
少なくとも製品が出るまではIBMからはほとんど情報でないのかも。
少なくとも製品が出るまではIBMからはほとんど情報でないのかも。
>>195
＞音声は浮動少数はつかわんですよ。
次世代機では物理音源処理にも挑戦するでしょ。
5.1chの為の音の移動にも使われるだろうし。
LSに置いた波形メモリの多重合成や、圧縮された曲データの
ストリーミング解凍だけでは、3GHzが勿体無い。
＞音声は浮動少数はつかわんですよ。
次世代機では物理音源処理にも挑戦するでしょ。
5.1chの為の音の移動にも使われるだろうし。
LSに置いた波形メモリの多重合成や、圧縮された曲データの
ストリーミング解凍だけでは、3GHzが勿体無い。
自作版のcellスレも見てみるといい
>>199
＞その割に擬似コードの一つも見たこと無いので、
＞本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
E3カンファレンスで実演されてましたがな。
それとも、CorC++コードそのものを公開しろと？
＞その割に擬似コードの一つも見たこと無いので、
＞本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
E3カンファレンスで実演されてましたがな。
それとも、CorC++コードそのものを公開しろと？
>それとも、CorC++コードそのものを公開しろと？
デモのソースコードをリークしろとは言ってないですが。
今までとパラダイムの違うアーキテクチャなんだから、擬似コードでも良いので処理の流れが判らないと信用できないと思うのが普通じゃない？
他人の言うことそのまま信じてマンセーするのは盲信だよ。
デモのソースコードをリークしろとは言ってないですが。
今までとパラダイムの違うアーキテクチャなんだから、擬似コードでも良いので処理の流れが判らないと信用できないと思うのが普通じゃない？
他人の言うことそのまま信じてマンセーするのは盲信だよ。
×SSESSE
○SSE
ダブった。
○SSE
ダブった。
今までとパラダイムの違うアーキティクチャだから、みんな日経NEの特集とか
読んで、とっとと頭に入れておく努力をしちゃうんだな。
読んで、とっとと頭に入れておく努力をしちゃうんだな。
>>204
＞処理の流れが判らない
処理の流れ。
http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
＞他人の言うことそのまま信じてマンセーするのは盲信だよ。
プログラム知識がない人には、本当か嘘かの検証すら出来ませんよ。
念のために聞いとくけど、プログラマさんですよね？
＞処理の流れが判らない
処理の流れ。
http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
＞他人の言うことそのまま信じてマンセーするのは盲信だよ。
プログラム知識がない人には、本当か嘘かの検証すら出来ませんよ。
念のために聞いとくけど、プログラマさんですよね？
>>209
プログラマじゃないからこういう頓珍漢な事いうんでは。
プログラマじゃないからこういう頓珍漢な事いうんでは。
>>195
AVアンプとかではアナデバの浮動小数点DSPがよく使われてるよ。
CreamWare というソフトシンセ用 PCI DSP ボードにも使われてるし。
音源や音声自体を自動生成する音ゲーとか出たりするんじゃない?
くまうた for PS3 とか。
AVアンプとかではアナデバの浮動小数点DSPがよく使われてるよ。
CreamWare というソフトシンセ用 PCI DSP ボードにも使われてるし。
音源や音声自体を自動生成する音ゲーとか出たりするんじゃない?
くまうた for PS3 とか。
213 ：( ・)3 Σ・ )：2005/07/08(金) 00:10:22 ID:M7yql5Cl
0.1の表現すら誤差の出る固定小数点ｻｲｺｰ
>処理の流れ。
>http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
いやいや、これSPEのスケジューリングで処理の流れじゃないでしょ。
たとえばAIだったらαβ法をどうSPEで実装するとか、そういう話なんだけど。
だめ？
>http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
いやいや、これSPEのスケジューリングで処理の流れじゃないでしょ。
たとえばAIだったらαβ法をどうSPEで実装するとか、そういう話なんだけど。
だめ？
メディア処理系だと精度がある基準レベルで保てれば言い訳で
浮動小数点が速い処理系であればそれでやればいいし
浮動小数点が速い処理系であればそれでやればいいし
俺も見てみたいですね．擬似コードでいいから．
209がプログラマみたいなんで，期待．
209がプログラマみたいなんで，期待．
■後藤弘茂のWeekly海外ニュース■
対照的なアーキテクチャでぶつかるNVIDIAとATI
http://pc.watch.impress.co.jp/docs/2005/0708/kaigai196.htm
対照的なアーキテクチャでぶつかるNVIDIAとATI
http://pc.watch.impress.co.jp/docs/2005/0708/kaigai196.htm
評価関数がSPEで実装可能かどうか(適切かどうか)によると思われる。
データもfloatで持つのかな。
ADPCMのような圧縮方式はFP8みたいなのでやんのかな。
あるのかしらんけど。
さすがに次世代機とはいえ無圧縮で持つのはあまりに無駄かと思うんだけど。
PS3/360の音周りって何か情報来てましたっけ？
ADPCMのような圧縮方式はFP8みたいなのでやんのかな。
あるのかしらんけど。
さすがに次世代機とはいえ無圧縮で持つのはあまりに無駄かと思うんだけど。
PS3/360の音周りって何か情報来てましたっけ？
擬似コードうるさいけど、SPEはC言語ですから…
256KBに収まるように普通に書けばよし。
IBM製製コンパイラが勝手に最適化してくれます。
256KBに収まるように普通に書けばよし。
IBM製製コンパイラが勝手に最適化してくれます。
>256KBに収まるように普通に書けばよし。
メインメモリをDMAでしかアクセス出来ないんじゃなかったっけ？
コンパイラの最適化でレイテンシ隠してくれるの？
メインメモリをDMAでしかアクセス出来ないんじゃなかったっけ？
コンパイラの最適化でレイテンシ隠してくれるの？
>>214
SPEをフル活用するぐらいだから、相当深い木になるでしょ。
上から3レベルまでのノードはPPE、それ以下はSPE。
PPE⇔SPEだけmessage boxで通信すれば普通にできるじゃん。
SPEをフル活用するぐらいだから、相当深い木になるでしょ。
上から3レベルまでのノードはPPE、それ以下はSPE。
PPE⇔SPEだけmessage boxで通信すれば普通にできるじゃん。
>>222
探索問題なんて並列化が容易なんだから、SPE内で99.9%は収まる。
残り0.1%ぐらいレイテンシが発生したところでどうだというんだ。
SPEがダメと言いたいなら、もっと並列化が難しいものを持ってきなさい。
探索問題なんて並列化が容易なんだから、SPE内で99.9%は収まる。
残り0.1%ぐらいレイテンシが発生したところでどうだというんだ。
SPEがダメと言いたいなら、もっと並列化が難しいものを持ってきなさい。
>何でSPEへのAIコード実装例まで、SCEとIBMが示さなきゃならないの？
SCEやIBMなんて一言も言ってないんだけど・・・。
SCEやIBMなんて一言も言ってないんだけど・・・。
>>214
例えば、本格的なゲーム制作者がわざわざコードを書きに来るわけが無い。
Cellでアイデアを実現してみようという人も自分の種をわざわざ明らかにはしない。
じゃあどういう状況ならコードが出てくるのか。
それは自分から動く人がいて初めて出てくる。
他力本願な奴が「コードかいてくれよ～」なんて言っても誰も書かんよ。
これは2chの他の色々な板・スレでもそうだと思うけどね。
○○を作るスレみたいなのをいくつか漁ってみ？
前向きに、こういうコードなら動きそうだけどどう？とかそういうのなら、
気まぐれで誰かがアドバイスをくれたり、同レベルの奴が、
俺ならこう書くかもみたいなのをだしてくれるかもしれない。
とりあえず今のままなら、間違いなく誰も書きはしない。メリットないし。
例えば、本格的なゲーム制作者がわざわざコードを書きに来るわけが無い。
Cellでアイデアを実現してみようという人も自分の種をわざわざ明らかにはしない。
じゃあどういう状況ならコードが出てくるのか。
それは自分から動く人がいて初めて出てくる。
他力本願な奴が「コードかいてくれよ～」なんて言っても誰も書かんよ。
これは2chの他の色々な板・スレでもそうだと思うけどね。
○○を作るスレみたいなのをいくつか漁ってみ？
前向きに、こういうコードなら動きそうだけどどう？とかそういうのなら、
気まぐれで誰かがアドバイスをくれたり、同レベルの奴が、
俺ならこう書くかもみたいなのをだしてくれるかもしれない。
とりあえず今のままなら、間違いなく誰も書きはしない。メリットないし。
下位の関数（激しく重い処理）として実装するならば、256KBもあれば十分だと思われ。
>>224
こっちは例としてAI処理が出された理由が解らんよ。
SPEで標準的なプログラミングモデルは
データはダブルバッファ、片方のバッファを処理してる間に
DMAで、もう片方のバッファを入れ替える。その繰り返し。
これで、どのような実装例出さなきゃ納得いかないの？
こっちは例としてAI処理が出された理由が解らんよ。
SPEで標準的なプログラミングモデルは
データはダブルバッファ、片方のバッファを処理してる間に
DMAで、もう片方のバッファを入れ替える。その繰り返し。
これで、どのような実装例出さなきゃ納得いかないの？
>>188は他人に対してばかり根拠を求めて
自分の意見の根拠やら正当性については完全に目を逸らしてるなｗ
自分の意見の根拠やら正当性については完全に目を逸らしてるなｗ
232 ：( ・)3 Σ・ )：2005/07/08(金) 00:35:39 ID:rzGt2iIQ
AIがお題で出てくるのは変だが、実のところSPEでも結構イケる、が正解
αβ以前に探索は節の合流を判別する為にグローバルなハッシュを参照できないといけないから
SPEじゃむちゃくちゃ非効率。そんなことも分からないアホしかCELLﾏﾝｾｰ派にはいないようだな。
SPEじゃむちゃくちゃ非効率。そんなことも分からないアホしかCELLﾏﾝｾｰ派にはいないようだな。
>>233
そのグローバル値をLSに一緒に投げ込まなければいけないってこと？
そのグローバル値をLSに一緒に投げ込まなければいけないってこと？
例えば、次のＡ、Ｂの関数で、
main() {
関数Ａ() // 1ns
関数Ｂ() // 1ms
}
処理時間が↑だとするならば、関数Ｂ()をSPEに割り当てればよい。
仮に関数Ｂ()がSPEに展開できない大きなｻｲｽﾞだとすれば、
関数Ｂ() {
関数Ｃ() // 10ns
関数Ｄ() // 90ns
}
関数Ｂ内の関数Ｄ()をSPEに割り当てるだけ。
結局ﾎﾞﾄﾙﾈｯｸになる箇所自体は、それほど大きな容量を必要としないと思われ。
main() {
関数Ａ() // 1ns
関数Ｂ() // 1ms
}
処理時間が↑だとするならば、関数Ｂ()をSPEに割り当てればよい。
仮に関数Ｂ()がSPEに展開できない大きなｻｲｽﾞだとすれば、
関数Ｂ() {
関数Ｃ() // 10ns
関数Ｄ() // 90ns
}
関数Ｂ内の関数Ｄ()をSPEに割り当てるだけ。
結局ﾎﾞﾄﾙﾈｯｸになる箇所自体は、それほど大きな容量を必要としないと思われ。
関数Ｄ（） // 990ns
の間違いだ。。orz
の間違いだ。。orz
コアの同期通信が必要だと高くつきそうだが。
>自分の意見の根拠やら正当性については完全に目を逸らしてるなｗ
本当にCELLがゲーム向けかどうか疑問に思うことがこのスレ的には問題って事？
本当にCELLがゲーム向けかどうか疑問に思うことがこのスレ的には問題って事？
そもそもグローバルに散らばったメモリにランダムアクセスしようと思ったら、どんなＣＰＵでもメインメモリアクセス速度以上は出ないと思われ。
ＬＳに乗らないってことはキャッシュにも乗らないでしょ？
キャッシュに乗るレベルなら>238が言うように探索タスクの並列化して細分したＬＳに対し裏でＤＭＡぶん回しとく方法でキャッシュと同等の効果は出る。
自動じゃないけどね。
ＬＳに乗らないってことはキャッシュにも乗らないでしょ？
キャッシュに乗るレベルなら>238が言うように探索タスクの並列化して細分したＬＳに対し裏でＤＭＡぶん回しとく方法でキャッシュと同等の効果は出る。
自動じゃないけどね。
ここは「次世代機テクノロジー」スレなのに、FFTベンチやMPEG2同時48本再生がうれしい理由って何？
↓
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
↓
その割に擬似コードの一つも見たこと無いので、本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
今までとパラダイムの違うアーキテクチャなんだから、擬似コードでも良いので処理の流れが判らないと信用できないと思うのが普通じゃない？
（根拠言ってくれないと同意求められても無理だから）
↓
処理の流れ。
http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
↓
いやいや、これSPEのスケジューリングで処理の流れじゃないでしょ。
たとえばAIだったらαβ法をどうSPEで実装するとか、そういう話なんだけど。
（いきなり強引な論点ずらし乙！）
↓
何でSPEへのAIコード実装例まで、SCEとIBMが示さなきゃならないの？
↓
SCEやIBMなんて一言も言ってないんだけど・・・。
（じゃあ誰が示すんだよｗｗ）
↓
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
↓
その割に擬似コードの一つも見たこと無いので、本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
今までとパラダイムの違うアーキテクチャなんだから、擬似コードでも良いので処理の流れが判らないと信用できないと思うのが普通じゃない？
（根拠言ってくれないと同意求められても無理だから）
↓
処理の流れ。
http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
↓
いやいや、これSPEのスケジューリングで処理の流れじゃないでしょ。
たとえばAIだったらαβ法をどうSPEで実装するとか、そういう話なんだけど。
（いきなり強引な論点ずらし乙！）
↓
何でSPEへのAIコード実装例まで、SCEとIBMが示さなきゃならないの？
↓
SCEやIBMなんて一言も言ってないんだけど・・・。
（じゃあ誰が示すんだよｗｗ）
>>241
どう使えるのかはまだわからないけど、その機能がゲームに生かされる可能性がないわけじゃない。
CELLの能力を知るうえで参考となるデータが出されたことに対して、
ぐだぐだケチつけるのも野暮だと思うけどなあ。
どう使えるのかはまだわからないけど、その機能がゲームに生かされる可能性がないわけじゃない。
CELLの能力を知るうえで参考となるデータが出されたことに対して、
ぐだぐだケチつけるのも野暮だと思うけどなあ。
246 ：( ・)3 Σ・ )：2005/07/08(金) 00:49:29 ID:rzGt2iIQ
検索より評価関数の処理効率を突っ込んだほうが
>>242
常時グローバルなメモリをランダムアクセスは必要ない。
ただし必要な時は必要だというだけ。
SPEでどう解決するかというネタなら意味はあるが
SPEで全く問題ないと言い張るアホにはあきれるばかりだ。
常時グローバルなメモリをランダムアクセスは必要ない。
ただし必要な時は必要だというだけ。
SPEでどう解決するかというネタなら意味はあるが
SPEで全く問題ないと言い張るアホにはあきれるばかりだ。
>>236
関数ＢやＤが使うメモリがSPE内で収まってるなら効果的だと思うんだけど、他のグローバルなデータ参照してるとマズくない？
一度ロードしたメモリを無駄なく処理に使うのがSPEの真骨頂だと考えると、そうとうモジュール化できないと難しそうだね。
ある意味オブジェクト指向的なのかな。
関数ＢやＤが使うメモリがSPE内で収まってるなら効果的だと思うんだけど、他のグローバルなデータ参照してるとマズくない？
一度ロードしたメモリを無駄なく処理に使うのがSPEの真骨頂だと考えると、そうとうモジュール化できないと難しそうだね。
ある意味オブジェクト指向的なのかな。
局所性が少ないファイル検索アルゴリズムをSPEで解決できるか？
→議論の余地あり
探索問題のような局所性があって、すでにいくつも並列化アルゴリズムが実現されてるもの
→議論の余地なく全く問題なし
→議論の余地あり
探索問題のような局所性があって、すでにいくつも並列化アルゴリズムが実現されてるもの
→議論の余地なく全く問題なし
最近、ｸﾞﾛｰﾊﾞﾙ変数ってあんまり使わんので考慮してなかった。
>>244
まとめてくれてありがとう。
擬似コードって書いてるのにまさかスケジューリングの話が出るとは思ってなかったもので。
私がコードって書いてるから、具体的な例としてαβ法とか出したんだけど、論点ずらしてるように見えましたか。
すまんかった。
まとめてくれてありがとう。
擬似コードって書いてるのにまさかスケジューリングの話が出るとは思ってなかったもので。
私がコードって書いてるから、具体的な例としてαβ法とか出したんだけど、論点ずらしてるように見えましたか。
すまんかった。
プログラマは与えられた条件の中で、その都度効率的なアプローチを模索するのが仕事だから、
「SPEはAIに向いているか」という大雑把すぎる議論は無意味な気がする。
とりあえずSPEは、演算量多め、メモリアクセス少なめの問題が得意であるということしか
わからないわけだし。
「SPEはAIに向いているか」という大雑把すぎる議論は無意味な気がする。
とりあえずSPEは、演算量多め、メモリアクセス少なめの問題が得意であるということしか
わからないわけだし。
彼はむしろメモリアクセス多い時の方がすごい。
ダブルバッファで交互に。休みなし。
あたしもう死ぬかと思った。
ダブルバッファで交互に。休みなし。
あたしもう死ぬかと思った。
255 ：( ・)3 Σ・ )：2005/07/08(金) 01:01:12 ID:rzGt2iIQ
さすがSuperPenisErection
>>245-255
ﾜﾛﾀ
ﾜﾛﾀ
257 ：名無しさん必死だな：2005/07/08(金) 01:01:54 ID:oQ6uEJ6P
>253
メモリアクセスは多くても問題ないでしょ。
ランダムアクセスが多いとスケジューリングがめんどいってだけじゃ。
メモリアクセスは多くても問題ないでしょ。
ランダムアクセスが多いとスケジューリングがめんどいってだけじゃ。
ＳＰＥのおかげでスレを昇天してしまいました。
>>217
＞＞R520を含め、ATIの今後の新世代GPUは、Unified-Shader構成を継承すると見られている。
R520は これまで分離シェーダのままで行く、
とか言われてなかった？ 統合シェーダだったのか？
しかし、両者の言い分は面白いなー
同じゲームの中でも場面によって頂点シェーダとピクセルシェーダの負荷が違ってくる。
だから、統合シェーダだ、と。 成程、納得できる。
一方で、統合シェーダにも”無駄”はある、と。
全てのシェーダがピクセル処理で占有されることなど決して無い。
にもかかわらず、統合シェーダでは 全てのシェーダにピクセル処理機能を載せないとならない。
１つのシェーダに何もかもやらせようとすると、かえって”器用貧乏”、トランジスタの無駄になる、と。
成程・・ これも納得できる。
ま、結局は実行性能で決着が付くんだろうけど・・
＞＞R520を含め、ATIの今後の新世代GPUは、Unified-Shader構成を継承すると見られている。
R520は これまで分離シェーダのままで行く、
とか言われてなかった？ 統合シェーダだったのか？
しかし、両者の言い分は面白いなー
同じゲームの中でも場面によって頂点シェーダとピクセルシェーダの負荷が違ってくる。
だから、統合シェーダだ、と。 成程、納得できる。
一方で、統合シェーダにも”無駄”はある、と。
全てのシェーダがピクセル処理で占有されることなど決して無い。
にもかかわらず、統合シェーダでは 全てのシェーダにピクセル処理機能を載せないとならない。
１つのシェーダに何もかもやらせようとすると、かえって”器用貧乏”、トランジスタの無駄になる、と。
成程・・ これも納得できる。
ま、結局は実行性能で決着が付くんだろうけど・・
>>253
＞メモリアクセス少なめの問題が得意であるということしか
「メモリのランダムアクセス少なめ」ですな。
連続したアドレスのメモリアクセスは
LSダブルバッファによるレイテンシ隠蔽まで含めたら得意とも言えるし。
＞メモリアクセス少なめの問題が得意であるということしか
「メモリのランダムアクセス少なめ」ですな。
連続したアドレスのメモリアクセスは
LSダブルバッファによるレイテンシ隠蔽まで含めたら得意とも言えるし。
>SPEがAIに向いてないと、Cellはゲーム機向けじゃないということ？
いや、前のスレでAIも物理演算もガシガシいけるみたいな話題が出てたので、例にあげただけ。
物理演算の方はコードにするとどうなるか良くわかってないので、例にあげませんでした。
いや、前のスレでAIも物理演算もガシガシいけるみたいな話題が出てたので、例にあげただけ。
物理演算の方はコードにするとどうなるか良くわかってないので、例にあげませんでした。
>>250
＞局所性が少ないファイル検索アルゴリズム
通常、ある程度以上規模の大きいデータベースは
いきなり総当たりで片っ端からデータ舐めていくのではなくて
データベース構築時に実データとは別に検索キー別の
もっとコンパクトな検索テーブルを複数生成してるのでは？
グーグルとか片っ端から全データ舐めてるわきゃ無いと思うが。
＞局所性が少ないファイル検索アルゴリズム
通常、ある程度以上規模の大きいデータベースは
いきなり総当たりで片っ端からデータ舐めていくのではなくて
データベース構築時に実データとは別に検索キー別の
もっとコンパクトな検索テーブルを複数生成してるのでは？
グーグルとか片っ端から全データ舐めてるわきゃ無いと思うが。
263 ：名無しさん必死だな：2005/07/08(金) 01:06:48 ID:6rDmKiwg
ttp://techon.nikkeibp.co.jp/article/NEWS/20050707/106552/
CELLの応用例＞プリンタ（w
ショボイ、あまりにもショボ過ぎる。
プリンタに乗せる程度の低性能チップでゲーム機を作るなよ
CELLの応用例＞プリンタ（w
ショボイ、あまりにもショボ過ぎる。
プリンタに乗せる程度の低性能チップでゲーム機を作るなよ
>>259
ATIのチェック入りのbeyond3dの記事でR520は統合シェーダじゃないと言ってる
んだから後藤の壮大な勘違いでしょ。前も後藤はNVIDIAも統合シェーダかも、
とか言ってたしなんかずれてる。
ATIのチェック入りのbeyond3dの記事でR520は統合シェーダじゃないと言ってる
んだから後藤の壮大な勘違いでしょ。前も後藤はNVIDIAも統合シェーダかも、
とか言ってたしなんかずれてる。
>>261
＞AIも物理演算もガシガシいけるみたいな
元ネタは多分これですな。
http://spin.s2c.ne.jp/stoday/stoday06.html
＞また、束縛条件の解消の過程も並列化できます。
＞つまり、物理シミュとAIの処理は並列処理の要素が明確であり
＞並列処理に向いています。
この文章で想定されてるAI処理の中身は知らないけど。
（AI処理は種類多すぎなんで）
＞AIも物理演算もガシガシいけるみたいな
元ネタは多分これですな。
http://spin.s2c.ne.jp/stoday/stoday06.html
＞また、束縛条件の解消の過程も並列化できます。
＞つまり、物理シミュとAIの処理は並列処理の要素が明確であり
＞並列処理に向いています。
この文章で想定されてるAI処理の中身は知らないけど。
（AI処理は種類多すぎなんで）
G70はシェーダーを走らせないと無駄だという意味なんだよ
たとえば現行箱でもシェーダーバリバリのソフトなんて何がある？
たとえば現行箱でもシェーダーバリバリのソフトなんて何がある？
後藤タンの肩をもつ訳じゃないが、ATIの型番のつけ方にも問題ある気がする
>LSダブルバッファによるレイテンシ隠蔽まで含めたら得意とも言えるし。
LSダブルバッファって256Kを半分に割るって事ですか？
そういえばDMAでのアクセスのオーバーヘッドってどんなもんなんでしょうね？
CELLをオープンソースにするって言うから、そのうち詳しい資料とか出るのかな。
>ショボイ、あまりにもショボ過ぎる。
プリンタなめたらいかんぜよ。
LSダブルバッファって256Kを半分に割るって事ですか？
そういえばDMAでのアクセスのオーバーヘッドってどんなもんなんでしょうね？
CELLをオープンソースにするって言うから、そのうち詳しい資料とか出るのかな。
>ショボイ、あまりにもショボ過ぎる。
プリンタなめたらいかんぜよ。
プリンタ馬鹿にしてる奴はプリンタ屋に謝れｗ
R500とR520じゃ 確かに同じ系統だと思われても仕方が無いよな・・
実際はどうなんだろ？
実際はどうなんだろ？
プリンタごときが馬鹿みたいに消費電力食うようになったら終わりだな
メモリはともかく高速なCPUなんて必要ないんだよ
メモリはともかく高速なCPUなんて必要ないんだよ
統合ｼｪｰﾀﾞは高解像度にも対応しなきゃならないPCじゃまだ早いのは同意。
HDTV解像度がまだ普及しきれていないコンシューマだからできるものだね。
HDTV解像度がまだ普及しきれていないコンシューマだからできるものだね。
>>271
R400(キャンセルされたSM3.0対応チップ)とR420も違うわけで。
R400(キャンセルされたSM3.0対応チップ)とR420も違うわけで。
>>268
＞LSダブルバッファって256Kを半分に割るって事ですか？
最大、(256KB-プログラム)/2
バッファサイズはデータに対するSPEの処理量によって変わる。
60分の1秒で数十バイトしか処理できなければ、その倍しかいらん。
＞LSダブルバッファって256Kを半分に割るって事ですか？
最大、(256KB-プログラム)/2
バッファサイズはデータに対するSPEの処理量によって変わる。
60分の1秒で数十バイトしか処理できなければ、その倍しかいらん。
>>272
業務用のプリンターだと1000w余裕で超えてるんですが・・・
業務用のプリンターだと1000w余裕で超えてるんですが・・・
>>268
完全にストリーム的なシーケンシャルアクセスでいいなら、リングバッファでも良い
DMAはメインのスレッドの裏で動かして、必要な時に必要なデータがメモリ上に用意され
ている状態になりさえすれば、バッファ方式は何でも良いかと
完全にストリーム的なシーケンシャルアクセスでいいなら、リングバッファでも良い
DMAはメインのスレッドの裏で動かして、必要な時に必要なデータがメモリ上に用意され
ている状態になりさえすれば、バッファ方式は何でも良いかと
今のところ判明したCellの用途
SPE8個 WS、医療用画像処理機器
SPE7個 PS3
6個以下 HPの複合プリンタ
謎 トヨタの車載システム
4ヶ月前に仕様が公開されたばかりのチップなのに順調だな
SPE8個 WS、医療用画像処理機器
SPE7個 PS3
6個以下 HPの複合プリンタ
謎 トヨタの車載システム
4ヶ月前に仕様が公開されたばかりのチップなのに順調だな
R520はWGF2.0じゃないぞ
ちなみにWGF2.0はDirectX10のこと
ちなみにWGF2.0はDirectX10のこと
R1050とかつけてくれれば誰がみても統合シェーダってわかるのにな。
>>280
>DMAはメインのスレッドの裏で動かして、必要な時に必要なデータがメモリ上に用意され
>ている状態になりさえすれば
こういう処理が演算性能に与える影響というのはどんなもんなんでしょ．
個々のSPE内でマルチスレッドってことですよね．
>DMAはメインのスレッドの裏で動かして、必要な時に必要なデータがメモリ上に用意され
>ている状態になりさえすれば
こういう処理が演算性能に与える影響というのはどんなもんなんでしょ．
個々のSPE内でマルチスレッドってことですよね．
>280
しかもＥＥの例を見ればＤＭＡにインテリジェントな自動転送機能をつけててもおかしくない。
しかもＥＥの例を見ればＤＭＡにインテリジェントな自動転送機能をつけててもおかしくない。
>>275
>>280
なるほど、そうなるとSPEに載ってるDMAがキモなんですね。
XDRなら十分なメモリ帯域ありそうだし。
デバック時にSPEのメモリ見れないと大変そうだなぁ。
そこは東芝かIBMがかんばってくれるのかな。
>>280
なるほど、そうなるとSPEに載ってるDMAがキモなんですね。
XDRなら十分なメモリ帯域ありそうだし。
デバック時にSPEのメモリ見れないと大変そうだなぁ。
そこは東芝かIBMがかんばってくれるのかな。
>285,287
ＥＥではＤＭＡで送るデータ列にパケット（処理単位）毎に転送するためのタグや次のデータ列へジャンプするためのリンク情報が埋め込めたはず。
それをＤＭＡが解析して転送をコントロール。
箱もディスプレイリストにはそんな感じの昨日はあったけどＤＭＡのようなハードウェアアシストがあるのかは知らない。
ＥＥではＤＭＡで送るデータ列にパケット（処理単位）毎に転送するためのタグや次のデータ列へジャンプするためのリンク情報が埋め込めたはず。
それをＤＭＡが解析して転送をコントロール。
箱もディスプレイリストにはそんな感じの昨日はあったけどＤＭＡのようなハードウェアアシストがあるのかは知らない。
>>284
うまい！
うまい！
>>288
ハハハ、こやつめ！
ハハハ、こやつめ！
×昨日
○機能
あと、289は以前はこうだったから次もなんか効率化する手段は入っているんじゃないかという意味。
○機能
あと、289は以前はこうだったから次もなんか効率化する手段は入っているんじゃないかという意味。
>>265
ビリヤードやレースゲームのような作用反作用処理で並列処理は有りなの？
ビリヤードやレースゲームのような作用反作用処理で並列処理は有りなの？
>>293
並列処理するほどコストが大きくないと思われ
並列処理するほどコストが大きくないと思われ
>>289
CellのEIBはデータ128bitあたり64bitものタグ情報を持ってるしね。
CellのEIBはデータ128bitあたり64bitものタグ情報を持ってるしね。
>>295
http://ascii24.com/news/i/tech/article/2005/02/09/654178-000.html
＞それぞれ64bitのタグと128bitのデータからなる計192bitのパケットがバス内を走る。
http://ascii24.com/news/i/tech/article/2005/02/09/654178-000.html
＞それぞれ64bitのタグと128bitのデータからなる計192bitのパケットがバス内を走る。
Xbox 360 Beta Development Kit Picture Leaked?
http://news.teamxbox.com/xbox/8661/Xbox-360-Beta-Development-Kit-Picture-Leaked/
http://news.teamxbox.com/xbox/8661/Xbox-360-Beta-Development-Kit-Picture-Leaked/
299 ：名無しさん必死だな：2005/07/08(金) 02:42:00 ID:oUj4ykTi
待ってれば実機が出るのになぜだかスペックが気になる今日この頃。
http://pc.watch.impress.co.jp/docs/2005/0622/kaigai193.htm
↑
ここを良く読むとRSXのシェーダー演算性能には、FP16 normalize処理用
のユニット分が含まれてますね。
FP16 normalizeを含まないシェーダー性能
ピクセルシェーダー性能 24基×20Flops×550MHz=264GFlops
（20Flops=4way×2基=8MADD=16Flops + 1way×2基=2MADD=4Flops)
バーテックスシェーダー性能 8基×10Flops×550MHz=44GFlops
(10Flops=4way×1基=4MADD=8Flops + 1way×1基=1MADD=2Flops)
合計=264GFlops + 44 GFlops = 308GFlops
FP16 normalize処理ユニットの性能はNvidiaによると
7Flops×24基×550MHz=92.4GFlops という事なのでこれを足すと
308GFlops + 92.4GFlops= 400.4GFlopsとなりますね。
http://pc.watch.impress.co.jp/docs/2005/0622/kaigai193.htm
↑
ここを良く読むとRSXのシェーダー演算性能には、FP16 normalize処理用
のユニット分が含まれてますね。
FP16 normalizeを含まないシェーダー性能
ピクセルシェーダー性能 24基×20Flops×550MHz=264GFlops
（20Flops=4way×2基=8MADD=16Flops + 1way×2基=2MADD=4Flops)
バーテックスシェーダー性能 8基×10Flops×550MHz=44GFlops
(10Flops=4way×1基=4MADD=8Flops + 1way×1基=1MADD=2Flops)
合計=264GFlops + 44 GFlops = 308GFlops
FP16 normalize処理ユニットの性能はNvidiaによると
7Flops×24基×550MHz=92.4GFlops という事なのでこれを足すと
308GFlops + 92.4GFlops= 400.4GFlopsとなりますね。
>>294
最近のシミュレーター要素が多いレースゲームはどうだろう
>>296
え～、そんな。
たとえば、自分の車がクラッシュして他の車を巻き込む時
他の車のクラッシュ挙動を先に処理出来るんですか？
ビリヤード処理を考えれば出来そうにないと思うのですが
最近のシミュレーター要素が多いレースゲームはどうだろう
>>296
え～、そんな。
たとえば、自分の車がクラッシュして他の車を巻き込む時
他の車のクラッシュ挙動を先に処理出来るんですか？
ビリヤード処理を考えれば出来そうにないと思うのですが
301 ：名無しさん必死だな：2005/07/08(金) 02:54:04 ID:oUj4ykTi
299の続きです。
http://www.beyond3d.com/articles/xenos
一方で散々既出ですが、上記記事を読むと、
Xenosのシェーダー性能は
統合シェーダー性能 48基×10Flops×500MHz=240GFlops
(10Flops=4way×1基=4MADD=8Flops + 1way×1基=1MADD=2Flops)
Xenosは統合シェーダーなので総計も240GFlopsとなります。
http://www.beyond3d.com/articles/xenos/index.php?p=07
ただし、↑ここを読むとATIはシェーダーユニットと並列でpixel shader
interpolation calculationsが実行可能な別ユニットを搭載しているとの事。
これをカウントするとピクセルシェーダー演算性能は33%向上するとか。
このユニットが全統合シェーダーに着いているのかは不明としてもATIの
言い分通りだと最大で
240GFlops×0.33=79.2GFlops分が上乗せされる事になります。
よって総計は240+79.2GFlops = 319.2GFlops??に
http://www.beyond3d.com/articles/xenos
一方で散々既出ですが、上記記事を読むと、
Xenosのシェーダー性能は
統合シェーダー性能 48基×10Flops×500MHz=240GFlops
(10Flops=4way×1基=4MADD=8Flops + 1way×1基=1MADD=2Flops)
Xenosは統合シェーダーなので総計も240GFlopsとなります。
http://www.beyond3d.com/articles/xenos/index.php?p=07
ただし、↑ここを読むとATIはシェーダーユニットと並列でpixel shader
interpolation calculationsが実行可能な別ユニットを搭載しているとの事。
これをカウントするとピクセルシェーダー演算性能は33%向上するとか。
このユニットが全統合シェーダーに着いているのかは不明としてもATIの
言い分通りだと最大で
240GFlops×0.33=79.2GFlops分が上乗せされる事になります。
よって総計は240+79.2GFlops = 319.2GFlops??に
302 ：名無しさん必死だな：2005/07/08(金) 02:54:53 ID:oUj4ykTi
301の続きです。長くてすいません＾＾； これで最後です。
RSXのFP16 normalizeユニット と Xenosのpixel shader interpolation
calculationsユニットのどちらもフル稼働するようなケースはあまり想定
できませんが、通常のゲームアプリを動作させる場合にどちらがより多く
活用されそうかという予想ってつく人いらっしゃいますか？？
ケースバイケースだとは思いますが・・。
（統合シェーダーの効率性とか帯域うんぬんとかは別の話として素のシェー
ダー性能に影響する部分なのでちょっと興味が）
RSXのFP16 normalizeユニット と Xenosのpixel shader interpolation
calculationsユニットのどちらもフル稼働するようなケースはあまり想定
できませんが、通常のゲームアプリを動作させる場合にどちらがより多く
活用されそうかという予想ってつく人いらっしゃいますか？？
ケースバイケースだとは思いますが・・。
（統合シェーダーの効率性とか帯域うんぬんとかは別の話として素のシェー
ダー性能に影響する部分なのでちょっと興味が）
>>299
normalizeというのなんか汎用ユニットじゃないように聞こえるけど、
やってる計算ってのは、
x=v1*h1+v2*h2+v3*h3+v4*h4
の4個の積演算と３個の和演算
3D計算ではもっとも頻出するSIMD演算ですよ
元のソースではnormってあったけど、normalizeじゃなくて
ベクトルのノルム計算という意味のほうが近いと思う。
normalizeにしたければ、x=v1*v1+v2*v2+v3*v3+v4*v4と引数を同じにすればよい。
normalizeというのなんか汎用ユニットじゃないように聞こえるけど、
やってる計算ってのは、
x=v1*h1+v2*h2+v3*h3+v4*h4
の4個の積演算と３個の和演算
3D計算ではもっとも頻出するSIMD演算ですよ
元のソースではnormってあったけど、normalizeじゃなくて
ベクトルのノルム計算という意味のほうが近いと思う。
normalizeにしたければ、x=v1*v1+v2*v2+v3*v3+v4*v4と引数を同じにすればよい。
>>301
＞interpolation calculations
この英単語知らなかったから辞書引いたけど、補完みたいだね。
正体が線形補完なのか、もっと高度な補完なのかは知らないけど。
アルファブレンディングは線形補完。
何に使うのかは知らないけど、俺にはROS処理の一部だとしか思えない。
もしそうだとしたら固定機能の一部としてカウントするべきだよね。
＞interpolation calculations
この英単語知らなかったから辞書引いたけど、補完みたいだね。
正体が線形補完なのか、もっと高度な補完なのかは知らないけど。
アルファブレンディングは線形補完。
何に使うのかは知らないけど、俺にはROS処理の一部だとしか思えない。
もしそうだとしたら固定機能の一部としてカウントするべきだよね。
>>303の補足
そもそも本当の意味でのnormalize（正規化）ってのは。
x=√(v1*v1+v2*v2+v3*v3+v4*v4)
v1/=x,v2/=x,v3/=x,v4/=x
の１２浮動小数点演算が必要。
元のソースにはnormは７浮動小数点演算だと書かれていたから、
normalizeと仮定するとおかしいことになる
そもそも本当の意味でのnormalize（正規化）ってのは。
x=√(v1*v1+v2*v2+v3*v3+v4*v4)
v1/=x,v2/=x,v3/=x,v4/=x
の１２浮動小数点演算が必要。
元のソースにはnormは７浮動小数点演算だと書かれていたから、
normalizeと仮定するとおかしいことになる
307 ：名無しさん必死だな：2005/07/08(金) 03:18:12 ID:oUj4ykTi
>>305
ご指摘どうもです。
元のソースというのはどちらになりますでしょうか？
（Nvidiaの資料とかですか？）
もう一度２９９出だしたソースを読み直してみたたのですが、
こちらの図には+Free FP16 normalizeと記載されていますし、
↓
http://pc.watch.impress.co.jp/docs/2005/0622/kaigai06l.gif
本文中の下のほうに下記のように記載されていたのでnormalize処理用かと
思った次第です。
[さらに、Tamasi氏によると、7個のFP16 normalize(正規化)処理も並列に
可能だという。]
ご指摘どうもです。
元のソースというのはどちらになりますでしょうか？
（Nvidiaの資料とかですか？）
もう一度２９９出だしたソースを読み直してみたたのですが、
こちらの図には+Free FP16 normalizeと記載されていますし、
↓
http://pc.watch.impress.co.jp/docs/2005/0622/kaigai06l.gif
本文中の下のほうに下記のように記載されていたのでnormalize処理用かと
思った次第です。
[さらに、Tamasi氏によると、7個のFP16 normalize(正規化)処理も並列に
可能だという。]
308 ：名無しさん必死だな：2005/07/08(金) 03:19:28 ID:oUj4ykTi
＞移動計算→衝突判定→衝突応答は別々の処理。
＞並列処理するのは、それぞれの段階。
だとすると、衝突判定→衝突応答が再帰的に起こる場合は、殆ど並列化出来ないという事？
＞並列処理するのは、それぞれの段階。
だとすると、衝突判定→衝突応答が再帰的に起こる場合は、殆ど並列化出来ないという事？
312 ：sage：2005/07/08(金) 03:26:24 ID:oUj4ykTi
>>310
NVIDIA（全部大文字なんですね＾＾；）の資料見つけてきましたが、
やっぱりFP16 normalizeって書いてありますね。
↓
http://www.4gamer.net/specials/3de/050706_gf7800/002/img/pixel_g70.jpg
Xenosのpixel shader interpolation calculationsについては初めて聞く
単語で正体不明です。Flops数とかでなくて３３％っていう書き方も謎ですし
・・。
NVIDIA（全部大文字なんですね＾＾；）の資料見つけてきましたが、
やっぱりFP16 normalizeって書いてありますね。
↓
http://www.4gamer.net/specials/3de/050706_gf7800/002/img/pixel_g70.jpg
Xenosのpixel shader interpolation calculationsについては初めて聞く
単語で正体不明です。Flops数とかでなくて３３％っていう書き方も謎ですし
・・。
下げ方間違えましたm(_ _)m
>>303
それは唯の内積ですよね？
それならGeforce3でも
スループット1で出来ていたと思いますが。
(8bit固定小数点ですが)
G70では16bit浮動少数点内積の為に
専用演算器を設けているんですかね？
それは唯の内積ですよね？
それならGeforce3でも
スループット1で出来ていたと思いますが。
(8bit固定小数点ですが)
G70では16bit浮動少数点内積の為に
専用演算器を設けているんですかね？
>>312
＞やっぱりFP16 normalizeって書いてありますね。
本当だ。それだったら7fpというのが間違いなんだろうか…
でも正規化処理なんてそこまで出現頻度高くないぞ
でてきたとしてもsimd*2+aluで1clockでできそうだし
＞やっぱりFP16 normalizeって書いてありますね。
本当だ。それだったら7fpというのが間違いなんだろうか…
でも正規化処理なんてそこまで出現頻度高くないぞ
でてきたとしてもsimd*2+aluで1clockでできそうだし
>>314
shaderプログラムでは内積の使用頻度がTOP
対してsimd unitを１つには内積以外にもいくつも命令を用意する必要がある。
それじゃあ内積だけを１ユニットにすれば、性能/ダイ面積の向上に繋がるのではという、
判断だと思った
shaderプログラムでは内積の使用頻度がTOP
対してsimd unitを１つには内積以外にもいくつも命令を用意する必要がある。
それじゃあ内積だけを１ユニットにすれば、性能/ダイ面積の向上に繋がるのではという、
判断だと思った
正規化は使いまくりでは。３Dcでも使うっしょ。
使いまくりって、それは何と比較してかによる
少なくとも内積より使うってことはない
少なくとも内積より使うってことはない
>>315
そろそろ寝ますが、7fpも謎ですが、
こちらの図を見ると、fp16 normalize unitはShader Unit1にしか着いてなさ
そうですね。（Shader Unit1はテクスチャ処理兼用っぽい）
↓
http://www.4gamer.net/specials/3de/050706_gf7800/002/img/pixel_g70.jpg
となると２４基全てに着いてるとして計算している後藤氏の記事は違うの
かな？？眠くて分からぬ・・
そろそろ寝ますが、7fpも謎ですが、
こちらの図を見ると、fp16 normalize unitはShader Unit1にしか着いてなさ
そうですね。（Shader Unit1はテクスチャ処理兼用っぽい）
↓
http://www.4gamer.net/specials/3de/050706_gf7800/002/img/pixel_g70.jpg
となると２４基全てに着いてるとして計算している後藤氏の記事は違うの
かな？？眠くて分からぬ・・
GeForce 7800 GTXのパイプラインを細かく見てみる（後編）
ttp://www.4gamer.net/specials/3de/050706_gf7800/002/050707_gf7800_02.shtml
ttp://www.4gamer.net/specials/3de/050706_gf7800/002/050707_gf7800_02.shtml
>>318
次世代機だと、どうなると思ってたの？
その処理概要を書いてみ。
ぶっちゃけ、厳密さより物理演算処理できるオブジェクト数が増えるほうが
視覚インパクトが大きいわけで（それも、１００倍、１０００倍の世界）
次世代機だと、どうなると思ってたの？
その処理概要を書いてみ。
ぶっちゃけ、厳密さより物理演算処理できるオブジェクト数が増えるほうが
視覚インパクトが大きいわけで（それも、１００倍、１０００倍の世界）
皆様おはようございます
>>306
処理的にはそうですね
１つ１つ処理して演算結果を出さなければ駄目
演算を並列化出来ても処理は並列化出来ない
>>316
なんかCellは物理演算の並列処理が～って話しで
よくある作用反作用なビリヤード処理を思い出して書いてみた
この前のディープインパクトって凄いよな、計算通り宇宙の彼方で
衝突させたもんな、寝たら起きれ無そう・・どうしよう外が明るい
処理的にはそうですね
１つ１つ処理して演算結果を出さなければ駄目
演算を並列化出来ても処理は並列化出来ない
>>316
なんかCellは物理演算の並列処理が～って話しで
よくある作用反作用なビリヤード処理を思い出して書いてみた
この前のディープインパクトって凄いよな、計算通り宇宙の彼方で
衝突させたもんな、寝たら起きれ無そう・・どうしよう外が明るい
>>329
＞演算を並列化出来ても処理は並列化出来ない
演算の並列化は、並列演算処理と言われてますよ。
あと、３つの処理を並列化する必要は最初からないです。
（複数のSPEが同時に動き続けることには変わりないので）
＞よくある作用反作用なビリヤード処理を思い出して書いてみた
２体問題は教科書にも載ってますが
＞衝突判定→衝突応答が再帰的に起こる場合は
これは多体問題にも発展するんで
よくある話じゃないです。
＞演算を並列化出来ても処理は並列化出来ない
演算の並列化は、並列演算処理と言われてますよ。
あと、３つの処理を並列化する必要は最初からないです。
（複数のSPEが同時に動き続けることには変わりないので）
＞よくある作用反作用なビリヤード処理を思い出して書いてみた
２体問題は教科書にも載ってますが
＞衝突判定→衝突応答が再帰的に起こる場合は
これは多体問題にも発展するんで
よくある話じゃないです。
>>330
＞あと、３つの処理を並列化する必要は最初からないです。
いや3つの処理を並列化って意味じゃなくて・・
現在の処理結果が次の挙動を決めるわけで
＞２体問題は教科書にも載ってますが
簡単な例でビリヤード出しただけ
9ボールじゃなくて4096ボールでリアルタイム物理演算して画面で
動かすとか（車でも）
＞あと、３つの処理を並列化する必要は最初からないです。
いや3つの処理を並列化って意味じゃなくて・・
現在の処理結果が次の挙動を決めるわけで
＞２体問題は教科書にも載ってますが
簡単な例でビリヤード出しただけ
9ボールじゃなくて4096ボールでリアルタイム物理演算して画面で
動かすとか（車でも）
1フレームの間にそんなに複雑にぶつかる物なの？
流体シミュレーションとかのような粒度でもなくて、
所詮ビリヤードだのでしょ？
フレーム単位で駄目なら、>>316にあるように細かく積分する事で対処できるだろうし。
流体シミュレーションとかのような粒度でもなくて、
所詮ビリヤードだのでしょ？
フレーム単位で駄目なら、>>316にあるように細かく積分する事で対処できるだろうし。
細かく積分ってなんだ？
>>334
積分dtを小さくする。
積分dtを小さくする。
判定サイクルを細かくするってことかな
そっか時間ごとに移動距離が足されていくから積分って言うのか
RSXもリーク電流対策で苦労しているみたい。
110nmから90nmにシュリンクしただけでは駄目だったもよう。
110nm450MHzで発売か?
110nmから90nmにシュリンクしただけでは駄目だったもよう。
110nm450MHzで発売か?
リーク電流よりその凄い情報がそんなに簡単にリーク出来ると思ってるお前のが凄い
そういえばRSXってなんでこんな時間かかってんだ?
要はG70だろ。
要はG70だろ。
オブジェクトが多いときの衝突処理をオブジェクトごとにやってたら、演算順番で結果がかわる。
普通は>306のように処理を分けて並列化する。
精度上げるときは皆さん言っている通りｄｔを小さくする（１フレームに数回処理する）
普通は>306のように処理を分けて並列化する。
精度上げるときは皆さん言っている通りｄｔを小さくする（１フレームに数回処理する）
PC用のGPUはCPUから直接VRAMを読み書き出来る設計になっていないからね、G70そのままというわけにはいかないでしょ。
単にFloxIOと繋ぐだけならともかくNUMAというのもネックになっているのでは?
あとは110nmの時点で90nmにシュリンクすることを考えて設計されていたのかというのも考えられなくもない。
単にFloxIOと繋ぐだけならともかくNUMAというのもネックになっているのでは?
あとは110nmの時点で90nmにシュリンクすることを考えて設計されていたのかというのも考えられなくもない。
G70とアーキティクチャを共有しつつ、設計は別、という話では。
つまり110→90nmシュリンクではなく90nmで新規の設計。
FlexIOに加えて省電力も入れているかもしれない。
つまり110→90nmシュリンクではなく90nmで新規の設計。
FlexIOに加えて省電力も入れているかもしれない。
GDDR3がATI主導の規格であることも考えと、
・ nVidiaがVRAMとしてXDR2を採用
・ 65nmプロセスでRSXもXDR2採用
・ Cell、RSXともにメモリはXDR2の1Gbit品 2個ずつに変更
というコストダウンの筋書もありうるか。ちょっと大変すぎるか。
・ nVidiaがVRAMとしてXDR2を採用
・ 65nmプロセスでRSXもXDR2採用
・ Cell、RSXともにメモリはXDR2の1Gbit品 2個ずつに変更
というコストダウンの筋書もありうるか。ちょっと大変すぎるか。
プロセス変更もあるけどソレに加えてredwood対応のせいじゃないの？
いまだにPCI-E接続なんでしょ？
いまだにPCI-E接続なんでしょ？
>>344
つーか、俺はこれ読んでから、nVIDIAはG70でXDR-DRAMに移行すると信じてた。
ttp://pc.watch.impress.co.jp/docs/2004/0716/kaigai103.htm
つーか、俺はこれ読んでから、nVIDIAはG70でXDR-DRAMに移行すると信じてた。
ttp://pc.watch.impress.co.jp/docs/2004/0716/kaigai103.htm
>>346
nVIDIAにしても、まだXDRのノウハウが蓄積されてないから、まずはRSXでFlexIO（SLI向け）と
Cellとの連携でXIOの実働データを参考にしてG80くらいからXDR2に対応するんじゃない？
nVIDIAにしても、まだXDRのノウハウが蓄積されてないから、まずはRSXでFlexIO（SLI向け）と
Cellとの連携でXIOの実働データを参考にしてG80くらいからXDR2に対応するんじゃない？
XDR(2)への移行が技術的に正しくなきゃ、nVidiaだってやらんだろうけどね。
将来のGDDRでは、グラニュラリティと帯域速度の問題がどの程度生じるのかに
かかってる?
将来のGDDRでは、グラニュラリティと帯域速度の問題がどの程度生じるのかに
かかってる?
XDR2の価格次第でしょうな。マイクロスレッディングとかどのくらいRambunに払う事になるのか
わからんし。メモリーは高性能より、量産低価格そこそこ性能が求められるし。
わからんし。メモリーは高性能より、量産低価格そこそこ性能が求められるし。
GDDR系は、そろそろ等長配線がキツくなってきてないか？
帯域と容量を考えたら次世代GPUはXDR系しか選択肢は無さそうだと思うけど。
何かGDDR系でその辺の新技術とかあったっけ？
帯域と容量を考えたら次世代GPUはXDR系しか選択肢は無さそうだと思うけど。
何かGDDR系でその辺の新技術とかあったっけ？
例えXDR2採用して性能上がっても価格も上がる、ではハイエンド以外で戦えない。
XDR2に移行するにしてもチキンレースになるだろうね。
XDR2に移行するにしてもチキンレースになるだろうね。
XDR2のライセンス料はそんなに高いのか?
メモリの「高い」はたいてい「数量でないから高い」で、
PS3ぐらいのボリュームがあると、それはなんとかなるらしいんだが。
メモリの「高い」はたいてい「数量でないから高い」で、
PS3ぐらいのボリュームがあると、それはなんとかなるらしいんだが。
メモリ帯域は重要だが最優先ではないことはRDがPCのメインストリームにならなかった事からも
わかる。価格が安くなる＝大量生産なんだが、XDR2がどの程度の価格製品になるかは未知数。
わかる。価格が安くなる＝大量生産なんだが、XDR2がどの程度の価格製品になるかは未知数。
RDRAMが流行らなかったのは、Intelの開発失敗が一番大きいような。
開発難度が高かったからね。でも、XDRではそれが逆転する事になるでしょ。
XDRの方が開発が楽だから、後は値段がどれ位の物になるか次第かと。
開発難度が高かったからね。でも、XDRではそれが逆転する事になるでしょ。
XDRの方が開発が楽だから、後は値段がどれ位の物になるか次第かと。
RDRAMに関しては当時としては実行性能がDDRと比較して別段高くなく
値段は飛びぬけて高かったので市場に受けいられなかったのでは。
値段は飛びぬけて高かったので市場に受けいられなかったのでは。
RDRAMは高く、DDRは安く、DDRでもボトルネックにはあまりならなかったが、インテルはRDRAMで強行。
安いほうがいいという市場に負けたという流れだったっけ。
安いほうがいいという市場に負けたという流れだったっけ。
やっぱRDRAMは最初の頃のﾏｻﾞｰがこけたのがなぁ
Intelで交換騒ぎあったのあれぐらいじゃね？
Intelで交換騒ぎあったのあれぐらいじゃね？
みんな、鬱陶しいラムバスに余計な金を払いたくなかったんだよ。
ゲームプログラムの並列化って、どういう流れになるんかね。
ミドルウェアやマルチスレッド化されたライブラリを使うといった曖昧なものでなく、出来ればアセンブラレベルまで降りて検証してみたいんだけど。
ちなみに研究目的なので、実用的でないとかいうのは無しの方向で。
ミドルウェアやマルチスレッド化されたライブラリを使うといった曖昧なものでなく、出来ればアセンブラレベルまで降りて検証してみたいんだけど。
ちなみに研究目的なので、実用的でないとかいうのは無しの方向で。
なんだこの閉古鳥具合は？
だれかハードのこととか
プログラムのしやすさ比較とか
皆に分かるようにチンコに例えて説明してくれ
プログラムのしやすさ比較とか
皆に分かるようにチンコに例えて説明してくれ
>>364
んなもん実物がないのにどんな話しろと？
んなもん実物がないのにどんな話しろと？
それなら、コントローラーからの入力からになるかな。
これは1プレイヤーの場合は並列化出来ない、複数の場合もまあ、シングルスレッドだなLSにロードしたプログラムだけでSPE内で回す、XDRはアクセスしない。
これは1プレイヤーの場合は並列化出来ない、複数の場合もまあ、シングルスレッドだなLSにロードしたプログラムだけでSPE内で回す、XDRはアクセスしない。
>>364
360のGPUはお前のチンコみたいなもんだ。斬新な構造だが一度も使われて無いので未だ未知数
360のGPUはお前のチンコみたいなもんだ。斬新な構造だが一度も使われて無いので未だ未知数
368 ：名無しさん必死だな：2005/07/08(金) 23:31:03 ID:gE8CBjDU
入力の後は、行動ルーチンか。
ここから物理演算とか入ってくるんだよな。
ここから物理演算とか入ってくるんだよな。
斬新な構造のおちんこってどんなのだろう。
>>369
カントン包茎
カントン包茎
I/Oから読み込んで結果をメモリに格納するだけの処理をSPEに割り当てたら
オーバーヘッドの方が多いだろう
たぶんPPEでサクっと終わらせると思われ
オーバーヘッドの方が多いだろう
たぶんPPEでサクっと終わらせると思われ
当たり判定座標の配列組むけどデーター量から見てLSには入りきらないよな。
やっぱりXDR読みにいくのか?
やっぱりXDR読みにいくのか?
小さいL1キャッシュと違って、LSは256KBあるからダブルバッファにしても
100KBぐらいははいけるだろう
当たり座標判定に使うだけのプログラムなら10Kにもならないだろうし
100KBぐらいははいけるだろう
当たり座標判定に使うだけのプログラムなら10Kにもならないだろうし
任天堂とMSは本気モード
SONYは夢見る乙女モード
分かってる？GKさんよ
SONYは夢見る乙女モード
分かってる？GKさんよ
vsスレでどうぞ。
G70内での、それぞれ異なるクロックスピードで動作する複数の部位
http://www.bit-tech.net/news/2005/07/07/g70_clock_speed/
http://www.bit-tech.net/news/2005/07/07/g70_clock_speed/
>>377
だれか説明おねがいしまつ orz
だれか説明おねがいしまつ orz
,,...- ''''''' ''' ー---
ｷｭﾙｷｭﾙ _,,,,.../
彡 彡 彡 ,,,......-..:::':'::" _ノ
三三三三三三エエエ===ゝ:、:,:,:.:- ' "
（
＼ ;
ヽ 、 _,,,,.......ﾉノ、,,,_
" '''--- ''''''"
省電力と各部の処理スピードバランスをとるために、部位によってクロックスピードが
違うだけ、クロック表示するソフトが対応出来てないので、変な表示になるようだ
半導体としては別に珍しい事じゃない、CPUだって部分的には倍速だったりするし
違うだけ、クロック表示するソフトが対応出来てないので、変な表示になるようだ
半導体としては別に珍しい事じゃない、CPUだって部分的には倍速だったりするし
【レボリューション ハード情報（リーク）】
CPU：4コア （各2.5GHz）一次キャッシュは128KB、二次キャッシュは512KB
GPU：RN520×2コア（16MB混載）
ﾒﾓﾘ：512MB共有
PPU：物理ｼﾐｭﾚｰｼｮﾝ専用のﾌﾟﾛｾｯｻ（32MB）
・最も革命的な部分は「無料のオンラインシステム」
・性能的にはXbox360より遥かに上
・720p(プログレッシブ)と1080i(インターレース)HDTV規格に対応
・E3でのコントローラーの発表は未定
・コントローラーが感圧式とか無線
・DSより進化した「音声認識機能」
・無線による「ＤＳとの連動」
ttp://www.unika.com.cn/article/article.php/2572
終わった・・・ 完全に衝を突かれたな・・・
CPU：4コア （各2.5GHz）一次キャッシュは128KB、二次キャッシュは512KB
GPU：RN520×2コア（16MB混載）
ﾒﾓﾘ：512MB共有
PPU：物理ｼﾐｭﾚｰｼｮﾝ専用のﾌﾟﾛｾｯｻ（32MB）
・最も革命的な部分は「無料のオンラインシステム」
・性能的にはXbox360より遥かに上
・720p(プログレッシブ)と1080i(インターレース)HDTV規格に対応
・E3でのコントローラーの発表は未定
・コントローラーが感圧式とか無線
・DSより進化した「音声認識機能」
・無線による「ＤＳとの連動」
ttp://www.unika.com.cn/article/article.php/2572
終わった・・・ 完全に衝を突かれたな・・・
>>382
当初のコンセプトモデル
ttp://www.1up.com/media?id=1897381&type=lg
チップやドライブ類の実装を踏まえて寸法と熱対策を見直した最新プロトタイプ
ttp://www.clubic.com/photo/00101697.jpg
青く光るLEDの部分で双方の大きさの違いが比較できるな。
当初のコンセプトモデル
ttp://www.1up.com/media?id=1897381&type=lg
チップやドライブ類の実装を踏まえて寸法と熱対策を見直した最新プロトタイプ
ttp://www.clubic.com/photo/00101697.jpg
青く光るLEDの部分で双方の大きさの違いが比較できるな。
インチキリークに必ず顔を出す物理演算チップってなんか根拠があるの？
社長さんがそんなことを匂わせたとかさ。
社長さんがそんなことを匂わせたとかさ。
>>384
低クロックでも性能的に対抗できそうな可能性はそれだけだから。
でも、物理演算チップって３Dゲームを作る時にしか用が無いから
２Dゲームやその他の用途では全く使えない盲腸チップ。
CellのSPEや箱○GPUの統合シェーダのような柔軟性は無い。
低クロックでも性能的に対抗できそうな可能性はそれだけだから。
でも、物理演算チップって３Dゲームを作る時にしか用が無いから
２Dゲームやその他の用途では全く使えない盲腸チップ。
CellのSPEや箱○GPUの統合シェーダのような柔軟性は無い。
というか物理演算チップを載せるコストを考えたら、
高クロックなCPUやGPUを載せる方がコストパフォーマンスが良い。
コスト重視路線の任天堂が、そんな無駄にコストのかかる物を載せる事は無い。
高クロックなCPUやGPUを載せる方がコストパフォーマンスが良い。
コスト重視路線の任天堂が、そんな無駄にコストのかかる物を載せる事は無い。
任天堂が物理演算で
ゲームが面白くなると一番思って無いでしょ
ゲームが面白くなると一番思って無いでしょ
>>383
＞チップやドライブ類の実装を踏まえて寸法と熱対策を見直した最新プロトタイプ
＞ttp://www.clubic.com/photo/00101697.jpg
実機のレボはファンレスなら本気でその画像みたいなゴツい筐体になるかもな。
あのモックアップもI/Oポートの位置とか細かいところで推敲が足りてないように
思えるから、大幅な変更は無きにしも非ず。
＞チップやドライブ類の実装を踏まえて寸法と熱対策を見直した最新プロトタイプ
＞ttp://www.clubic.com/photo/00101697.jpg
実機のレボはファンレスなら本気でその画像みたいなゴツい筐体になるかもな。
あのモックアップもI/Oポートの位置とか細かいところで推敲が足りてないように
思えるから、大幅な変更は無きにしも非ず。
2Dで使えんという事は無いと思うが
オブジェクトを同一平面上に束縛すればいいだけやん？
オブジェクトを同一平面上に束縛すればいいだけやん？
> でも、物理演算チップって３Dゲームを作る時にしか用が無いから
> ２Dゲームやその他の用途では全く使えない盲腸チップ。
コレに対するレスだから汎用チップのがいいとかはおら知らね
> ２Dゲームやその他の用途では全く使えない盲腸チップ。
コレに対するレスだから汎用チップのがいいとかはおら知らね
>>391
「使えない」じゃなくて「使い物にならない」のほうが良かったかな？
「使えない」じゃなくて「使い物にならない」のほうが良かったかな？
基本的にゲームキューブの踏襲なんだろうけど
1T-SRAMはどれくらい大容量化が可能なんだろう
1T-SRAMはどれくらい大容量化が可能なんだろう
きっと768Mbitチップ×２とかだ
>>387
直感的な面白さを追及する上で、物理演算は非常に有効な手段。
むしろグラフィックの変わりに任天堂が次世代で一番力をいれそうな分野だと思っていた。
そういう意味では性能を重視しないと言われるレボは意外。
直感的な面白さを追及する上で、物理演算は非常に有効な手段。
むしろグラフィックの変わりに任天堂が次世代で一番力をいれそうな分野だと思っていた。
そういう意味では性能を重視しないと言われるレボは意外。
噂だとPPC970MPの1.6GHzだっけか？
それだけでもう俺のノーパソより３倍速いよ
VMXもふたつ載ってるし
他社がもっと凄いからコレで十分なんてとても言えないけど
次世代には違いないんじゃない
それだけでもう俺のノーパソより３倍速いよ
VMXもふたつ載ってるし
他社がもっと凄いからコレで十分なんてとても言えないけど
次世代には違いないんじゃない
現時点で出てるレヴォの性能についての情報は例外なくデマ。なんで
未だにこのスレに繰り返し出てくるんだろうね
未だにこのスレに繰り返し出てくるんだろうね
>>399
言わなくてもみんなわかってますから・・・。
言わなくてもみんなわかってますから・・・。
物理演算で面白いゲーム・・・
FANFUNくらいしか記憶に無いなあ
FANFUNくらいしか記憶に無いなあ
レボリューションのスペック
http://www.gamesindustry.biz/content_page.php?aid=9485
・1.8Ghz IBM PowerPC G5プロセッサが2つ（GCはIBM PowerPC「GEKKO」485MHz）
・600Mhz ATIグラフィックチップ（GCは「Flipper」162MHz）
・7.1デジタルサウンドチップセット
・128MB 1T SRAM（GCは1T SRAM「Splash」24M + 「Aメモリ」16M）
・12MB グラフィックチップのRAM
・パナソニック設計の6GB DVDサイズディスク
http://www.gamesindustry.biz/content_page.php?aid=9485
・1.8Ghz IBM PowerPC G5プロセッサが2つ（GCはIBM PowerPC「GEKKO」485MHz）
・600Mhz ATIグラフィックチップ（GCは「Flipper」162MHz）
・7.1デジタルサウンドチップセット
・128MB 1T SRAM（GCは1T SRAM「Splash」24M + 「Aメモリ」16M）
・12MB グラフィックチップのRAM
・パナソニック設計の6GB DVDサイズディスク
CELLはストリーミングは得意だけど
http://www.itmedia.co.jp/games/articles/0505/17/news075.html
こういう数千体のキャラがうごくゲームは苦手ですね。というか無理。
MPEG2動画48本同時デコードのデモみたいな並列処理には強いけど。
http://www.itmedia.co.jp/games/articles/0505/17/news075.html
こういう数千体のキャラがうごくゲームは苦手ですね。というか無理。
MPEG2動画48本同時デコードのデモみたいな並列処理には強いけど。
>>405
ゾンビ数千体は無理でも、アヒルや足軽なら沢山動いているよ。
ゾンビ数千体は無理でも、アヒルや足軽なら沢山動いているよ。
アヒルは、AIの載ってないただのオブジェクトな訳で
>>405
ｳﾝｳﾝ、そうだといいですね（ ´,_ゝ｀）
ｳﾝｳﾝ、そうだといいですね（ ´,_ゝ｀）
なんで360はキャラ大量に出せて
PS3は360ほどキャラだせないってなってんの。なんか技術的証拠あんのかな。
PS3は360ほどキャラだせないってなってんの。なんか技術的証拠あんのかな。
ゾンビがテキパキ動くんだろ
ttp://www.scei.co.jp/corporate/release/pdf/050701b.pdf
どうやら本気でコンピュータ事業に乗り出すらしい
どうやら本気でコンピュータ事業に乗り出すらしい
どうでもいいが全部倒せるとかそれ以前に腐臭で死ねそうだな
ここでは発言に根拠がないとねぇ
この言葉を送ろう
儲も鳴かずば撃たれまい
儲も鳴かずば撃たれまい
つーか、数千体のゾンビにAI使ってるとは思えないんだけど…
個々に係数が設定されていて、徒党を組んでむかってくる奴もいれば一人で逃げてる
奴もいる、ぐらいのことは期待してもいいような気がする。ゲームとして面白いのは
どんなモデルだろう?
奴もいる、ぐらいのことは期待してもいいような気がする。ゲームとして面白いのは
どんなモデルだろう?
SPEでメインメモリからデータ読み込む時は
struct list {
void *data;
struct list *prev;
struct list *next;
};
みたいな自己参照構造体のデータは、データが連続してないし次のデータ読み込むまでその次のデータ読み込めないから厳しそうだね。
検索でよく使う２分木や８分木も自己参照構造体なんだけど、この辺はPPEで処理しろって事なのかな？
８分木って地形コリジョンによく使われるから、コリジョン検索はPPEの仕事になりそうだね。
struct list {
void *data;
struct list *prev;
struct list *next;
};
みたいな自己参照構造体のデータは、データが連続してないし次のデータ読み込むまでその次のデータ読み込めないから厳しそうだね。
検索でよく使う２分木や８分木も自己参照構造体なんだけど、この辺はPPEで処理しろって事なのかな？
８分木って地形コリジョンによく使われるから、コリジョン検索はPPEの仕事になりそうだね。
Dead Risingや無双みたいなワラワラゲームは
AIがどうのこうのというよりも、単純にポリゴンをどれだけ出せるか
というのが勝負だと思うけど。そうなれば圧倒的にPS3のほうが得意なわけで。
AIがどうのこうのというよりも、単純にポリゴンをどれだけ出せるか
というのが勝負だと思うけど。そうなれば圧倒的にPS3のほうが得意なわけで。
>424
記憶領域を連続にできるものはlist使わないんじゃない？
listの旨味は挿入削除にコストかからない点だと思う。
木のサイズがLSに収まるなら、確かにその方法で良いと思うんだけど。
記憶領域を連続にできるものはlist使わないんじゃない？
listの旨味は挿入削除にコストかからない点だと思う。
木のサイズがLSに収まるなら、確かにその方法で良いと思うんだけど。
SPEでの処理するメンバだけ別に取り出して連続なデータ構造にするとか、
同時に複数枝探索してメインメモリアクセスのレイテンシを隠蔽するとか、
必要なら方法は生み出されるでしょう。
大雑把に言えば、SPEのための最適化はかかる手間は大きいが、得られる性能も大きい。
費用対効果で考えると割に合うのではないかな、と。
とりあえずプログラマ的には楽しそうだ。
同時に複数枝探索してメインメモリアクセスのレイテンシを隠蔽するとか、
必要なら方法は生み出されるでしょう。
大雑把に言えば、SPEのための最適化はかかる手間は大きいが、得られる性能も大きい。
費用対効果で考えると割に合うのではないかな、と。
とりあえずプログラマ的には楽しそうだ。
ポインタアレイ渡すのも爆死コースだな
階層が深くなければ問題ねーや。欝だ死のう。今日はもうこねぇよ。
数千体のゾンビの処理なんかＡＩといっても物理演算と同レベルだろうな。
別に並列化できなくも無いよな。
別に並列化できなくも無いよな。
ポインタの再帰的参照でディスクリートなメモリエリアにアクセスするのは、普通のＣＰＵだってキャッシュ効率最悪になるし、必要ならＳＰＥでも先読み処理しておけば処理速度は同じじゃない？
めんどくさいのは確かだけど自動処理関数も作れそうだしコンパイラしだいじゃないかな。
めんどくさいのは確かだけど自動処理関数も作れそうだしコンパイラしだいじゃないかな。
Listなんて一番対応が簡単なパターンだよ
単にListを順に処理するだけで良いなら、DMA用スレッドがメインの処理スレッドの裏で
*nextと*data読み取って、DMA発行するだけでいいんだから
Listを線形になら、メインスレッドが処理している部分よりも先行してDMA発行が可能
だから、完全にデータ転送レイテンシを隠蔽できるパターンだ
八分木のように分岐が必要な場合は、例えば最初に全体を2つに分割して、そのツリーを
交互に
判定で次に必要なデータ判明→DMA発行→別のツリーの判定→DMA発行
という順で処理すれば、隠蔽は可能だ
素人でもこのぐらい思いつくんだから、プロはもっといい方法思いつくだろうさ
単にListを順に処理するだけで良いなら、DMA用スレッドがメインの処理スレッドの裏で
*nextと*data読み取って、DMA発行するだけでいいんだから
Listを線形になら、メインスレッドが処理している部分よりも先行してDMA発行が可能
だから、完全にデータ転送レイテンシを隠蔽できるパターンだ
八分木のように分岐が必要な場合は、例えば最初に全体を2つに分割して、そのツリーを
交互に
判定で次に必要なデータ判明→DMA発行→別のツリーの判定→DMA発行
という順で処理すれば、隠蔽は可能だ
素人でもこのぐらい思いつくんだから、プロはもっといい方法思いつくだろうさ
私も素人ですけど、NUMAなんて単に分離メモリの間を
ブリッジで繋いでるだけのものじゃないの？
並列処理じゃある程度効果はありそうだし便利だとも思うけど、
大抵GPU専用のローカルメモリがあるだろうから、
そんなに劇的な差にはならなさそうな気がします。
専門家の皆様どうなんでしょ
ブリッジで繋いでるだけのものじゃないの？
並列処理じゃある程度効果はありそうだし便利だとも思うけど、
大抵GPU専用のローカルメモリがあるだろうから、
そんなに劇的な差にはならなさそうな気がします。
専門家の皆様どうなんでしょ
>432
>425は書き方悪いのかもしれないが、いいたいことはツリーの動的変更に自由度があるということでしょ？
継承してノードの大きさが変わっても、ノードの数が極端に増減してもListならメモリの再確保必要ないし。
>424に対する意見なんだし、配列化できるかって話では？
>425は書き方悪いのかもしれないが、いいたいことはツリーの動的変更に自由度があるということでしょ？
継承してノードの大きさが変わっても、ノードの数が極端に増減してもListならメモリの再確保必要ないし。
>424に対する意見なんだし、配列化できるかって話では？
437 ：名無しさん必死だな：2005/07/09(土) 12:26:16 ID:DqE0caew
わらわらゲームはスマッシュTVで完成されてるからなあ。
ATI taped out R520, again
http://www.theinquirer.net/?article=24446
2度目のテープアウトも、歩留まり改善しなかったのね
それで
>I just cannot understand one thing. How come ATI was able to ship millions of R500,
>Xbox 360 chips to Microsoft's launch scheduled for October, when it seems to having
>trouble with yields for the R520? Both chips are using the same new 90 nanometre marchitecture.
http://www.theinquirer.net/?article=24446
2度目のテープアウトも、歩留まり改善しなかったのね
それで
>I just cannot understand one thing. How come ATI was able to ship millions of R500,
>Xbox 360 chips to Microsoft's launch scheduled for October, when it seems to having
>trouble with yields for the R520? Both chips are using the same new 90 nanometre marchitecture.
>>434
そもそも、Listのノード順と配列のメモリ位置が同等なら、すでにListじゃないしｗｗ
ゾンビの例で言うと、もっと複雑なシーングラフなわけで、、。
シーンのトラバース順とメモリ配置に因果関係なんか作ってたら、正直やってらんねーよ。
トラバース順なんて、ちょっとした事でどんどん変化するものだし。
そもそも、Listのノード順と配列のメモリ位置が同等なら、すでにListじゃないしｗｗ
ゾンビの例で言うと、もっと複雑なシーングラフなわけで、、。
シーンのトラバース順とメモリ配置に因果関係なんか作ってたら、正直やってらんねーよ。
トラバース順なんて、ちょっとした事でどんどん変化するものだし。
>>439
苦労してるねぇ。
苦労してるねぇ。
ｵｲｵｲ、えらい事実が発覚しましたよｗ
>746 名前：名無しさん必死だな sage 投稿日：2005/07/09(土) 12:36:47 ID:FszcfBG8
>>>737みたいなお子様は英語が読めないのかwww
>＞XBOX360CPU=240Gflopsは最新開発機材に添付されていたスペックシートに書かれていた。
>＞360CPUは最終的に、1coreあたり2命令/clockに増強されたそうだ(CellのPPEは1命令/2clockの2命令同時実行）
(ﾉ∀`)ｱﾁｬｰ
>746 名前：名無しさん必死だな sage 投稿日：2005/07/09(土) 12:36:47 ID:FszcfBG8
>>>737みたいなお子様は英語が読めないのかwww
>＞XBOX360CPU=240Gflopsは最新開発機材に添付されていたスペックシートに書かれていた。
>＞360CPUは最終的に、1coreあたり2命令/clockに増強されたそうだ(CellのPPEは1命令/2clockの2命令同時実行）
(ﾉ∀`)ｱﾁｬｰ
>>426
既存のアルゴリズムが使えないのは職業プログラマ的には辛いだけなのですが・・・
既存のアルゴリズムが使えないのは職業プログラマ的には辛いだけなのですが・・・
ってか、PS3でもわらわらゲームのデモあったやん。
仁王もリアルタイムだったらしいし、heavenly swordも
開発自ら掲示板でリアルタイムだったと認めてるし。
http://www.ninjatheory.com/blinkblink/index.php?option=com_content&task=view&id=38&Itemid=61
仁王もリアルタイムだったらしいし、heavenly swordも
開発自ら掲示板でリアルタイムだったと認めてるし。
http://www.ninjatheory.com/blinkblink/index.php?option=com_content&task=view&id=38&Itemid=61
>442
ちょっと前に話題になっていた気がするが？
ちょっと前に話題になっていた気がするが？
>>442
えらく古いネタだな・・・
えらく古いネタだな・・・
いや、いまだにこのネタVSスレで振りかざしてたからね。英語サイトに書かれてると説得力あるらしいｗ
>440
えっと、なぜ私にレス？
>434は>432に対して論点がかみ合っていないって言うだけだよ。
ちなみに自分は>430だし、SPEでもListを配列的に連続した特定メモリエリアに押し込めて使う意味は無いと思ってる。
えっと、なぜ私にレス？
>434は>432に対して論点がかみ合っていないって言うだけだよ。
ちなみに自分は>430だし、SPEでもListを配列的に連続した特定メモリエリアに押し込めて使う意味は無いと思ってる。
>451
そうだよね、どっちも単位時間当たりの周囲の状況に対する応答を処理（内部の状態遷移含む）していくだけだし。
違いといえば、AIは場合（レベル）によっては複雑な評価関数を処理しなければならないのと、衝突判定なら単位時間を短くとらなきゃならない可能性があるって事かな。
そうだよね、どっちも単位時間当たりの周囲の状況に対する応答を処理（内部の状態遷移含む）していくだけだし。
違いといえば、AIは場合（レベル）によっては複雑な評価関数を処理しなければならないのと、衝突判定なら単位時間を短くとらなきゃならない可能性があるって事かな。
ttp://www.ati.com/developer/demos/rx800.html
ATiのCrowdというDemoは既存のPC、GPUで1400体のキャラクター出してる
Mpegでも見れるし、ATiのX800以降のカード持ってる人なら自分で実行できるよ
ま、キャラクターをワラワラ出すだけなら、PS3もXBOX360も全く問題無いだろうね
ATiのCrowdというDemoは既存のPC、GPUで1400体のキャラクター出してる
Mpegでも見れるし、ATiのX800以降のカード持ってる人なら自分で実行できるよ
ま、キャラクターをワラワラ出すだけなら、PS3もXBOX360も全く問題無いだろうね
>>446
未だにキャッシュサイズだとか転送とかを弄って自己満足してる連中もどうかと思うけどね。
そういうの好きな人種が多いのはわかるが、そもそもハードベンダがやればいい仕事だし。
もっとやらんといけない部分は沢山あると思うしね。海外に先越されてる。
実際、結局は大手でも使えない自作ライブラリは止めてミドルウェアにシフトしてる所多いし。
>>450
深い意味はないよ。
未だにキャッシュサイズだとか転送とかを弄って自己満足してる連中もどうかと思うけどね。
そういうの好きな人種が多いのはわかるが、そもそもハードベンダがやればいい仕事だし。
もっとやらんといけない部分は沢山あると思うしね。海外に先越されてる。
実際、結局は大手でも使えない自作ライブラリは止めてミドルウェアにシフトしてる所多いし。
>>450
深い意味はないよ。
>>454
海外に先行されている分野は、それこそ自分で新しいアルゴリズムを考えなきゃ
ならない物が多いし、SPEの最適化で悩むようなプログラマは、そんなレベルに
無いと思われ・・・
アルゴリズムとデータ構造の最適化はプログラムの基本なんだし
海外に先行されている分野は、それこそ自分で新しいアルゴリズムを考えなきゃ
ならない物が多いし、SPEの最適化で悩むようなプログラマは、そんなレベルに
無いと思われ・・・
アルゴリズムとデータ構造の最適化はプログラムの基本なんだし
456 ：名無しさん必死だな：2005/07/09(土) 14:01:50 ID:KccXX2ya
PS3の学習曲線はPS2よりはるかに悪いだろうな。
つまりPS3の性能を生かしたソフトはPS3末期にしか出てこない可能性が高いということだ。
FLOPSに偏重しすぎの使いづらいハードを押し付け
printfデバッグを強要してそれを使いづらいという開発者を無能呼ばわり。
それがSCE&GKｸｵﾘﾃｨ。
つまりPS3の性能を生かしたソフトはPS3末期にしか出てこない可能性が高いということだ。
FLOPSに偏重しすぎの使いづらいハードを押し付け
printfデバッグを強要してそれを使いづらいという開発者を無能呼ばわり。
それがSCE&GKｸｵﾘﾃｨ。
性能に違いはない
よくてGCと箱ぐらいの違い
この２機種もGCだけ30fpsとかいう
ソフトが皆無だった
所詮そんなもん
よくてGCと箱ぐらいの違い
この２機種もGCだけ30fpsとかいう
ソフトが皆無だった
所詮そんなもん
本日のID：ID:KccXX2ya
PPE+SPEx1ですらEEと同じくらい開発が難しいと言われてるのに、開発環境はPS2の時と同程度と、ソニー幹部自ら発言
本当64の時の任天堂よりも遥かにグダグダだよ
本当64の時の任天堂よりも遥かにグダグダだよ
>>454
いや、その自己満足で出来る事が増えるならプログラマ以外も喜ぶから、自己満足じゃ無いと思うよ。
確かにハードベンダーがやってくれれば最高なんだけどね。
まさに夢の開発環境。
>>456
森へお帰り
いや、その自己満足で出来る事が増えるならプログラマ以外も喜ぶから、自己満足じゃ無いと思うよ。
確かにハードベンダーがやってくれれば最高なんだけどね。
まさに夢の開発環境。
>>456
森へお帰り
cellのSPEを使ったソフトは当分出てこない
とかいうか出せない
とかいうか出せない
実際の話、今の開発環境ではSPEはゲーム用途では背景動画の再生くらいにしか使えない
>>460
仕様が達成出来て終い。じゃないからね。
汎用性と保守が大事。言われるまでもないと思うが。
それはハードベンダがやんないと。
で、結局破棄してミドルウェアに頼るなら、最初からやらない方が良い。
コストの無駄。要するに自己満足。
仕様が達成出来て終い。じゃないからね。
汎用性と保守が大事。言われるまでもないと思うが。
それはハードベンダがやんないと。
で、結局破棄してミドルウェアに頼るなら、最初からやらない方が良い。
コストの無駄。要するに自己満足。
>PPE+SPEx1ですらEEと同じくらい開発が難しいと言われてるのに
初耳だ。
今までの情報を一通り見てればそんな結論にはならないと思うが。
ていうかレスしちゃいけない人みたいだな。
初耳だ。
今までの情報を一通り見てればそんな結論にはならないと思うが。
ていうかレスしちゃいけない人みたいだな。
つか、勘違いしてるのが多いね
別にSPEやPPEに最適化されたコード書かなくても
Cellはそれなりに動いてくれるわけですが
(コンパイラの問題もあるが)
別にSPEやPPEに最適化されたコード書かなくても
Cellはそれなりに動いてくれるわけですが
(コンパイラの問題もあるが)
>>463
自社ライブラリを持つ事は無駄なのか・・・
ミドルウェア製作会社ならともかく、ゲーム業界なんてハードが切り替われば過去の
資産なんて使い物にならなくなる＆ゲーム以外の用途に使う事なんて考えずに
最適化するのがあたりまえの業界で、汎用性と保守性を第一に考える？
Cellを使ったサーバーやら、PCならともかく、ここはゲームハードテクノロジースレだよ？
自社ライブラリを持つ事は無駄なのか・・・
ミドルウェア製作会社ならともかく、ゲーム業界なんてハードが切り替われば過去の
資産なんて使い物にならなくなる＆ゲーム以外の用途に使う事なんて考えずに
最適化するのがあたりまえの業界で、汎用性と保守性を第一に考える？
Cellを使ったサーバーやら、PCならともかく、ここはゲームハードテクノロジースレだよ？
ミドルウェアを持たなく失敗した例
まさにEEじゃないか
まさにEEじゃないか
>>466
無駄とまでは言わないが、ＨＡＬ層の最適化に注力してりゃいいって人はごく限られてると。
後、考え方が少し古くない？
続編や復刻が多い今日、汎用性と保守性は重要性上がってるでしょう。間違いなく。
＞ここはゲームハードテクノロジースレだよ？
ハードに特化してるのか、、。ならソフト屋の出る幕はないな、、。
無駄とまでは言わないが、ＨＡＬ層の最適化に注力してりゃいいって人はごく限られてると。
後、考え方が少し古くない？
続編や復刻が多い今日、汎用性と保守性は重要性上がってるでしょう。間違いなく。
＞ここはゲームハードテクノロジースレだよ？
ハードに特化してるのか、、。ならソフト屋の出る幕はないな、、。
汎用コードでとりあえず組んでって、必要だったら最適化していくのが今の主流 かな？
ゲームエンジンのミドルウェアひとつ数十万ドル＋何パーセントかのインセンティブとかいわれてるわけで、
そういうのが本当に必要な中小にとっては結構引くよな。
体力のある大手は自社開発して、経験ふくめて会社の資産にした方が後々も有利だし。
今のレトロゲー的に後々になって再販する商売も考えれば、いつまでも紐付きなのは怖い話でもあるしな。
そういうのが本当に必要な中小にとっては結構引くよな。
体力のある大手は自社開発して、経験ふくめて会社の資産にした方が後々も有利だし。
今のレトロゲー的に後々になって再販する商売も考えれば、いつまでも紐付きなのは怖い話でもあるしな。
てか塊魂とかFF11とかやるとｹﾞｰﾑﾌﾟﾛｸﾞﾗﾏはと、てつもないと思えてくるよ
このへんでﾘｽﾄがどうのとか言ってるような事は、まったく問題にならんと思われ
このへんでﾘｽﾄがどうのとか言ってるような事は、まったく問題にならんと思われ
http://www.theinquirer.net/?article=24446
>How come ATI was able to ship millions of R500, Xbox
>360 chips to Microsoft's launch scheduled for October,
>when it seems to having trouble with yields for the
>R520? Both chips are using the same new 90 nanometrem
> architecture.
R520の再設計には４～６週間かかる。nVIDIAのG70発売前
に、ATIはすでにR520の再設計を二度行っていたが、それ
でも、満足のいく結果が得られなかった。
（略）
R520の生産でこれだけトラブルを抱えてるのに、１０月発売
が予定されているＭＳのXbox360用のチップ、R500を数百万
も一体どうやったら出荷することができるというのだろう？
両チップは同じ新しい90nmアーキテクチャを使っている。
専門家からも、R500の生産はムリポという意見が出てきたね。
Xbox360、まじ来年春以降に発売延期になりそうだ。
>How come ATI was able to ship millions of R500, Xbox
>360 chips to Microsoft's launch scheduled for October,
>when it seems to having trouble with yields for the
>R520? Both chips are using the same new 90 nanometrem
> architecture.
R520の再設計には４～６週間かかる。nVIDIAのG70発売前
に、ATIはすでにR520の再設計を二度行っていたが、それ
でも、満足のいく結果が得られなかった。
（略）
R520の生産でこれだけトラブルを抱えてるのに、１０月発売
が予定されているＭＳのXbox360用のチップ、R500を数百万
も一体どうやったら出荷することができるというのだろう？
両チップは同じ新しい90nmアーキテクチャを使っている。
専門家からも、R500の生産はムリポという意見が出てきたね。
Xbox360、まじ来年春以降に発売延期になりそうだ。
どこに句読点打ってるんだよ；
王様ﾋﾞｰﾑあびながら転がしてくる．．．
王様ﾋﾞｰﾑあびながら転がしてくる．．．
>>471
FF11は少し知ってるんだが、、かなり泥臭い事やってる。
デザイナがやらんでも出来るような事を、手作業で。
それ聞いて、「なんだ、そんなもんか」と思ったけどな。
内のデザイナに同じ事要求したら、「ふざけんな！プログラムで何とか出来ないの？」て言われるような事。
FF11は少し知ってるんだが、、かなり泥臭い事やってる。
デザイナがやらんでも出来るような事を、手作業で。
それ聞いて、「なんだ、そんなもんか」と思ったけどな。
内のデザイナに同じ事要求したら、「ふざけんな！プログラムで何とか出来ないの？」て言われるような事。
GPUの開発遅延で、箱○の発売は来年延期がほぼ濃厚か。PS3より発売が
遅れたら、性能で劣る箱○はまじでやばいね。テクモとか、箱○に荷担
しているメーカーも会社も業績に影響が出るのは必至か。
遅れたら、性能で劣る箱○はまじでやばいね。テクモとか、箱○に荷担
しているメーカーも会社も業績に影響が出るのは必至か。
ますますドリキャス臭が漂ってきた
この際R600を載せてくりゃいいのに
DVDもHDDVD
DVDもHDDVD
G70<>RSXと違って
R500<>R520は完全な別設計
目標性能以外に共通点はないよ
R500<>R520は完全な別設計
目標性能以外に共通点はないよ
R500もR520も、同じTSMCの90nmプロセスで製造で、R520の開発が遅延して
いるのは、製造上の問題だから、R500もやばいでしょ。
いるのは、製造上の問題だから、R500もやばいでしょ。
RSXもR500もなんかパットしない。
X-GPUが一番よかったな
今でも画質の面で見劣りしない
いくらシェーダー性能が上がってもそれだけなんだよ
ちょっとプレームが安定するかとかいうその程度の
違い。５年先でも見劣りしないGPUをつくって欲しい。
X-GPUが一番よかったな
今でも画質の面で見劣りしない
いくらシェーダー性能が上がってもそれだけなんだよ
ちょっとプレームが安定するかとかいうその程度の
違い。５年先でも見劣りしないGPUをつくって欲しい。
>>479
R520で問題が生じているのはTSMC 90nmプロセスにおけるリーク電流だろ？
これはR500にも当然問題になるよ。R500にのみ何らかのリーク電流対策をしていないと駄目。
しかも、後藤なんかはR520も分離シェーダだと言ってるけどな。
もしそれが本当ならR500とR520は共通点が多い。
R520で問題が生じているのはTSMC 90nmプロセスにおけるリーク電流だろ？
これはR500にも当然問題になるよ。R500にのみ何らかのリーク電流対策をしていないと駄目。
しかも、後藤なんかはR520も分離シェーダだと言ってるけどな。
もしそれが本当ならR500とR520は共通点が多い。
>472
ソースは出せないけど、確実に内部状況知ってる人間にそこまで遅れているとは聞かなかったんだけどな。
R500とR520もeDRAM以外同じようなアーキテクチャだともいってた。
自分がだまされただけなのか？
ソースは出せないけど、確実に内部状況知ってる人間にそこまで遅れているとは聞かなかったんだけどな。
R500とR520もeDRAM以外同じようなアーキテクチャだともいってた。
自分がだまされただけなのか？
ATIの中の人のインタビューでは、
XenosとR520は全く異なる、というわけではないって言ってたな。
仮にXenosとR520が同一アーキテクチャだとしても、
24パイプモノ(Xenos相当？)は通常のハイエンドGPU並に取れるらしいし、
クロックも500MHｚと低いわけで、それほど大きな問題ではないような。
XenosとR520は全く異なる、というわけではないって言ってたな。
仮にXenosとR520が同一アーキテクチャだとしても、
24パイプモノ(Xenos相当？)は通常のハイエンドGPU並に取れるらしいし、
クロックも500MHｚと低いわけで、それほど大きな問題ではないような。
とっくに発表・販売されているはずのチップが遅れていることは確か。
PC向けチップがBF2特需に乗れていないのは痛いと思う。
PC向けチップがBF2特需に乗れていないのは痛いと思う。
>>484
ソースも出せないような情報を、どう信じろと？
ソースも出せないような情報を、どう信じろと？
通常のハイエンド品と同等なら、年300万程度の生産量はある訳だし、
歩留まりは時間がたつにつれ向上するので、問題はほとんどないだろう
歩留まりは時間がたつにつれ向上するので、問題はほとんどないだろう
>>484
内部事情知ってる人間が、流れたら痛手になるようなことを外部のものに話すわけないと思うが。
内部事情知ってる人間が、流れたら痛手になるようなことを外部のものに話すわけないと思うが。
生産が遅れるならR500はボツにしそう
年300万じゃ 日米欧で発売3日で品切れだろｗ
それとも、XBOX360ではそれで十分なのかな？
それとも、XBOX360ではそれで十分なのかな？
んじゃ次スレのタイトルは
【ゲーム総合】次世代機テクノロジー11【スレ】
にでもするとしよう。
【ゲーム総合】次世代機テクノロジー11【スレ】
にでもするとしよう。
RSXもリーク電流の問題が・・・
急遽110nm版を投入し
クロックも落とす
急遽110nm版を投入し
クロックも落とす
>487、他
ごめん、信じてもらいたいわけじゃないので適当に流して。
ごめん、信じてもらいたいわけじゃないので適当に流して。
90nmでの高クロック製品の生産能力でいえば
実績のないソニー東芝FabのRSXの方が遥かに危険
実績のないソニー東芝FabのRSXの方が遥かに危険
>>496
ソースでも引っ張ってきてから言ってくれ
ソースでも引っ張ってきてから言ってくれ
このスレ、ソース、ソースいう奴
ウザすぎ
ウザすぎ
ソニーはトランスメタの社員を大量に雇って、リーク電流対策に
LongRun2の実装をしてくるだろうから、R500よりは歩留まりいい
だろう。
LongRun2の実装をしてくるだろうから、R500よりは歩留まりいい
だろう。
このスレをよく読めばわかるけど、反論出来ない時の逃げの言葉ですから
＞ソースを出せ
＞ソースを出せ
ネット上にすら根拠の無い噂話のほうがウザいです
R500はNECのUX6でつくられるのですよ
R520はすでに２度再設計して、32パイプはほとんど取れず、24パイプ
取れたらラッキー、大半は16パイプらしく、いま三度目の再設計で、
設計完了が一ヶ月から一ヶ月半だから、順調に行って８月中旬から９
月にテープアウト、それから製品発売まで二ヶ月として１０～１１月
に店頭に並ぶ。
一方、R500は（もう少し構造が単純な）48パイプの統合シェーダー。
48パイプを数百万チップ確保するのは今年いっぱいは無理だろうね。
取れたらラッキー、大半は16パイプらしく、いま三度目の再設計で、
設計完了が一ヶ月から一ヶ月半だから、順調に行って８月中旬から９
月にテープアウト、それから製品発売まで二ヶ月として１０～１１月
に店頭に並ぶ。
一方、R500は（もう少し構造が単純な）48パイプの統合シェーダー。
48パイプを数百万チップ確保するのは今年いっぱいは無理だろうね。
LR2は技術的にまだ載せらないんじゃないかとかいう話が昔あった気がするけど、
あれってeDRAMがくっついてる場合だっけ？
あれってeDRAMがくっついてる場合だっけ？
＞R500はNECのUX6でつくられるのですよ
それは別ダイのeDRAM部分だけ。GPU本体はTSMC。
それは別ダイのeDRAM部分だけ。GPU本体はTSMC。
>>503
eDRAM+ロジック部分だけNECで、メインは台湾じゃなかったっけ？
eDRAM+ロジック部分だけNECで、メインは台湾じゃなかったっけ？
ID:8lRWG0WRの発言などを読んでいると
いかにソースが大事か痛感いたしますw
いかにソースが大事か痛感いたしますw
ソースのない英語の書き込みがなぜかこのスレではソースになってしまう件
UX6は工場ではありませよ
>>501
yokattane
yokattane
ソースなんて基本的に張られてもすぐどこにいったか
忘れるしいちいちアドレスまでも保存しているのか？
過去ログからも探すのもめんどくさい
忘れるしいちいちアドレスまでも保存しているのか？
過去ログからも探すのもめんどくさい
RSXもTSMC?
>>504
レボは発売遅いんだから、それで別に大きな問題はないんじゃね？
レボは発売遅いんだから、それで別に大きな問題はないんじゃね？
>>516
すまん、R500のほうの話か。勘違いしたよ
すまん、R500のほうの話か。勘違いしたよ
>>510
サンクス。
ttp://pc.watch.impress.co.jp/docs/2004/1220/kaigai142.htm
SOIとeDRAMの共存が難しいということはeDRAM+LR2の可能性があるのか。
サンクス。
ttp://pc.watch.impress.co.jp/docs/2004/1220/kaigai142.htm
SOIとeDRAMの共存が難しいということはeDRAM+LR2の可能性があるのか。
事前のリーク情報は実は中国経由なんだが
PC関連やその周辺のリークなら中国経由の情報はかなり確度が高い。
GPUやCPU、マザーボード関連のベンチなどは事後の情報とほとんど重なる。
情報セキュリティが甘くて重要情報ダダ漏れの裏返しではあるが。
GPUやCPU、マザーボード関連のベンチなどは事後の情報とほとんど重なる。
情報セキュリティが甘くて重要情報ダダ漏れの裏返しではあるが。
>>524
そんな管理が甘いところで作っているRSXっていったい．．．。
そんな管理が甘いところで作っているRSXっていったい．．．。
NECで製造する石の方の噂は全然伝わってこないが
こーゆー場合は順調にいってる証拠だな
こーゆー場合は順調にいってる証拠だな
>>468
続編はともかく、復刻を考えて効率を犠牲にし汎用性や保守性を優先するのは
無駄でしか無いとおもうが
復刻ならプログラムそのものではなく、ドキュメントやデータ、詳細仕様の方が
圧倒的に重要じゃないか？どうせコードはそのままじゃ使えないし、詳細なドキュメントと
元データがあれば移植プログラム自体は大して難しく無いだろう
まぁ、汎用性や保守性にしたって、全てをCellベッタリにする必要は無いのだから
高速化が必要な部分だけ対応するようにすれば、そんなに犠牲になるとも思えないんだが
続編はともかく、復刻を考えて効率を犠牲にし汎用性や保守性を優先するのは
無駄でしか無いとおもうが
復刻ならプログラムそのものではなく、ドキュメントやデータ、詳細仕様の方が
圧倒的に重要じゃないか？どうせコードはそのままじゃ使えないし、詳細なドキュメントと
元データがあれば移植プログラム自体は大して難しく無いだろう
まぁ、汎用性や保守性にしたって、全てをCellベッタリにする必要は無いのだから
高速化が必要な部分だけ対応するようにすれば、そんなに犠牲になるとも思えないんだが
>>528
そういう話も踏まえた上で、
＞ゲーム業界なんてハードが切り替われば過去の
資産なんて使い物にならなくなる
というのは違うんじゃ？と言ってる訳だよ。
ゲームエンジン側でカリカリの最適化が必要だとは思えないし、
エンジン部分と仕様は分かり易く分けるべきだし。
で、Cellアーキテクチャがどれだけ汎用性等を犠牲にするかは
ちょっと想像付かない。が、他よりかは依存性が強そう。
因みに、C++やスマートポインタは賛成派？反対派？俺は推進派。
とあるミドルウェアでは、恐ろしくクラスのネストが深い構成になってる。
でも、パフォーマンスは全然高いんだよね。
効率の面から言うと、コードでの最適化なんて、余程ハードよりな部分以外はナンセンスだし、
そういう風潮になって来てると思うんだが。君の周りではそうじゃない？
そういう話も踏まえた上で、
＞ゲーム業界なんてハードが切り替われば過去の
資産なんて使い物にならなくなる
というのは違うんじゃ？と言ってる訳だよ。
ゲームエンジン側でカリカリの最適化が必要だとは思えないし、
エンジン部分と仕様は分かり易く分けるべきだし。
で、Cellアーキテクチャがどれだけ汎用性等を犠牲にするかは
ちょっと想像付かない。が、他よりかは依存性が強そう。
因みに、C++やスマートポインタは賛成派？反対派？俺は推進派。
とあるミドルウェアでは、恐ろしくクラスのネストが深い構成になってる。
でも、パフォーマンスは全然高いんだよね。
効率の面から言うと、コードでの最適化なんて、余程ハードよりな部分以外はナンセンスだし、
そういう風潮になって来てると思うんだが。君の周りではそうじゃない？
SPE向けに最適化されたライブラリが高い性能で動作すれば、
開発者は高水準のPPEコードを書くだけでよくなる、という考え方もあると思うけどね。
Cell依存のコードが局所化できない、ということはないので、要は書き方、使い方だと思うけど。
開発者は高水準のPPEコードを書くだけでよくなる、という考え方もあると思うけどね。
Cell依存のコードが局所化できない、ということはないので、要は書き方、使い方だと思うけど。
>>530
んー、それならカリカリの最適化が必要じゃない部分はPPEで処理すれば
いいんじゃないかな？CellはPPEまで含めてCellなのだし
で、SPEが活用できる部分はルーチン単位でSPEに投げるようにすれば、お手軽に
高速化可能 と
ちなみに、C++やスマートポインタは賛成派だよ、ただしスマートポインタにベッタリ
頼るぐらいなら別の言語使う派だけど
あと、クラスのネストって継承関係の事なら、きっちり設計されていれば、仮想関数を
大量に使わない限り、いくらネストしてもパフォーマンスへの影響は大した事無いのでは？
プログラミングの手間という効率から考えれば、ハードウェアベッタリの最適化をするのは
ナンセンスと言う事はわかるけど、ハード能力をしっかりと活用する事が望まれるゲーム
プログラミングではナンセンスとは思わないなぁ
そりゃ、楽に組めるに越した事は無いけどね
んー、それならカリカリの最適化が必要じゃない部分はPPEで処理すれば
いいんじゃないかな？CellはPPEまで含めてCellなのだし
で、SPEが活用できる部分はルーチン単位でSPEに投げるようにすれば、お手軽に
高速化可能 と
ちなみに、C++やスマートポインタは賛成派だよ、ただしスマートポインタにベッタリ
頼るぐらいなら別の言語使う派だけど
あと、クラスのネストって継承関係の事なら、きっちり設計されていれば、仮想関数を
大量に使わない限り、いくらネストしてもパフォーマンスへの影響は大した事無いのでは？
プログラミングの手間という効率から考えれば、ハードウェアベッタリの最適化をするのは
ナンセンスと言う事はわかるけど、ハード能力をしっかりと活用する事が望まれるゲーム
プログラミングではナンセンスとは思わないなぁ
そりゃ、楽に組めるに越した事は無いけどね
ヘッドルーム！
ヘッドルーム！
ヘッドルーム！
そういや昔Max Headroomってあったなぁ
>>532
＞SPEが活用できる部分はルーチン単位でSPEに投げるようにすれば、お手軽に
高速化可能
もしそうできるのであれば、いいんだけど。
スクラッチパッドスタックのように、コードサイズがオーバーした途端暴走。とかは勘弁して欲しい。
＞仮想関数を大量に使わない限り、いくらネストしてもパフォーマンスへの影響は大した事無いのでは？
そうだけど、うるさい人は際限なく言うしね。
＞ハード能力をしっかりと活用する事が望まれるゲーム
プログラミングではナンセンスとは思わないなぁ
少なくとも、今の国内ゲームのレベルとハード能力から考えれば、
歪なコード書かないといけないようなケースは、そうはないかと。
次世代でどう変わるのかはわからないけど、時代の流れを逆流して欲しくは無いな。と。
＞SPEが活用できる部分はルーチン単位でSPEに投げるようにすれば、お手軽に
高速化可能
もしそうできるのであれば、いいんだけど。
スクラッチパッドスタックのように、コードサイズがオーバーした途端暴走。とかは勘弁して欲しい。
＞仮想関数を大量に使わない限り、いくらネストしてもパフォーマンスへの影響は大した事無いのでは？
そうだけど、うるさい人は際限なく言うしね。
＞ハード能力をしっかりと活用する事が望まれるゲーム
プログラミングではナンセンスとは思わないなぁ
少なくとも、今の国内ゲームのレベルとハード能力から考えれば、
歪なコード書かないといけないようなケースは、そうはないかと。
次世代でどう変わるのかはわからないけど、時代の流れを逆流して欲しくは無いな。と。
>>535
＞スクラッチパッドスタックのように、コードサイズがオーバーした途端暴走。とかは勘弁して欲しい。
さすがにフルのC,C++がサポートされている環境なのだから、そんな事は無いと思うけどね
IBMとSCEと東芝がどこまでプログラミング環境を整えるか次第だがIBMがCellブレード
サーバーを作ってるのだから、そんなに酷い環境と言う事は無いと思うよ、
もちろん個人的な推測(妄想)だけどね
さすがに、今PS3を触れるような人からのリークはありえないだろうし
＞時代の流れを逆流して欲しくは無いな。と。
理想で言えばそうだけど、ある程度の最適化はどんな物にでも付き物だからねぇ
コンパイラが素晴らしく賢くなってくれれば、将来的にはそうなるのかもしれないけれど
TLPに向かいつつある現状でも、綺麗にスレッド分けしてくれるコンパイラなんて無い訳で
性能をそんなに求めないなら可能なんだろうけど、ゲームだとどうしても性能を追い求める
方向になっちゃうだろうし
＞スクラッチパッドスタックのように、コードサイズがオーバーした途端暴走。とかは勘弁して欲しい。
さすがにフルのC,C++がサポートされている環境なのだから、そんな事は無いと思うけどね
IBMとSCEと東芝がどこまでプログラミング環境を整えるか次第だがIBMがCellブレード
サーバーを作ってるのだから、そんなに酷い環境と言う事は無いと思うよ、
もちろん個人的な推測(妄想)だけどね
さすがに、今PS3を触れるような人からのリークはありえないだろうし
＞時代の流れを逆流して欲しくは無いな。と。
理想で言えばそうだけど、ある程度の最適化はどんな物にでも付き物だからねぇ
コンパイラが素晴らしく賢くなってくれれば、将来的にはそうなるのかもしれないけれど
TLPに向かいつつある現状でも、綺麗にスレッド分けしてくれるコンパイラなんて無い訳で
性能をそんなに求めないなら可能なんだろうけど、ゲームだとどうしても性能を追い求める
方向になっちゃうだろうし
>>537
なんかCPUに関してはどっちもボロカスに言われてますな。
XBOX360のCPUはﾋﾟｰｸ性能（ｶﾀﾛｸﾞｽﾍﾟｯｸ）重視、Pen4、Athlon64クラスに及ばない実性能
CellはSPEはあんまり使えない、DMAは遅い。LS小さすぎPPEが冴えない。
開発環境はPSはPS2の大成功があったから、変なｱｰｷでも開発者は気にせずにゲーム開発するだろう
XBOX360は開発者の要望を聞きまくってたのに、いざ出てきたら望んでたものじゃなかった。マルチコアなんていらないのに・・・
GPUはRSXはﾀｰﾎﾞｷｬｯｼｭ積んだ90nmのG70。出来はすこぶる良い。
1080pが目標だが、殆どの開発者は720pを目標にしてる。AAx4はあんまり重要ではない。
Xenonもいいらしい。RSXと同じぐらい
なんかCPUに関してはどっちもボロカスに言われてますな。
XBOX360のCPUはﾋﾟｰｸ性能（ｶﾀﾛｸﾞｽﾍﾟｯｸ）重視、Pen4、Athlon64クラスに及ばない実性能
CellはSPEはあんまり使えない、DMAは遅い。LS小さすぎPPEが冴えない。
開発環境はPSはPS2の大成功があったから、変なｱｰｷでも開発者は気にせずにゲーム開発するだろう
XBOX360は開発者の要望を聞きまくってたのに、いざ出てきたら望んでたものじゃなかった。マルチコアなんていらないのに・・・
GPUはRSXはﾀｰﾎﾞｷｬｯｼｭ積んだ90nmのG70。出来はすこぶる良い。
1080pが目標だが、殆どの開発者は720pを目標にしてる。AAx4はあんまり重要ではない。
Xenonもいいらしい。RSXと同じぐらい
DMAが遅いとか誰が言ってんの？頭の中にいる人か？
情報源として胡散くさすぎ
マルチコアにしないでも性能向上が見込めるならともかく、クロックが上がらない
現状じゃ、どうにもならないと解ってるだろうに・・・
RSXがターボキャッシュ積んだG70という情報は気になる情報だけどね
マルチコアにしないでも性能向上が見込めるならともかく、クロックが上がらない
現状じゃ、どうにもならないと解ってるだろうに・・・
RSXがターボキャッシュ積んだG70という情報は気になる情報だけどね
From those that have had experience with the PS3 development kits,
this access takes far too long to be used in many real world scenarios.
ああこれか。real world scenariosとか怪しい言い回しだな。
this access takes far too long to be used in many real world scenarios.
ああこれか。real world scenariosとか怪しい言い回しだな。
Cellはともかく、360 CPUがなぜすでにあるPPC970コアよりもシングルスレッド性能の低い
(同クロックで半分?)PPEを採用したのか、という疑問は確かにある。
(同クロックで半分?)PPEを採用したのか、という疑問は確かにある。
>>544
サイズもでかいし、超爆熱になるからだろ。PPEx3でもやばいと言われてるんだから。
サイズもでかいし、超爆熱になるからだろ。PPEx3でもやばいと言われてるんだから。
ピーク性能は捨てて、970コア+大容量L2キャッシュで勝負するのだ。
これでこそ開発者のためのハードウェアであろう。
まあ、それも寂しいか。
これでこそ開発者のためのハードウェアであろう。
まあ、それも寂しいか。
PPE 3個 って、むしろバランスが悪いかもね・・
SIMD演算を強化したいなら、Cellがいいし、
コアとしての性能を伸ばすなら 簡略化せずにG5を無理してでも3個載せれば良かった。
しかし、もしかしたら PS3にxenonのCPUが載ってた可能性もあったわけだよな、当初の設計案では・・
SIMD演算を強化したいなら、Cellがいいし、
コアとしての性能を伸ばすなら 簡略化せずにG5を無理してでも3個載せれば良かった。
しかし、もしかしたら PS3にxenonのCPUが載ってた可能性もあったわけだよな、当初の設計案では・・
>>544
The one statement that we heard over and over again was that Microsoft was sold on the peak theoretical performance of the Xenon CPU.
極力コストをかけず、ピーク性能を重視したからじゃね？
VMXで簡単にピーク性能だけUP
The one statement that we heard over and over again was that Microsoft was sold on the peak theoretical performance of the Xenon CPU.
極力コストをかけず、ピーク性能を重視したからじゃね？
VMXで簡単にピーク性能だけUP
>>540
元発言は、ゲームプログラムの実行を想定した上で丁寧に
分析してるのに（その中身は、このスレたCellスレで推測されてきたことに近い）
＞XBOX360のCPUはﾋﾟｰｸ性能（ｶﾀﾛｸﾞｽﾍﾟｯｸ）重視、Pen4、Athlon64クラスに及ばない実性能
＞CellはSPEはあんまり使えない、DMAは遅い。LS小さすぎPPEが冴えない。
次元の低い要約すんなよ。要約だけ見て語る馬鹿もいるんだから。
元発言は、ゲームプログラムの実行を想定した上で丁寧に
分析してるのに（その中身は、このスレたCellスレで推測されてきたことに近い）
＞XBOX360のCPUはﾋﾟｰｸ性能（ｶﾀﾛｸﾞｽﾍﾟｯｸ）重視、Pen4、Athlon64クラスに及ばない実性能
＞CellはSPEはあんまり使えない、DMAは遅い。LS小さすぎPPEが冴えない。
次元の低い要約すんなよ。要約だけ見て語る馬鹿もいるんだから。
SPEのDMAは粒度が荒いので(128バイトだっけ?)、
普通にメインメモリの4バイトだけアクセスしたいときは「遅い」だろう。
普通にメインメモリの4バイトだけアクセスしたいときは「遅い」だろう。
MS-Intel間の交渉が不調に終わる
↓
IBMとの交渉に緊急に切り替え
↓
PPC970からゲーム機にいらない部分をカット＆必要な機能を拡張したものをオーダー
↓
ゲーム機に不要な部分をカットしたものはPPEならあるが、拡張となると設計の時間が厳しい
↓
PPE*3のマルチコアで対応
こんな感じじゃね？
↓
IBMとの交渉に緊急に切り替え
↓
PPC970からゲーム機にいらない部分をカット＆必要な機能を拡張したものをオーダー
↓
ゲーム機に不要な部分をカットしたものはPPEならあるが、拡張となると設計の時間が厳しい
↓
PPE*3のマルチコアで対応
こんな感じじゃね？
970コアはAppleとの絡みで、ゲーム機用の値段では売れないのかもしれんね。
>>552
PS3のGPUみたいな感じか。
cellGPUのパフォーマンスがあまりよろしくない
↓
Nvidiaとの交渉に緊急に切り替え
↓
cellと協調動作できる新しいGPUをオーダー
↓
6800の改良版のG70ならあるが、新設計となると設計の時間が厳しい
↓
G70クロックアップ版で対応
PS3のGPUみたいな感じか。
cellGPUのパフォーマンスがあまりよろしくない
↓
Nvidiaとの交渉に緊急に切り替え
↓
cellと協調動作できる新しいGPUをオーダー
↓
6800の改良版のG70ならあるが、新設計となると設計の時間が厳しい
↓
G70クロックアップ版で対応
cellはGPUにしたらもっと性能でなかったよ
あの英文ではボロカスにいわれてるから
nvidiaはいい仕事したんだろ
あの英文ではボロカスにいわれてるから
nvidiaはいい仕事したんだろ
実際、RSXは 要求性能を十二分に満たしてるだろう？
いい設計だよ。ゲーム製作者も少し安心したのでは。
最悪でも、どんな技術不足な会社でもPPEとRSXだけなら扱えるだろう。
PPEだけでもP4より高性能なんだろ？
いい設計だよ。ゲーム製作者も少し安心したのでは。
最悪でも、どんな技術不足な会社でもPPEとRSXだけなら扱えるだろう。
PPEだけでもP4より高性能なんだろ？
これ前にｶﾞｲｼｭﾂの記事じゃん
この記事を書いた奴は後藤以下の
前知識の持ち主だと書いた覚えがある
この記事を書いた奴は後藤以下の
前知識の持ち主だと書いた覚えがある
普通に考えて両者のパフォーマンスを詳細に知っててリークするやつなんていないだろ
そんなのはこのスレだって一緒だ
Attendうんたらとかいうに載った記事か？
一つだけ確かな事はID:AlTZ22OSがID:oycdOqFP以下のツマラン香具師だってことだ。
ってか普通に考えてCELLへぼでしょう？
RmUTmFy8 ＝ oycdOqFP
か。いつもの人乙。 キミの脳内ではヘボなんだろうなぁｗ
か。いつもの人乙。 キミの脳内ではヘボなんだろうなぁｗ
MSって最初はインテルCPUで行こうとしてたの？
つ 凶
>>567
？
？
>>566
Intelの人が採算が合わないからと降りたとの記事を読んだことがある。
Intelの人が採算が合わないからと降りたとの記事を読んだことがある。
もしIntelチップだとしたらPenD乗せられる所だったろうから
ユーザーとしてはIntelが蹴ってくれて助かったんじゃない？
ユーザーとしてはIntelが蹴ってくれて助かったんじゃない？
PS4では 最初からIBM・nVIDIAと協力してやってほしい。
572 ：名無しさん必死だな：2005/07/10(日) 03:17:48 ID:G7pKTaot
>>556
PPEだけだと確実にP4に負ける、VMX強化版の箱○PPEにさえも負ける。
PPEだけだと確実にP4に負ける、VMX強化版の箱○PPEにさえも負ける。
クタの話だとRSXはNVIDIAと組むことの第一歩みたいなこと言ってたが。
IBMの副社長も日経のインタビューで、既にCellの第二世代の設計思想
についてソニーと議論を始めたとか言ってた。
実際は5年先のこの世界がどうなるかなんて全くわからんが。
IBMの副社長も日経のインタビューで、既にCellの第二世代の設計思想
についてソニーと議論を始めたとか言ってた。
実際は5年先のこの世界がどうなるかなんて全くわからんが。
箱のVMXは32本から128本へレジスタ数が増えてるけど、
CELLのVMXは仕様が公開されてないから比べようもない。
ただ、スペック表から読み取れるVMXの演算性能自体は
どちらも同じ。
CELLのVMXは仕様が公開されてないから比べようもない。
ただ、スペック表から読み取れるVMXの演算性能自体は
どちらも同じ。
箱のVMXのレジスタが128本ってのがよくわからんのよ。
PowerPC ISAでは論理レジスタ32本じゃないとフォーマット的にまずいんでは？
たしかPowerPC970は物理的にはそれぞれ80本だったはずだから数自体はおかしくないと思うけど。
PowerPC ISAでは論理レジスタ32本じゃないとフォーマット的にまずいんでは？
たしかPowerPC970は物理的にはそれぞれ80本だったはずだから数自体はおかしくないと思うけど。
http://pc.watch.impress.co.jp/docs/2005/0514/kaigai178.htm
> VMX自体も拡張されている。PowerPC系のVMXは、もともと128bitレジスタを
> 32本備えていた。しかし、Xenon CPUのVMXは、各CPUコアに128本のVMXレジス
> タ(VRF)がある。明記されていないが、これは物理レジスタだけでなく論理レ
> ジスタも128本になっていると見られる。
この書き方だと、特に根拠はないんじゃないかという気が…
> VMX自体も拡張されている。PowerPC系のVMXは、もともと128bitレジスタを
> 32本備えていた。しかし、Xenon CPUのVMXは、各CPUコアに128本のVMXレジス
> タ(VRF)がある。明記されていないが、これは物理レジスタだけでなく論理レ
> ジスタも128本になっていると見られる。
この書き方だと、特に根拠はないんじゃないかという気が…
CELLのVMXは32本(IBMのサイトかどっかで見た記憶有り)、Xenonのは128本(リーク文書)。
360 CPUのVMXのレジスタ128本は公式に発表されてるんだけれども、
元々のVMXの命令フォーマットはレジスタ32本用だから、どう対応してるんだろうね? という話。
レジスタ指定を5bit→7bitに拡張したVMX命令なのか、register renamingで暗黙に使うのか。
元々のVMXの命令フォーマットはレジスタ32本用だから、どう対応してるんだろうね? という話。
レジスタ指定を5bit→7bitに拡張したVMX命令なのか、register renamingで暗黙に使うのか。
ゲーム機用に命令セット拡張しちゃいかん事は無いし
レジスタ7bitにしちゃうとPowerPCの命令フォーマットから逸脱する上に、
VMXってソース3つ、デスティネーション1つで4つレジスタ指定するんで、
opcodeとあわせて32bitにも収まらない。
カスタム命令追加のようには簡単に拡張できないでしょ。
命令セットはそのままに、970で32+48個だったVMXレジスタを、
32+96個に増やしたと考えるのが妥当ではないかと。
どの程度使えるのかはわかりませんが。
後藤タン、他にも「XenonはPPC970コアのカスタム版」とか言ってたりするんで(まだ訂正して
ない)、360ネタはけっこうあてずっぽうな感じ。
VMXってソース3つ、デスティネーション1つで4つレジスタ指定するんで、
opcodeとあわせて32bitにも収まらない。
カスタム命令追加のようには簡単に拡張できないでしょ。
命令セットはそのままに、970で32+48個だったVMXレジスタを、
32+96個に増やしたと考えるのが妥当ではないかと。
どの程度使えるのかはわかりませんが。
後藤タン、他にも「XenonはPPC970コアのカスタム版」とか言ってたりするんで(まだ訂正して
ない)、360ネタはけっこうあてずっぽうな感じ。
後藤タンはXenonに寄りすぎだと思うけどな・・・記事としては面白いかも知らんが、RSXが随分と劣ってるような錯覚を起こさせる
つーことはCellのSPEも32+96なん
CellのPPEはSIMD性能を強化する必要性薄いし、VMX拡張はMS向けの別メニューかも。
カタログスペックは理論ピーク値なので、そのへんの差が数字に現れてなくても
不思議はない。
カタログスペックは理論ピーク値なので、そのへんの差が数字に現れてなくても
不思議はない。
CellのSPEはPPCとはまったく無関係。
>>582
後藤タンはCPUに関しては、Cellに入れ込んで
GPUに関してはXenosに入れ込んでるけど
ハードヲタ的には普通の姿と違うかな？
特に後藤たんの場合、過去記事からも
統合シェーダは心待ちにしてた感じだし。
Cell発表 (ﾟ∀ﾟ)=3 ﾑｯﾊｰ → 直後にPentiumD発表 ('A`)
Xenos発表 (ﾟ∀ﾟ)=3 ﾑｯﾊｰ → RSX発表 ('A`)
この記事のテンションの落差は読んでて笑えたw
後藤タンはCPUに関しては、Cellに入れ込んで
GPUに関してはXenosに入れ込んでるけど
ハードヲタ的には普通の姿と違うかな？
特に後藤たんの場合、過去記事からも
統合シェーダは心待ちにしてた感じだし。
Cell発表 (ﾟ∀ﾟ)=3 ﾑｯﾊｰ → 直後にPentiumD発表 ('A`)
Xenos発表 (ﾟ∀ﾟ)=3 ﾑｯﾊｰ → RSX発表 ('A`)
この記事のテンションの落差は読んでて笑えたw
>>582
後藤氏は新しい物好きだからな。
新技術にチャレンジとか、凝ったギミックとか、そういうのに萌えるんだよ。
製品の価値としては、既存の技術でもうまくまとめ上げた物のほうが
高い場合も多くて、彼もその価値はきちんと認めるんだけど、萌えない。
後藤氏が新製品のレビューとかしないのは、彼自身がそれをちゃんと認識しているから
かもしれない。
後藤氏は新しい物好きだからな。
新技術にチャレンジとか、凝ったギミックとか、そういうのに萌えるんだよ。
製品の価値としては、既存の技術でもうまくまとめ上げた物のほうが
高い場合も多くて、彼もその価値はきちんと認めるんだけど、萌えない。
後藤氏が新製品のレビューとかしないのは、彼自身がそれをちゃんと認識しているから
かもしれない。
>>582
後藤氏をXenos偏重と言うけど、この凄まじいほど
Cell偏重ぶりにくらべれば、全然たいしたことないです。
ttp://pc.watch.impress.co.jp/docs/2005/0208/kaigai153.htm
ttp://pc.watch.impress.co.jp/docs/2005/0209/kaigai154.htm
ttp://pc.watch.impress.co.jp/docs/2005/0211/kaigai155.htm
ttp://pc.watch.impress.co.jp/docs/2005/0212/kaigai156.htm
ttp://pc.watch.impress.co.jp/docs/2005/0212/kaigai157.htm
ttp://pc.watch.impress.co.jp/docs/2005/0218/kaigai158.htm
ttp://pc.watch.impress.co.jp/docs/2005/0225/kaigai159.htm
ttp://pc.watch.impress.co.jp/docs/2005/0228/kaigai160.htm
ttp://pc.watch.impress.co.jp/docs/2005/0308/kaigai163.htm
ttp://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
後藤氏をXenos偏重と言うけど、この凄まじいほど
Cell偏重ぶりにくらべれば、全然たいしたことないです。
ttp://pc.watch.impress.co.jp/docs/2005/0208/kaigai153.htm
ttp://pc.watch.impress.co.jp/docs/2005/0209/kaigai154.htm
ttp://pc.watch.impress.co.jp/docs/2005/0211/kaigai155.htm
ttp://pc.watch.impress.co.jp/docs/2005/0212/kaigai156.htm
ttp://pc.watch.impress.co.jp/docs/2005/0212/kaigai157.htm
ttp://pc.watch.impress.co.jp/docs/2005/0218/kaigai158.htm
ttp://pc.watch.impress.co.jp/docs/2005/0225/kaigai159.htm
ttp://pc.watch.impress.co.jp/docs/2005/0228/kaigai160.htm
ttp://pc.watch.impress.co.jp/docs/2005/0308/kaigai163.htm
ttp://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
591 ：名無しさん必死だな：2005/07/10(日) 11:23:13 ID:YHcfE2Pu
後藤ﾀﾝはPSよりだったんだけど、GPUが自分の想像してたのとまったく違ったのが相当ご立腹だったみたい。
最初のPS3スペック発表時、RSXこき下ろした後のXenosのﾏﾝｾｰ振りがすごひ。
しかもどちらも想像で筆走らせてるありさま。
最初のPS3スペック発表時、RSXこき下ろした後のXenosのﾏﾝｾｰ振りがすごひ。
しかもどちらも想像で筆走らせてるありさま。
>>377で何気にスルーされてるけど
http://www.bit-tech.net/news/2005/07/07/g70_clock_speed/
この記事の内容、結構おもろしくね？
>The clock speeds within the chip are dynamic
>three visible clocks did (that's the ROP clock, pixel clock and geometry clock if you're still playing catchup).
なんかジオメトリー部、ピクセル部、ROP部のクロックが
負荷に応じてそれぞれ動的に変わるらしい。
なんかまるで非同期クロックチップを思い出させる感じ。
http://www.bit-tech.net/news/2005/07/07/g70_clock_speed/
この記事の内容、結構おもろしくね？
>The clock speeds within the chip are dynamic
>three visible clocks did (that's the ROP clock, pixel clock and geometry clock if you're still playing catchup).
なんかジオメトリー部、ピクセル部、ROP部のクロックが
負荷に応じてそれぞれ動的に変わるらしい。
なんかまるで非同期クロックチップを思い出させる感じ。
Xenosのテクスチャーパイプって
テクスチャーフィルターとか行えるのですかね？
それともフェッチのみでSIMD演算機で行う？
テクスチャーフィルターとか行えるのですかね？
それともフェッチのみでSIMD演算機で行う？
CELLって本当に性能良いのかね・・
CELLにがんばって欲しいけど、海外あたりの分析見ると相当駄目っぽいので不安だなぁ
CELLにがんばって欲しいけど、海外あたりの分析見ると相当駄目っぽいので不安だなぁ
スレ違いを気にしてこっちにも書き込んだのは分かるが
反射的にただのマルチポストに見えてしまう２ちゃんねる脳の悲しさ
反射的にただのマルチポストに見えてしまう２ちゃんねる脳の悲しさ
○はGI搭載
RSXのレジスタ数が十分なので、
シリーズパラレル型レジスタ生存グラフを用いた方法、
並列性を抽出・レジスタ数が多いても良い結果、ベクトルプロセッサはレジスタ数が非常に多い上に、
ベクトル演算であるが故にレジスタに必要なトランジスタ数がベクトル化倍だけ多いので、３６０より楽です。
シリーズパラレル型レジスタ生存グラフを用いた方法、
並列性を抽出・レジスタ数が多いても良い結果、ベクトルプロセッサはレジスタ数が非常に多い上に、
ベクトル演算であるが故にレジスタに必要なトランジスタ数がベクトル化倍だけ多いので、３６０より楽です。
599 ：名無しさん必死だな：2005/07/10(日) 12:25:02 ID:jWOjz1m5
Cellはベンチ結果がいいので、開発者が慣れたりライブラリが整備されればよく活きるだろう
CELL版GPUではなくRSXを採用した理由
単位データに対する演算量は少ないが
大量にデータを処理しなければならない場合、
やっぱりCELLでは不向きと判断したのではないか・・
単位データに対する演算量は少ないが
大量にデータを処理しなければならない場合、
やっぱりCELLでは不向きと判断したのではないか・・
あの長い英語の長文だろ
XBOX360のコアは実際のゲームでは
一個しか使われないだろとか書いてた記事ね。
あの記事はどうも…
一個しか使われないだろとか書いてた記事ね。
あの記事はどうも…
ベンチってアテにならないんだよね、同一環境で同一ソフトで実行すれば
ある程度信頼性はあるんだろうけど、得て不得手やちょっとした事で数値
は変わるし。メーカーが提示した数字なんてはなっから問題外だよ
ゲームという特殊なアプリである以上、汎用性と効率性が図られているか、
あとはハード特性の情報開示がされるか否か。
性能良いです、でも特定の方法にした場合のみってハードは問題外だな
ある程度信頼性はあるんだろうけど、得て不得手やちょっとした事で数値
は変わるし。メーカーが提示した数字なんてはなっから問題外だよ
ゲームという特殊なアプリである以上、汎用性と効率性が図られているか、
あとはハード特性の情報開示がされるか否か。
性能良いです、でも特定の方法にした場合のみってハードは問題外だな
>>593
モバイルの技術を取り入れて
クロックを可変にすることで電力消費の低減、ヒートシンクの小型化
ファンの静音化に貢献した、みたいな内容ですね。
電力を6800から大幅ダウンしたと言うが、ここに秘密があるのだね。
クロックを550MHzまで上げても大丈夫なように出来てるようだ。
モバイルの技術を取り入れて
クロックを可変にすることで電力消費の低減、ヒートシンクの小型化
ファンの静音化に貢献した、みたいな内容ですね。
電力を6800から大幅ダウンしたと言うが、ここに秘密があるのだね。
クロックを550MHzまで上げても大丈夫なように出来てるようだ。
>>606
これは凄いことなのか？
これは凄いことなのか？
＞Shader Clock：430MHz/Rop Clock：430MHz/Geometry Clock：470MHz
このGeometryってのは どこにあるの？
シェーダやROPとは違う場所にある演算機？
このGeometryってのは どこにあるの？
シェーダやROPとは違う場所にある演算機？
中身の使用状況を見ながらクロックを変えてるのかもね
同じゲームならオーバークロックしても中身の使い方は違わないから
各ユニット（Shader,Rop,Geometry）のクロック比は変わらない
停止したとたん基本の430にもどる
おもしろ～
同じゲームならオーバークロックしても中身の使い方は違わないから
各ユニット（Shader,Rop,Geometry）のクロック比は変わらない
停止したとたん基本の430にもどる
おもしろ～
610 ：名無しさん必死だな：2005/07/10(日) 13:46:27 ID:DIQjAlBv
>>599
FFTベンチはCellに有利なベンチで汎用CPUのPen4を比較対称としている時点で
うさんくさいと思う、メモリ帯域が全然違うのにCellすげーとか言われても
ふーんって感じ。
せめて同じメモコン搭載しているAthlon64とやるべきじゃないかな。
FFTベンチはCellに有利なベンチで汎用CPUのPen4を比較対称としている時点で
うさんくさいと思う、メモリ帯域が全然違うのにCellすげーとか言われても
ふーんって感じ。
せめて同じメモコン搭載しているAthlon64とやるべきじゃないかな。
定格で3.2G動作するAthlon64ってあったっけ？
>>610
別にメモリ帯域がいいのは問題ないだろｗ
ゲームと無関係なベンチしかやってないのが問題なんだろ。
せめてMSくらい機材貸して3DMark作ってもらってゲーム雑誌のDVDで
プログラム自体と録画ムービー配布してくれればいいのに。
別にメモリ帯域がいいのは問題ないだろｗ
ゲームと無関係なベンチしかやってないのが問題なんだろ。
せめてMSくらい機材貸して3DMark作ってもらってゲーム雑誌のDVDで
プログラム自体と録画ムービー配布してくれればいいのに。
＞＞メモリ帯域が全然違うのに
言いがかりも極まれり。
まさに、ボトルネックとなっているメモリ帯域を向上させたのがCellアーキテクチャなんだろ。
その内、「SPEを使うなんて卑怯だ。 PPEだけで勝負しろ！」とか言い出すんじゃないだろな？
言いがかりも極まれり。
まさに、ボトルネックとなっているメモリ帯域を向上させたのがCellアーキテクチャなんだろ。
その内、「SPEを使うなんて卑怯だ。 PPEだけで勝負しろ！」とか言い出すんじゃないだろな？
>>611
AthlonFX2.8GHzと比較したらもっと差が縮まるんじゃね。
俺も遅いPen4とじゃぁ比較にならんのじゃないかと思う。
フェアにやるならPenM、Power5、Athlon64FX、Cell2.4GHz開発機で比べるべき、
AthlonFX2.8GHzと比較したらもっと差が縮まるんじゃね。
俺も遅いPen4とじゃぁ比較にならんのじゃないかと思う。
フェアにやるならPenM、Power5、Athlon64FX、Cell2.4GHz開発機で比べるべき、
ttp://www.fftw.org/speed/g5-2GHz/ PPC G5(970) 2GHz Dual
ttp://www.fftw.org/speed/itanium2-900MHz/ Itanium II, 900 MHz
ttp://www.fftw.org/speed/p3-550MHz/ Pentium III (Katmai), 550MHz
PenMは無いからPen3に周波数のスケールかけてみるぐらいしか無いねぇ
まぁ、どれにしてもCellが圧倒的なんだが
ttp://www.fftw.org/speed/itanium2-900MHz/ Itanium II, 900 MHz
ttp://www.fftw.org/speed/p3-550MHz/ Pentium III (Katmai), 550MHz
PenMは無いからPen3に周波数のスケールかけてみるぐらいしか無いねぇ
まぁ、どれにしてもCellが圧倒的なんだが
ゲーム開発に関係無いベンチでいばっているこいつらっていったい．．．。
結論としては検索エンジンすら使えない子供はROMってなさいと言う事ですね
ゲーム開発に関係のあるベンチマークなんて、過去のゲーム機において出た事
あったっけ？
少なくとも公式になんらかのベンチマーク結果を発表したゲーム機なんて、無いと思うんだが
発表されるのはピーク演算能力と、ピーク表示可能ポリゴン数ぐらいだよなぁ・・・
実効性能の数値と言われる物も、どんなソフト使ったかすら解らない状態での
公式発表では無い曖昧な数字しか見たことないぞ
あったっけ？
少なくとも公式になんらかのベンチマーク結果を発表したゲーム機なんて、無いと思うんだが
発表されるのはピーク演算能力と、ピーク表示可能ポリゴン数ぐらいだよなぁ・・・
実効性能の数値と言われる物も、どんなソフト使ったかすら解らない状態での
公式発表では無い曖昧な数字しか見たことないぞ
つまりFFTベンチはソースにはなりえないって事でFA？
そんなマイナーなベンチでいばられても・・・
FFTベンチってのは
画像や動画、音声などの圧縮や解凍といった処理の際につかわれる。
CELL搭載のエンコシステム出して・・
画像や動画、音声などの圧縮や解凍といった処理の際につかわれる。
CELL搭載のエンコシステム出して・・
あからさまな単発IDラッシュﾜﾛｽｗｗｗ
実際にゲーム機に搭載されるCPUでの実効性能を、公式なベンチマークとして発表した
非常に有益な情報でFA
他のCPUの理論ピーク性能と実行性能の比と、Cellの場合の比を比べると面白いかもね
非常に有益な情報でFA
他のCPUの理論ピーク性能と実行性能の比と、Cellの場合の比を比べると面白いかもね
意味ないベンチみたいだね
その他のベンチなら負けないぞっ、
と言いたいのだろう。
よろしい。 自分たちに有利なベンチを探してきなさい。
待ってるよ
と言いたいのだろう。
よろしい。 自分たちに有利なベンチを探してきなさい。
待ってるよ
ベンチさえ出せないCPUよりはいいと思うけどね。
それと、メモリ帯域を理由にCellが駄目だと言ってた馬鹿がいたけど、
128MBのメモリアクセスがあっても実効性能が十分出たという証明になったし。
それと、メモリ帯域を理由にCellが駄目だと言ってた馬鹿がいたけど、
128MBのメモリアクセスがあっても実効性能が十分出たという証明になったし。
マイナーなベンチって・・・
FFTはHPCチャレンジベンチでも性能評価項目に
入ってるほど重要な計算ですよ。
FFTはHPCチャレンジベンチでも性能評価項目に
入ってるほど重要な計算ですよ。
おそらくいま行われているであろうUE3エンジンのCell最適化が一つの試金石か。
それがどの程度大変で、どの程度の効果があるのかわかれば、
PS3の将来がどっちなのかも見えてくるだろう。
それがどの程度大変で、どの程度の効果があるのかわかれば、
PS3の将来がどっちなのかも見えてくるだろう。
＞フーリエ変換なんかゲームじゃムービーぐらいにしか使わないからなぁ。
なるほど
やはりベンチに意味なかったか
なるほど
やはりベンチに意味なかったか
>>633
それでもゲームには関係無い、さあどうする？
それでもゲームには関係無い、さあどうする？
>>637
その前にフーリエ変換が実際ゲームにどういう役に立つのか答えなさい（ｗ
その前にフーリエ変換が実際ゲームにどういう役に立つのか答えなさい（ｗ
ID:yysRcZ4O
いつもの人？
君にはVSスレの方がいいと思うけどな。
ベンチの中身を理解できない奴は、背伸びしてここに来ても仕方ないよ。
いつもの人？
君にはVSスレの方がいいと思うけどな。
ベンチの中身を理解できない奴は、背伸びしてここに来ても仕方ないよ。
すぐにVSスレ化するのな('A`)
それから、Cellの性能否定材料として使われやすい、LSに乗り切らない量のデータを
扱った例として、性能低下があの程度で済んでいるという意味でも非常に有益な情報
なのに・・・
扱った例として、性能低下があの程度で済んでいるという意味でも非常に有益な情報
なのに・・・
まあこの板にあるスレである以上仕方ないところ。
>>641
「ソースを出せ」「VSスレへ行け」はCell信者の敗北宣言。
「ソースを出せ」「VSスレへ行け」はCell信者の敗北宣言。
定期的に来るのはお仕事だからなのかね
アンチならソニーらしいハッタリって納得しとけば、いらぬ恥をかかないで済んだの
に、ＶＳスレにｶｴﾚ。
に、ＶＳスレにｶｴﾚ。
アンチCellの人は
ここで頑張れば頑張るほど
現実を思い知らされることになってるのに…
けなげと言うか…
ここで頑張れば頑張るほど
現実を思い知らされることになってるのに…
けなげと言うか…
いったろ？cellはItanium2だって
分散コンピューティングが一番似合っている
分散コンピューティングが一番似合っている
>>645
ソース出せ、ってのは当たり前じゃないのか？
ソース出せ、ってのは当たり前じゃないのか？
http://ascii24.com/news/i/topi/article/2004/09/06/651405-000.html
波の表現には、Gerstner(ガースナー)波形計算とFFT
(高速フーリエ変換)の統計モデルがあるが、ここではGerstner波形
を採用している。その理由として芦田氏は、FFTの統計モデルでは、
リアルな波を表現できる半面、計算(プリレンダリング)に時間が
かかること、同じ波が繰り返し出てきてしまうことなどを挙げた。
ただ、リアルタイムレンダリングの必要がない映画などではFFT
の統計モデルが使われており、同じ波の繰り返しはカメラ位置
を切り替えることなどでカバーしていることも説明した。
CELLであれば、リアルな水面波シミュレーションが実現できそう
ですね。まさにプリレンダと同じ手法が使えるんです。
波の表現には、Gerstner(ガースナー)波形計算とFFT
(高速フーリエ変換)の統計モデルがあるが、ここではGerstner波形
を採用している。その理由として芦田氏は、FFTの統計モデルでは、
リアルな波を表現できる半面、計算(プリレンダリング)に時間が
かかること、同じ波が繰り返し出てきてしまうことなどを挙げた。
ただ、リアルタイムレンダリングの必要がない映画などではFFT
の統計モデルが使われており、同じ波の繰り返しはカメラ位置
を切り替えることなどでカバーしていることも説明した。
CELLであれば、リアルな水面波シミュレーションが実現できそう
ですね。まさにプリレンダと同じ手法が使えるんです。
SPEがFFTのような連続データの処理に好適なのはさもありなんなのだが、
個人的には、(メモリ上で連続していない)linked listが
実用的な速度で扱えるのかどうかに興味がある。
個人的には、(メモリ上で連続していない)linked listが
実用的な速度で扱えるのかどうかに興味がある。
今のところ、アンチCell派には耳の痛い情報ばかりだな
いや、定量的に、どの手法でどの程度のコードの複雑化と速度悪化(対PPE比で)が
あるのかな、と。
あるのかな、と。
>>657
100レスぐらい前に出てきた
100レスぐらい前に出てきた
>>657 そのスレッドは実際にコード書いて検証した話じゃないんで、
いわばこのスレと同レベルというか…
いわばこのスレと同レベルというか…
>>658
ソースだせよ
ソースだせよ
>>660
何のソース？
何のソース？
XBOX360のCPUがXBOXのCPUの2倍程度の実効性能しか出ないと書いてある時点で・・・
2倍程度はないな
そんならkameoの群集シーンなんかできるわけないはずで
あれでさえまだαキットらしいから
そんならkameoの群集シーンなんかできるわけないはずで
あれでさえまだαキットらしいから
そういえば、CellのPPEのベンチ情報ってあったっけ。
同クロック換算のG5よりだいぶ悪いのではないかと思うのだが。
同クロック換算のG5よりだいぶ悪いのではないかと思うのだが。
問題は開発が楽かどうかじゃね
性能高かろうが低かろうがソフトレベルじゃたいした差はない
性能高かろうが低かろうがソフトレベルじゃたいした差はない
クロックが４．３倍になってるのに、実性能が二倍だったら最悪だわな。
ありえるとしたら、XBOXCPUの理論性値の二倍の実性能って事かな
ありえるとしたら、XBOXCPUの理論性値の二倍の実性能って事かな
PPE単体は見たこと無いな
色々な資料から推測するに、XBOX360 CPUのコアに近いようだが、性能についての
記述は見たこと無いな
色々な資料から推測するに、XBOX360 CPUのコアに近いようだが、性能についての
記述は見たこと無いな
性能が高ければ、富豪的プログラミングのような手法も選択できるようになる。
PPE単体の性能を考えて 何ほどの意味があるのかな？
全体で１つのCPUなのに。 一体何と比較するのか。
まさか本当にSPEを使わずにゲームを作るつもりか。
全体で１つのCPUなのに。 一体何と比較するのか。
まさか本当にSPEを使わずにゲームを作るつもりか。
>>670
2Dアドベンチャーゲームならそれでも十分だろうな、いわゆるギャルゲーの類とか
2Dアドベンチャーゲームならそれでも十分だろうな、いわゆるギャルゲーの類とか
おそらくほぼ同じコアであろう360 CPUのシングルスレッド性能が類推できる。
「XBOXのCPUの2倍程度の実効性能しか出ない」説は、おそらくシングルスレッドで
VMXを使わないコードで比較した時の話だろう。
PPEの割り切り方を考えると、これもありうる数字じゃないかと思っているのだが…
「XBOXのCPUの2倍程度の実効性能しか出ない」説は、おそらくシングルスレッドで
VMXを使わないコードで比較した時の話だろう。
PPEの割り切り方を考えると、これもありうる数字じゃないかと思っているのだが…
開発が楽～って言ってる奴は何が言いたいんだ？
企業からすれば、一番売れてるハードに開発投資するに決まってるだろ
開発者が楽～で開発投資先が決まるとでも思ってるのかね
企業からすれば、一番売れてるハードに開発投資するに決まってるだろ
開発者が楽～で開発投資先が決まるとでも思ってるのかね
cell信者言い訳見苦しい
開発コストが下げられるなら損益分岐点も下がるわけで、
特にまだ両者ともシェア0%の状態では、開発の容易さは機種選定の上でそれなりに
重要なファクターでしょう。
たとえばもしWindows版からのベタ移植が容易じゃなかったら、□は360用のFF11を出さない
だろうと思う。
そうやって同発ソフトが決まり、ローンチが成功したり失敗したりして普及台数が
定まっていくわけで、開発の容易さというのは(決定打ではなくとも)
まるきり無駄というわけではないのでは。
特にまだ両者ともシェア0%の状態では、開発の容易さは機種選定の上でそれなりに
重要なファクターでしょう。
たとえばもしWindows版からのベタ移植が容易じゃなかったら、□は360用のFF11を出さない
だろうと思う。
そうやって同発ソフトが決まり、ローンチが成功したり失敗したりして普及台数が
定まっていくわけで、開発の容易さというのは(決定打ではなくとも)
まるきり無駄というわけではないのでは。
>>672
じゃぁ、CellのPPEはP3の2倍程度の実効性能ってこと？
じゃぁ、CellのPPEはP3の2倍程度の実効性能ってこと？
開発コストの占める割合の中で、プログラミングの容易さはさほど影響が無いよ。
しかも、Windowsのベタ移植って言っても、Windowsでゲームを作ってて、
ゲーム機にそのまま移植できるような弾を持ってるメーカーは少数派でしょ。
しかも、Windowsのベタ移植って言っても、Windowsでゲームを作ってて、
ゲーム機にそのまま移植できるような弾を持ってるメーカーは少数派でしょ。
向こうはPCとコンシューマ機にマルチで出してる所多いのかな?
日本は殆どないよねコンシューマが先でPC移植とかカプコンがやってるな
日本は殆どないよねコンシューマが先でPC移植とかカプコンがやってるな
プログラミングの容易は影響ありまくり
まず変な延期が少なくなる、最適化も容易
GT4の製作現場TVに出てたけど苦しそうだったな
バグ→延期のオンパレード
まず変な延期が少なくなる、最適化も容易
GT4の製作現場TVに出てたけど苦しそうだったな
バグ→延期のオンパレード
日本のPCゲーの中心はエロゲですから
CS機とマルチができない
CS機とマルチができない
世界にはPCとコンソール同発してるゲームは山ほどある。
日本メーカーでもコナミはMGSやSHなどをPC向けにも移植してる。
まあ日本では売られてないが。
日本メーカーでもコナミはMGSやSHなどをPC向けにも移植してる。
まあ日本では売られてないが。
GT4クラスだと、開発が難しいのもさることながらPS2では性能たりなくて、ギリギリまで性能搾り出すハメになってるから難航したんだろね。
市場は開発者が決めてるとでも思ってるのか
勘違いもいいところだな
スレ違いだから信者隔離VSスレへどうぞ
勘違いもいいところだな
スレ違いだから信者隔離VSスレへどうぞ
>>678
>>652
>>682
PCで出す場合、OpenGLという手段もあるわけで。
特にMacでもゲームを出すような場合にはOpenGLしかない。
MSもHaloのMac版をOpenGLで書いてたしね。
>>652
>>682
PCで出す場合、OpenGLという手段もあるわけで。
特にMacでもゲームを出すような場合にはOpenGLしかない。
MSもHaloのMac版をOpenGLで書いてたしね。
市場は開発者の決断にかかってるのもたしか
大手に関しては（開発費数億かけるところ）開発が容易か容易でないかは、あまり関係ないだろうな
だけど小さいメーカーだと、かなり気になるところだと思う。
だけど小さいメーカーだと、かなり気になるところだと思う。
現状PS2が一人勝ちだけど、開発環境がいいとでも？
開発環境で市場をみるなら、箱が勝ってるはずですね
あれ？ｗ
開発環境で市場をみるなら、箱が勝ってるはずですね
あれ？ｗ
そういやあ箱とレボの開発環境どっちがいいとかって話聞かないねえ
>>686
PCでOpenGLは絶滅危惧種なんだよ。
Haloはホントに特別な例で、これは元々Mac向けに開発されていたのを
MSに買収されてXBOXタイトルに加えられてしまった。
OpenGLを積極的に使うのってCarmackくらいなもので、
ここ最近OpenGLだったタイトルなんてD3くらいしか知らない。
LinuxやMac向けに後に移植する際OpenGL使うのはどこでも普通だね。
PCでOpenGLは絶滅危惧種なんだよ。
Haloはホントに特別な例で、これは元々Mac向けに開発されていたのを
MSに買収されてXBOXタイトルに加えられてしまった。
OpenGLを積極的に使うのってCarmackくらいなもので、
ここ最近OpenGLだったタイトルなんてD3くらいしか知らない。
LinuxやMac向けに後に移植する際OpenGL使うのはどこでも普通だね。
確かGCってOpenGL使ってたよなあ。
レボも引き続きOpenGL使えるって事だな。
レボも引き続きOpenGL使えるって事だな。
このスレの>>191以降でも既出の話題を蒸し返しですか
191 名前：名無しさん必死だな[sage] 投稿日：2005/07/07(木) 23:36:15 ID:fsrn1LfO
>>188
＞FFTベンチやMPEG2同時48本再生がうれしい理由って何？
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
191 名前：名無しさん必死だな[sage] 投稿日：2005/07/07(木) 23:36:15 ID:fsrn1LfO
>>188
＞FFTベンチやMPEG2同時48本再生がうれしい理由って何？
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
>>632
フーリエ変換は画像・音声信号の周波数解析をするための「積和演算」の一種、一内容
最近のゲームにおける 3Dの座標変換・ベクトル演算は この「積和演算」を繰り返し行うことで実行される
頂点演算やピクセル処理を行う GPUのシェーダユニットのメインは このための「積和演算器」
シェーダ性能を高める とは、シェーダユニットを並列化し 「積和演算機能」を高めること
実際、G70ではGF6800に比べて ピクセルシェーダ内の積和演算器の数が 16個 → 48個 と 3倍に増やされてる
何故こんなことをしたかと言うと、nVIDIAが代表的な1300のゲームのシェーダ処理を研究した結果
積和演算機能を強化すれば ゲームの性能が最も上がりやすいと判断したから
つまり、FFT（高速フーリエ変換）が速い → 積和演算が速い → ゲームにおける3D処理が速い
と、まさにゲーム性能に直結している
SPEは、GPUでいう「シェーダユニット」のようなものだと考えてくれ
そして、例のFFTの結果は
”Cellは （ゲーム性能に直結する）積和演算の（カタログ値だけでなく）「実効性能」が高い”、という意味なのだ
フーリエ変換は画像・音声信号の周波数解析をするための「積和演算」の一種、一内容
最近のゲームにおける 3Dの座標変換・ベクトル演算は この「積和演算」を繰り返し行うことで実行される
頂点演算やピクセル処理を行う GPUのシェーダユニットのメインは このための「積和演算器」
シェーダ性能を高める とは、シェーダユニットを並列化し 「積和演算機能」を高めること
実際、G70ではGF6800に比べて ピクセルシェーダ内の積和演算器の数が 16個 → 48個 と 3倍に増やされてる
何故こんなことをしたかと言うと、nVIDIAが代表的な1300のゲームのシェーダ処理を研究した結果
積和演算機能を強化すれば ゲームの性能が最も上がりやすいと判断したから
つまり、FFT（高速フーリエ変換）が速い → 積和演算が速い → ゲームにおける3D処理が速い
と、まさにゲーム性能に直結している
SPEは、GPUでいう「シェーダユニット」のようなものだと考えてくれ
そして、例のFFTの結果は
”Cellは （ゲーム性能に直結する）積和演算の（カタログ値だけでなく）「実効性能」が高い”、という意味なのだ
よくわからんけどなんか高評価っぽいから
ゲームにゃ関係ねーつって叩いとけ、が正解じゃね
ゲームにゃ関係ねーつって叩いとけ、が正解じゃね
ソニーを叩く事だけが生き甲斐の人が多いんですよ
Cellに文句つけてる箱○信者はどうしようもねえな。
箱○CPUはベンチ結果公表してるのかと。
同じベンチやったら、Cellにぶっちぎりで負けるから公表できませんよね。
せめて、信者曰く得意な分野でのベンチ結果ってのを見たいね。
箱○CPUはベンチ結果公表してるのかと。
同じベンチやったら、Cellにぶっちぎりで負けるから公表できませんよね。
せめて、信者曰く得意な分野でのベンチ結果ってのを見たいね。
>>657に書かれてるみたいな
「いくら演算速くても、SPEでまともな処理できるか」的意見も
それなりに理解できるけどね。たとえばC++オブジェクトの1メンバに
SPEのコードからアクセスしたい、というと、かなり面倒なのではないか。
360のような対称型マルチスレッドなら何の造作もないことなのに。
「いくら演算速くても、SPEでまともな処理できるか」的意見も
それなりに理解できるけどね。たとえばC++オブジェクトの1メンバに
SPEのコードからアクセスしたい、というと、かなり面倒なのではないか。
360のような対称型マルチスレッドなら何の造作もないことなのに。
箱○はPPEそのまんじゃないか
XBOXとPS2の時も比較ベンチはあったが
XBOXとPS2の時も比較ベンチはあったが
PPEをあまり貶すと、xenonが自爆するよｗ
ttp://game10.2ch.net/test/read.cgi/ghard/1117970733/422
オマケで、テクノロジースレらしくXBOX360に搭載されるCPUコアの数字を推測してみる
搭載されるCPUコアに近いと思われるPowerPC G5 (970), 2GHz Dual機から推測
まず、最大値で考えると要素数512の時に10MFlops出ているので、リニアに性能が
伸びる(実際にはありえない)と仮定した場合、Dualから3コアへ単純に性能が1.5倍、
クロックが3.2Gなのでさらに1.6倍で10x1.5x1.6=24GFlops この程度が最大値だろう
で、上のCellの結果は要素数が2^24の時のものなので、なるべく要素数が大きい物を
探してみると、2^18の時に1.75GFlopsと読み取れるので、1.75ｘ1.5x1.6=4.2GFlops
同条件だと多分これ以下になると思われる
これはXBOX360側にありえないほど有利な状況を仮定した上での結果だけど、それでも
10倍程度の差が付く事になる
オマケで、テクノロジースレらしくXBOX360に搭載されるCPUコアの数字を推測してみる
搭載されるCPUコアに近いと思われるPowerPC G5 (970), 2GHz Dual機から推測
まず、最大値で考えると要素数512の時に10MFlops出ているので、リニアに性能が
伸びる(実際にはありえない)と仮定した場合、Dualから3コアへ単純に性能が1.5倍、
クロックが3.2Gなのでさらに1.6倍で10x1.5x1.6=24GFlops この程度が最大値だろう
で、上のCellの結果は要素数が2^24の時のものなので、なるべく要素数が大きい物を
探してみると、2^18の時に1.75GFlopsと読み取れるので、1.75ｘ1.5x1.6=4.2GFlops
同条件だと多分これ以下になると思われる
これはXBOX360側にありえないほど有利な状況を仮定した上での結果だけど、それでも
10倍程度の差が付く事になる
>>698
G70はシェーダー演算器の塊みたいなものだと思うが、
G70だけで追いつかず、Cellにまで回ってくることがあるのか疑問。
ゲームにおけるCellの役割は3D処理では無く、
むしろ非グラフィック分野、AIや物理計算などが主だろう。
G70はシェーダー演算器の塊みたいなものだと思うが、
G70だけで追いつかず、Cellにまで回ってくることがあるのか疑問。
ゲームにおけるCellの役割は3D処理では無く、
むしろ非グラフィック分野、AIや物理計算などが主だろう。
続き
115.2 GFlopsと発表されている性能からすると、最大でピーク性能の20.8%、Cellと同条件
に近いときは3.6%しかで無い事となる
まぁ、実際のゲームでこのままの差が付くかどうかは別の話だが、Cellがあの条件で叩き出した
20%、41GFlopsという数字がどれだけ凄いかという事を示すには十分だろう
こんな試算も過去にされてたな
115.2 GFlopsと発表されている性能からすると、最大でピーク性能の20.8%、Cellと同条件
に近いときは3.6%しかで無い事となる
まぁ、実際のゲームでこのままの差が付くかどうかは別の話だが、Cellがあの条件で叩き出した
20%、41GFlopsという数字がどれだけ凄いかという事を示すには十分だろう
こんな試算も過去にされてたな
>http://forum.teamxbox.com/showthread.php?t=357095
>ここの話は無視か・・・
XBOX360とCellのPowerPCコアはシンプル過ぎでショボッ！！話にならん。
って話か…
後藤タンとは見方が180度違うんだな。
>http://pc.watch.impress.co.jp/docs/2005/0218/kaigai158.htm
>ここの話は無視か・・・
XBOX360とCellのPowerPCコアはシンプル過ぎでショボッ！！話にならん。
って話か…
後藤タンとは見方が180度違うんだな。
>http://pc.watch.impress.co.jp/docs/2005/0218/kaigai158.htm
PPEはGCみればいいと思うが
>http://forum.teamxbox.com/showthread.php?t=357095
ついでに言うとこの記事の人、スーパースカラーの実行
パイプラインが2倍になればシングルスレッド性能が、
そのまま2倍近くになると考える類の人なのだろうか？
既存コードを走らせないケースではOut-Of-Orderの有り難味は、
それほど大きくないってことにも思い至らないのだろうか？
ついでに言うとこの記事の人、スーパースカラーの実行
パイプラインが2倍になればシングルスレッド性能が、
そのまま2倍近くになると考える類の人なのだろうか？
既存コードを走らせないケースではOut-Of-Orderの有り難味は、
それほど大きくないってことにも思い至らないのだろうか？
ちなみにEpic Gamesの副社長はPhysX（NovodeX）とCellは相性がいいので移植が容易だとは言ってたが
3Dゲームファンのための最新物理エンジン講座
～3Dゲームのための物理エンジンアクセラレータ「PhysX」はブレイクするか?
http://www.watch.impress.co.jp/game/docs/20050318/ageia.htm
＞ そこで、AGEIAが開発したのは、世界初の物理エンジンアクセラレータチップ「PhysX」だ。
＞基本的にはSIMDベースの浮動小数点実数ベクトル演算器の塊(アレイ)のようだが、ここま
＞で述べてきたような連鎖反応的に発生する物理計算に特化したアーキテクチャになっているという。
「SIMDベースの浮動小数点実数ベクトル演算器の塊」ってまさにCellのことだしな
3Dゲームファンのための最新物理エンジン講座
～3Dゲームのための物理エンジンアクセラレータ「PhysX」はブレイクするか?
http://www.watch.impress.co.jp/game/docs/20050318/ageia.htm
＞ そこで、AGEIAが開発したのは、世界初の物理エンジンアクセラレータチップ「PhysX」だ。
＞基本的にはSIMDベースの浮動小数点実数ベクトル演算器の塊(アレイ)のようだが、ここま
＞で述べてきたような連鎖反応的に発生する物理計算に特化したアーキテクチャになっているという。
「SIMDベースの浮動小数点実数ベクトル演算器の塊」ってまさにCellのことだしな
>>710
GCのGeckoはPowerPC 750カスタム。970互換のPPEとはかなり違う。
GCのGeckoはPowerPC 750カスタム。970互換のPPEとはかなり違う。
HD DVDの山田さんみたいな物かな
>>707
今後のGPUの方向性として
・動画再生支援の強化
・物理演算機能の強化
が挙げられる。
実はこれを先取りしたのがまさに Cell
物理演算で重要な演算は
・力学計算
・衝突判定
この内、衝突判定は話題の”PhysXチップ”などのような
物理演算専用チップにはかなわないかもしれないが、
力学演算には Cellの膨大なパワーがいかん無く発揮されるだろう。
少なくとも、xenonチップには 物理演算をブーストするような
機能は何も付いていないのではないか。
今後のGPUの方向性として
・動画再生支援の強化
・物理演算機能の強化
が挙げられる。
実はこれを先取りしたのがまさに Cell
物理演算で重要な演算は
・力学計算
・衝突判定
この内、衝突判定は話題の”PhysXチップ”などのような
物理演算専用チップにはかなわないかもしれないが、
力学演算には Cellの膨大なパワーがいかん無く発揮されるだろう。
少なくとも、xenonチップには 物理演算をブーストするような
機能は何も付いていないのではないか。
コンパイラがPPE向け最適化で命令を並べかえれば、
in-order命令実行のインパクトは小さい? そんなものかね。
in-order命令実行のインパクトは小さい? そんなものかね。
そう言えばPPC970だとRISC命令のはずのPPC命令セットですら、
もはや複雑過ぎるようで、わざわざシンプルな内部命令に砕いて実行すると言う
今のx86系CPUみたいなことやってて、もう純粋なRISCとは言い難い現状。
PPC命令セットとの互換ですら、今となっては性能的なな足枷と言うことか。
だからSPEは、200以下に絞り込んだのかもな。
もはや複雑過ぎるようで、わざわざシンプルな内部命令に砕いて実行すると言う
今のx86系CPUみたいなことやってて、もう純粋なRISCとは言い難い現状。
PPC命令セットとの互換ですら、今となっては性能的なな足枷と言うことか。
だからSPEは、200以下に絞り込んだのかもな。
100個以下、じゃなかった？ ＞命令セット
老練のIBMアーキテクタが それで足りるとか言って。
構造もシンプルに、命令セットもシンプルに。
いいのではないか。
老練のIBMアーキテクタが それで足りるとか言って。
構造もシンプルに、命令セットもシンプルに。
いいのではないか。
↓この日経エレの記事な
次のミーティングはオースティン。SCE鈴置が会議室に入ると、
IBMの席に初老のエンジニアが。30、40代が多い中、一際目立つ。
時折考え込みながら、一心不乱にペンを走らせている。
「あれは誰だろう？」
IBMが案を提示する順番に。すると、その初老が立ち上がる。
「ともかくコンパイラが扱いやすい命令セットにすべき。200では
多すぎる。私の試算では100個以下で事足りる」
先ほどまでペンを走らせていた紙を掲げながら説明をする。
そこには機械語で記述した手書きのサンプルプログラムが。
その鬼気迫る姿に誰もが圧倒した。
更に続く・・・
次のミーティングはオースティン。SCE鈴置が会議室に入ると、
IBMの席に初老のエンジニアが。30、40代が多い中、一際目立つ。
時折考え込みながら、一心不乱にペンを走らせている。
「あれは誰だろう？」
IBMが案を提示する順番に。すると、その初老が立ち上がる。
「ともかくコンパイラが扱いやすい命令セットにすべき。200では
多すぎる。私の試算では100個以下で事足りる」
先ほどまでペンを走らせていた紙を掲げながら説明をする。
そこには機械語で記述した手書きのサンプルプログラムが。
その鬼気迫る姿に誰もが圧倒した。
更に続く・・・
いや、TLPを高めるからといってILPを捨てるのはあんまり良いことではないけれど。
トランジスタ数やチップ開発コストとのトレードオフでやむをえず、というか。
実際、Cellも第2世代でPPEを2命令同時発行に改善した。
1命令ではあんまりだと思ったんだろう。
トランジスタ数やチップ開発コストとのトレードオフでやむをえず、というか。
実際、Cellも第2世代でPPEを2命令同時発行に改善した。
1命令ではあんまりだと思ったんだろう。
続き
それもそのはず、APU命令セットの定義はそのエンジニアが
ソフト技術者としてのキャリアの締めくくりとして選んだ仕事
だったのだ。彼の名はMarty Hopkins。世界初のRISC型
CPU「IBM801」の開発者の一人であり、その道では知る人ぞ
知る人物。老練技術者の言説に技術者達の目から鱗が。
コンパイラを知り尽くすMartyのアドバイスを若手技術者
がシミュレーションで検証する。
その後も、コンパイラの最適化作業を助けるためにアドレッシング
モードを追加するなど貴重な助言を残した。そして、APUの
命令セットがほぼ固まったのを見届けて、30年勤務したIBMを
後にした。
RISCの産みの親の一人であるIBMのエンジニアが
最後の仕事であるCellの設計で自分の美学を込めて現場を去ったということか
それもそのはず、APU命令セットの定義はそのエンジニアが
ソフト技術者としてのキャリアの締めくくりとして選んだ仕事
だったのだ。彼の名はMarty Hopkins。世界初のRISC型
CPU「IBM801」の開発者の一人であり、その道では知る人ぞ
知る人物。老練技術者の言説に技術者達の目から鱗が。
コンパイラを知り尽くすMartyのアドバイスを若手技術者
がシミュレーションで検証する。
その後も、コンパイラの最適化作業を助けるためにアドレッシング
モードを追加するなど貴重な助言を残した。そして、APUの
命令セットがほぼ固まったのを見届けて、30年勤務したIBMを
後にした。
RISCの産みの親の一人であるIBMのエンジニアが
最後の仕事であるCellの設計で自分の美学を込めて現場を去ったということか
トランジスタ、多いよな。＞Cell
まぁSRAMに2.5MBも取られてるのだが・・
面積もRSXより大きくなるだろうね。
まぁSRAMに2.5MBも取られてるのだが・・
面積もRSXより大きくなるだろうね。
>>657の記事の人に更に突っ込むと
XBOX360のCPUはプレスコの半分くらいの大きさしかなくてショボッ！！
みたいなこと言ってるけど、プレスコがレガシーのために
いかに無駄なトランジスタを割いてるか考え欲しい
ttp://rerere.sytes.net/up/source/up8267.jpg
スケジューラー、命令デコーダ、分岐予測回路と言った
非実行ユニットが実行ユニットの2倍くらい面積を食ってる
この笑えるほどの末期的状況…
XBOX360のCPUはプレスコの半分くらいの大きさしかなくてショボッ！！
みたいなこと言ってるけど、プレスコがレガシーのために
いかに無駄なトランジスタを割いてるか考え欲しい
ttp://rerere.sytes.net/up/source/up8267.jpg
スケジューラー、命令デコーダ、分岐予測回路と言った
非実行ユニットが実行ユニットの2倍くらい面積を食ってる
この笑えるほどの末期的状況…
>>727
あれ？Cellが2億5000万くらいで、RSXは3億越えだったような？
あれ？Cellが2億5000万くらいで、RSXは3億越えだったような？
プレスコはキャッシュ2Mにしてもあのザマ
トランジスタの多さって意味あるのか？
トランジスタの多さって意味あるのか？
どちらもトランジスタ数多いけど、それでもGSよりはダイサイズが小さくなっている。
とりあえずG70は問題なく出荷してるね。
いつぞやのnVidiaとは大違い。彼らは失敗から学習する組織なんだろうか。
とりあえずG70は問題なく出荷してるね。
いつぞやのnVidiaとは大違い。彼らは失敗から学習する組織なんだろうか。
>>729
うん。
Cell（DD2）が 2億5000万トランジスタ・ 235mm~2、
RSXが3億トランジスタ弱・ 推定 200～240mm~2程度じゃないかな。
正確にはわからんけど・・
どっちも90nmプロセス。
トランジスタ数と面積は必ずしも一致しない。
うん。
Cell（DD2）が 2億5000万トランジスタ・ 235mm~2、
RSXが3億トランジスタ弱・ 推定 200～240mm~2程度じゃないかな。
正確にはわからんけど・・
どっちも90nmプロセス。
トランジスタ数と面積は必ずしも一致しない。
>>728
ttp://pcweb.mycom.co.jp/special/2004/prescott/003.html
Prescottって90nmプロセスで1億2500万(L2 1M)だけど、Xbox360のCPUってそんな小さいの？
ttp://pcweb.mycom.co.jp/special/2004/prescott/003.html
Prescottって90nmプロセスで1億2500万(L2 1M)だけど、Xbox360のCPUってそんな小さいの？
>>720
Xbox360の開発キットにはリアクターという物理演算エンジンがついているよ、UE3にもね。
物理演算はソフトでの効率のほうが性能に直結するからミドルウェアの性能次第。
特にゲームの場合、ポリゴンのカリングと同じでばか正直に力学計算なんかやってたら使い物にならないよ。
Xbox360の開発キットにはリアクターという物理演算エンジンがついているよ、UE3にもね。
物理演算はソフトでの効率のほうが性能に直結するからミドルウェアの性能次第。
特にゲームの場合、ポリゴンのカリングと同じでばか正直に力学計算なんかやってたら使い物にならないよ。
そんな速攻で論破されることをわざわざ書きに来なくても、と思った。
>>735
いやさ・・
「Cellは動画のエンコしか使えない」 と誰かが言うから
「3Dゲームの演算にも強いよ」 っつったら、
「GPU的な機能は足りてるよ。 Cellは物理演算は出来ないのか？」 っつうから、
「いや、それも得意だよ。 Cellの得意分野だ」 って答えただけでさ・・
チップ本体に物理演算をブーストするような機能が付いてないのに、
ミドルウェアで付いてるから心配無い、むしろCellで馬鹿正直にリアルタイム演算するのは無駄、
なんて言われても・・・
「ああそうですか、頑張ってください」、としか言いようがない。
いやさ・・
「Cellは動画のエンコしか使えない」 と誰かが言うから
「3Dゲームの演算にも強いよ」 っつったら、
「GPU的な機能は足りてるよ。 Cellは物理演算は出来ないのか？」 っつうから、
「いや、それも得意だよ。 Cellの得意分野だ」 って答えただけでさ・・
チップ本体に物理演算をブーストするような機能が付いてないのに、
ミドルウェアで付いてるから心配無い、むしろCellで馬鹿正直にリアルタイム演算するのは無駄、
なんて言われても・・・
「ああそうですか、頑張ってください」、としか言いようがない。
>>737
物理エンジンを「チップ」だと思ってるに一票。
物理エンジンを「チップ」だと思ってるに一票。
>>738
成程・・
例えば 「NovodeXエンジン」と「PhysXチップ」を混同してるのか・・
同じ処理でも 専用チップを積めば60fpsでるのが、
P4とかその手のCPUだけで行うと 1～2fpsしか出ないってこともあるぞ。
物理演算アクセラレーション機能は実装してたほうがいい。
せっかくのミドルウェアが無意味になってしまう。
成程・・
例えば 「NovodeXエンジン」と「PhysXチップ」を混同してるのか・・
同じ処理でも 専用チップを積めば60fpsでるのが、
P4とかその手のCPUだけで行うと 1～2fpsしか出ないってこともあるぞ。
物理演算アクセラレーション機能は実装してたほうがいい。
せっかくのミドルウェアが無意味になってしまう。
Cellのソフト環境の充実度はどんなもんかねぇ。
ちなみにDirectXのHLSLコンパイラは
とてもよく出来てると思うんだが
いまだにauto変数にconstすら付けられない。
もう2年以上歴史があるはずなのだが。
IBMだから大丈夫はちょっと楽観的すぎると思うのだが・・。
ちなみにDirectXのHLSLコンパイラは
とてもよく出来てると思うんだが
いまだにauto変数にconstすら付けられない。
もう2年以上歴史があるはずなのだが。
IBMだから大丈夫はちょっと楽観的すぎると思うのだが・・。
物理演算が強化されるとバーチャの人形くささも直る？
次世代にはそこら辺期待したいけど、正直に力学計算しなくても無問題なの？
次世代にはそこら辺期待したいけど、正直に力学計算しなくても無問題なの？
それ系のソフトを実行してみればわかると思うけど、
単純なポリゴンモデルでも 気持ち悪いくらいクネクネ動くぞ。
物理的に演算しながら・・
綺麗なテクスチャ張ったキャラで動かしたら
印象は全く違うゲームのように見えるだろう。
Cellは そのあたりが楽しみ。
単純なポリゴンモデルでも 気持ち悪いくらいクネクネ動くぞ。
物理的に演算しながら・・
綺麗なテクスチャ張ったキャラで動かしたら
印象は全く違うゲームのように見えるだろう。
Cellは そのあたりが楽しみ。
本当に現実と同じ物理演算だけでバーチャ作ったら
動きが遅くてHPゲージの意味の無いものになりそうだ。
動きが遅くてHPゲージの意味の無いものになりそうだ。
もちろん スパコンじゃないんだから、
演算能力の許す範囲の物理演算だね
ま、ゲーム程度なら そこそこ見れるものができるかも
演算能力の許す範囲の物理演算だね
ま、ゲーム程度なら そこそこ見れるものができるかも
現実じゃないからゲームは楽しいという部分もあるしね。
別にリアルな殴り合いを求めてるわけじゃないし
別にリアルな殴り合いを求めてるわけじゃないし
格闘ゲームに物理演算のような確率への依存性が高い要素を導入するのは微妙なような・・・。
そういう要素をもった格ゲーもありと言えばありなんだが、バーチャのように歴史が
あるソフトは下手に革新的な要素を盛り込めないから難しいところ。
そういう要素をもった格ゲーもありと言えばありなんだが、バーチャのように歴史が
あるソフトは下手に革新的な要素を盛り込めないから難しいところ。
格闘ゲームのスレ見たらわかるけど「この技入ったら硬直何フレでXX技確定」なんて世界に
物理演算は求められていない気がするな。
物理演算は求められていない気がするな。
次世代機の格ゲーヲタの間ではフレーム数じゃなくて
物理演算の働きを頭の中で読みながら戦うようになる
とかいう事になるのかもしれない
俺にもそれがどういうことだかよくわからんが格ゲーヲタの能力は凄いからな
物理演算の働きを頭の中で読みながら戦うようになる
とかいう事になるのかもしれない
俺にもそれがどういうことだかよくわからんが格ゲーヲタの能力は凄いからな
遊びじゃない
箱1に物理演算を取り入れた格闘超人ってのがあったと思うがあれはどう評価されてたのかな？
即回収＆存在抹消された事以外知らないんだが、ゲームシステム的にどうだったのかと。
即回収＆存在抹消された事以外知らないんだが、ゲームシステム的にどうだったのかと。
単に物理演算を入れるのではなくて、物理演算を使った+αがなければ
ゲームとしての面白さはないと思う
ゲームとしての面白さはないと思う
格ゲーに物理演算つかうなら背景と乳揺れぐらいだろ。
３D格ゲーに細かく物理演算使ったら
コンボなんか出来ないと思うが
コンボなんか出来ないと思うが
>>754
だな。
軽くはじいただけで人が高々と浮いてしまう時点で物理法則に反してる。
でもリアルにすると空中コンボそのものが成立しなくなって面白くなくなってしまう。
格闘ゲームを面白くするためにはむしろシステム面の改良の方が効果が大きいと思うね。
ガードすると固まってしまう制限とか、投げ失敗モーションが明らかに不自然とか、
起き上がりの攻防が単調とか。そこらへんの改良の方が面白さを増すと予想。
だな。
軽くはじいただけで人が高々と浮いてしまう時点で物理法則に反してる。
でもリアルにすると空中コンボそのものが成立しなくなって面白くなくなってしまう。
格闘ゲームを面白くするためにはむしろシステム面の改良の方が効果が大きいと思うね。
ガードすると固まってしまう制限とか、投げ失敗モーションが明らかに不自然とか、
起き上がりの攻防が単調とか。そこらへんの改良の方が面白さを増すと予想。
物理演算するからニュートン力学に沿った動きしかできなくなるってわけでもないだろ。
格ゲーなんてもはやキャラゲーなんだけどな。と
今日スターウォーズEP3のゲーム買ってしまった俺が言ってみるｗ
今日スターウォーズEP3のゲーム買ってしまった俺が言ってみるｗ
1対1の限定状況だとあんま効果はない。三国無双みたいなやつのほうが効果的だろう。
RTSとかね。
出来る出来ないと使う使わないは別問題だし。ゲームデザインに関してはまた別の
スレがふさわしいと思うが？
RTSとかね。
出来る出来ないと使う使わないは別問題だし。ゲームデザインに関してはまた別の
スレがふさわしいと思うが？
格ゲーに物理エンジンの例ならすでにEAがFight Nightで示してる。
スローモーションでKOシーンが妙にリアルなバーチャとかどうよ。
スローモーションでKOシーンが妙にリアルなバーチャとかどうよ。
例えばミドルキックをガードした場合、本当に物理演算を重視するなら
足の長さの分だけキャラが後ろに後退しないといけないんだよね。
でも現状は、至近距離でミドルキックをガードしても少ししか後退しない。
足がキャラののめり込んじゃってるのが現状。
これをリアルにするだけでもゲーム性はかなり変わるはず。
足の長さの分だけキャラが後ろに後退しないといけないんだよね。
でも現状は、至近距離でミドルキックをガードしても少ししか後退しない。
足がキャラののめり込んじゃってるのが現状。
これをリアルにするだけでもゲーム性はかなり変わるはず。
>>756
ゲームに求められている物理演算は厳密に力学計算しなくてもいいような気がするな。
そうすると、物理演算をブーストする機能は特別必要じゃなくてフェイクの
ほうが処理も速くてゲーム向きだという事になる。
ゲームに求められている物理演算は厳密に力学計算しなくてもいいような気がするな。
そうすると、物理演算をブーストする機能は特別必要じゃなくてフェイクの
ほうが処理も速くてゲーム向きだという事になる。
「物理演算」で検索するとおもしろいのがあるな。
winnyの作者も格ゲーと物理演算との関係に注目していたようだ。
winnyの作者も格ゲーと物理演算との関係に注目していたようだ。
＞足がキャラののめり込んじゃってるのが現状。
↓
足がキャラにのめり込んじゃってるのが現状。
>>761
物理演算が何のために必要か、というとつまりはリアルさの向上だろ。
でも格闘ゲームの場合、現状キャラの動きやシステム面の方がリアルさを阻害してるわけさ。
まず改良すべきはこちらでしょう。物理演算よりモーションの改良の方がリアルさを増す。
↓
足がキャラにのめり込んじゃってるのが現状。
>>761
物理演算が何のために必要か、というとつまりはリアルさの向上だろ。
でも格闘ゲームの場合、現状キャラの動きやシステム面の方がリアルさを阻害してるわけさ。
まず改良すべきはこちらでしょう。物理演算よりモーションの改良の方がリアルさを増す。
蹴る瞬間に足の質量が500Kgに増加して、その衝突を物理演算で厳密に計算したら
ゲーム的面白さが出ないかな。
ゲーム的面白さが出ないかな。
むしろゲームに物理エンジンの面白さは現実ではありえない
法則を構築できるという部分にもあるから、
どこかにフェイクなり漫画的強調を入れるのは必須かもしれない。
法則を構築できるという部分にもあるから、
どこかにフェイクなり漫画的強調を入れるのは必須かもしれない。
まあリアルだから面白さが増すとは限らないからね。
ゲームとしてのフェイクはどこかに必要。
個人的には、格闘ゲームの場合のフェイクは「キャラのパワー」だけでよいと思う。
不自然なモーションは極力配慮すべき。
ゲームとしてのフェイクはどこかに必要。
個人的には、格闘ゲームの場合のフェイクは「キャラのパワー」だけでよいと思う。
不自然なモーションは極力配慮すべき。
×不自然なモーションは極力配慮すべき。→○不自然なモーションは極力排除すべき。
今日はキー入力ミスが多い・・・
今日はキー入力ミスが多い・・・
ビリヤードとか重力をシュミレートした落ちゲーとかなら物理演算がゲームを
面白くするかもしれないが、既存のゲームは物理学を無視したところに面白さが
あるのでフレームシティみたいに撃ったドラム缶がリアルにころがるとかいう
のは意味が無いとおもうな。
こういうのは任天堂の得意分野なんだがSCEは当たり前の使い方しかしないからなぁ。
面白くするかもしれないが、既存のゲームは物理学を無視したところに面白さが
あるのでフレームシティみたいに撃ったドラム缶がリアルにころがるとかいう
のは意味が無いとおもうな。
こういうのは任天堂の得意分野なんだがSCEは当たり前の使い方しかしないからなぁ。
格闘の人対人の処理は物理エンジンよりさらに特化した骨格シミュレータが出てくるかもな。
素のエンジンだと大雑把過ぎて使いづらいかも。
箱に物理エンジンがロイヤリティーフリーで標準搭載されるなら
環境へのリアルな干渉（ブロックが壊れたり金網がひしゃげたり）は当たり前になるんじゃないの。
素のエンジンだと大雑把過ぎて使いづらいかも。
箱に物理エンジンがロイヤリティーフリーで標準搭載されるなら
環境へのリアルな干渉（ブロックが壊れたり金網がひしゃげたり）は当たり前になるんじゃないの。
相手が浮いた時に殴る場所が変わったらどこ飛んでいくかわからんと思うよ
浮いた時に自分が攻撃した場所が足だったり手だったりするわけじゃん
ここまで細かくしたら面白くないか
浮いた時に自分が攻撃した場所が足だったり手だったりするわけじゃん
ここまで細かくしたら面白くないか
物理演算はいいんだが、問題は格闘ゲーマーも納得できる対戦バランスを構築できるかどうかだ。
開発者自身も予期せない動作が大量に発生してしまうわけだから、バランス調整はより大変になる。
開発者自身も予期せない動作が大量に発生してしまうわけだから、バランス調整はより大変になる。
>>768
＞こういうのは任天堂の得意分野なんだがSCEは当たり前の使い方しかしないからなぁ。
この部分だけよくわからん。任天堂なんてキャラで売ってるだけ。
ゲームデザインの拘りなどとは最も遠いところにいるゲーム屋だと思うが。
＞こういうのは任天堂の得意分野なんだがSCEは当たり前の使い方しかしないからなぁ。
この部分だけよくわからん。任天堂なんてキャラで売ってるだけ。
ゲームデザインの拘りなどとは最も遠いところにいるゲーム屋だと思うが。
Xenonで使用されるのは，三つのコアをまとめたPowerPC系のプロセッサで，1コアあたり2命令を同時発行できるという。これが3.5GHz以上で駆動されるので，基本性能は21G命令/sec以上ということになる。
基本的に三つのコアではあるが，コアごとに2スレッド流すことで，全体で6スレッド同時実行するというイメージだ。
さらに，ベクトルレジスタがスレッドごとに128個搭載されているという。VMXとあるので，これはおそらく128ビットレジスタでベクトル演算を行うAltiVec（VelocityEngine）がついているという意味だと思われる
（AltiVecは128ビットレジスタで32ビット浮動小数点演算を同時に4個実行するPowerPC系のマルチメディア命令実行ユニット）。その場合の演算性能は84GFLOPSとなる（PlayStation2のEmotionEngineで6.4GFLOPS程度）。
レジスタ数が不自然に多いようにも思われるが，これが仮に複数のレジスタに対して同時に演算ができる仕様であるなら，最大10.5TFLOPSの演算性能を発揮する可能性もある。
基本的に三つのコアではあるが，コアごとに2スレッド流すことで，全体で6スレッド同時実行するというイメージだ。
さらに，ベクトルレジスタがスレッドごとに128個搭載されているという。VMXとあるので，これはおそらく128ビットレジスタでベクトル演算を行うAltiVec（VelocityEngine）がついているという意味だと思われる
（AltiVecは128ビットレジスタで32ビット浮動小数点演算を同時に4個実行するPowerPC系のマルチメディア命令実行ユニット）。その場合の演算性能は84GFLOPSとなる（PlayStation2のEmotionEngineで6.4GFLOPS程度）。
レジスタ数が不自然に多いようにも思われるが，これが仮に複数のレジスタに対して同時に演算ができる仕様であるなら，最大10.5TFLOPSの演算性能を発揮する可能性もある。
物理演算で一番面白みが増すとしたらクロスシムじゃないかと思うが。
顔が変形するとかより女キャラのコスが体に沿ってぷるぷるのするするに
動くのだったら見てみたい。
顔が変形するとかより女キャラのコスが体に沿ってぷるぷるのするするに
動くのだったら見てみたい。
パンチラがNGなら、パンツ脱がせばいいのに
何でよりリッチになった演算能力とメモリの使い道が格ゲーリアル一辺倒なんだ？
ビルの爆破解体でも、逆に築城シミュレータでも
合戦物SLGでも敵をより賢くしたり
地形その他のパラメータの種類と精度が上がるだけでもディティールが細かく出来たり
もっとマシな使い道は幾らでも有るだろう。
ビルの爆破解体でも、逆に築城シミュレータでも
合戦物SLGでも敵をより賢くしたり
地形その他のパラメータの種類と精度が上がるだけでもディティールが細かく出来たり
もっとマシな使い道は幾らでも有るだろう。
>>770
そうとも限らないだろ。
空中コンボで、体を殴った時と手を殴ったときで吹っ飛び方が違ったとしても
面白さが阻害されるとは思わない。
VF4あたりでも空中コンボでヒットさせる技の種類によって吹っ飛び方が違うよ。
そのバリエーションが更に増えるわけだから、コンボの多様性という意味では
物理演算は面白さにプラスに働くと思われる。
そうとも限らないだろ。
空中コンボで、体を殴った時と手を殴ったときで吹っ飛び方が違ったとしても
面白さが阻害されるとは思わない。
VF4あたりでも空中コンボでヒットさせる技の種類によって吹っ飛び方が違うよ。
そのバリエーションが更に増えるわけだから、コンボの多様性という意味では
物理演算は面白さにプラスに働くと思われる。
最大10.5TFLOPSの演算性能
^^^^^^^^^^^^^
すげぇ
^^^^^^^^^^^^^
すげぇ
格闘ゲームの場合、ヒットするゲームデザインの条件っつーのは、
①操作、ルールがある程度シンプルであること（初心者の敷居が低い）
②技術介入の余地が多い（上級者もやりこみがいがる）
というのがあると思う。
物理演算は、①に対しては影響を与えないが、②に対しては影響を与える。
物理演算が多様なモーションが生み出し、多様なモーションが多様な状況を生み出すはず。
各状況に対応した最適な行動っつーのは上級者も研究のしがいがあるだろ。
①操作、ルールがある程度シンプルであること（初心者の敷居が低い）
②技術介入の余地が多い（上級者もやりこみがいがる）
というのがあると思う。
物理演算は、①に対しては影響を与えないが、②に対しては影響を与える。
物理演算が多様なモーションが生み出し、多様なモーションが多様な状況を生み出すはず。
各状況に対応した最適な行動っつーのは上級者も研究のしがいがあるだろ。
ヒットした場所で威力や吹っ飛びが違うって
ようはスマブラだろ
ようはスマブラだろ
スマブラはキャラゲー。
ゲーム内容は期待されてないよ。
ゲーム内容は期待されてないよ。
>>769
物理演算とモデルに対する加工は別次元の話のような気がしますが。
物理演算とモデルに対する加工は別次元の話のような気がしますが。
>>776 9fhNQiskがやりたいからでしょ、実際、格闘ゲームで
その手のアプローチは格闘超人とかでも多少取り入れようと
してたりしたけど、たいした進化もなく格闘ゲームがマンネリな
キャラゲーに成り下がってるし。海外はともかく日本で格闘ゲームは
ゲームがポリゴンに流れるきっかけつくったジャンルだし。
個人的にもそれで技術がビジュアルに反映され見栄えが変わるなら
FPSで物がリアルに壊れたり無双みたいなのでキャラが1000体でるより見てみたい。
でも今の日本の格ゲーつくってるところにそんな技術あるとは思えないけど。
その手のアプローチは格闘超人とかでも多少取り入れようと
してたりしたけど、たいした進化もなく格闘ゲームがマンネリな
キャラゲーに成り下がってるし。海外はともかく日本で格闘ゲームは
ゲームがポリゴンに流れるきっかけつくったジャンルだし。
個人的にもそれで技術がビジュアルに反映され見栄えが変わるなら
FPSで物がリアルに壊れたり無双みたいなのでキャラが1000体でるより見てみたい。
でも今の日本の格ゲーつくってるところにそんな技術あるとは思えないけど。
リゲインのCMのようにCGが妙にリアルなのも考え物だな
ttp://regain.jp/jiten/cm/index.html
ttp://regain.jp/jiten/cm/index.html
ファイティング武術…いや、なんでもない。
なんでだ？
必然だろ
必然だろ
>>783
＞技術がビジュアルに反映され見栄えが変わる
ファイトナイト３がそうでは？
格ゲーである以上、リアルタイムに反応できるほどはっきり差が出て
かつ、ゲームパッドで操作しなければいけないんだから
反応や操作を細かくする事はゲーム性の妨げにしかならないっしょ。
＞技術がビジュアルに反映され見栄えが変わる
ファイトナイト３がそうでは？
格ゲーである以上、リアルタイムに反応できるほどはっきり差が出て
かつ、ゲームパッドで操作しなければいけないんだから
反応や操作を細かくする事はゲーム性の妨げにしかならないっしょ。
ブルース・リーのCG映画ボツになった？
>>783
＞その手のアプローチは格闘超人とかでも多少取り入れようとしてたりしたけど
そもそも格ゲーの面白さの核心は対戦にあるわけだから
対戦人口ゼロの格ゲーなんかが売れるはずが無い。
あとキャラ性も音楽もへぼへぼだったんだろ。
＞その手のアプローチは格闘超人とかでも多少取り入れようとしてたりしたけど
そもそも格ゲーの面白さの核心は対戦にあるわけだから
対戦人口ゼロの格ゲーなんかが売れるはずが無い。
あとキャラ性も音楽もへぼへぼだったんだろ。
格ゲーに物理演算（エンジン？）ってのは、主にバランス調整の問題じゃないのかと。
少なくとも見た目によりリアルに（破綻無く）なるのは確実だとは思うけど、プレイヤーの入力
によって起こる状態の可能性も同時に増えすぎて、それを全て管理しきれるかってのが問題だと。
見た目に美しく吹っ飛ぶのは良いけど、その吹っ飛び方はゲームとして不利すぎ無いか、
有利すぎないかって部分の調整が殆ど不可能になる。
もっとアバウトにバランスが決定出来るゲーム、VS群衆みたいな無双風のゲームなら
物理演算の取り込みようもあるかもしれないけど、細かなあらゆる全ての挙動までが
ゲームバランスとして調整しなきゃならん格ゲーでは（今のままでは）難しいんじゃないかと思う。
少なくとも見た目によりリアルに（破綻無く）なるのは確実だとは思うけど、プレイヤーの入力
によって起こる状態の可能性も同時に増えすぎて、それを全て管理しきれるかってのが問題だと。
見た目に美しく吹っ飛ぶのは良いけど、その吹っ飛び方はゲームとして不利すぎ無いか、
有利すぎないかって部分の調整が殆ど不可能になる。
もっとアバウトにバランスが決定出来るゲーム、VS群衆みたいな無双風のゲームなら
物理演算の取り込みようもあるかもしれないけど、細かなあらゆる全ての挙動までが
ゲームバランスとして調整しなきゃならん格ゲーでは（今のままでは）難しいんじゃないかと思う。
格闘ゲームの場合、ゲームデザインも重要だけど、
それ以上に対戦を楽しめる環境や対戦を盛り上げるシステムの方が重要。
格闘超人はその辺がダメダメだった。
まあ、それ以前に「格闘超人」ってやる気無さそうなタイトルである時点で
終わってるけど・・・
それ以上に対戦を楽しめる環境や対戦を盛り上げるシステムの方が重要。
格闘超人はその辺がダメダメだった。
まあ、それ以前に「格闘超人」ってやる気無さそうなタイトルである時点で
終わってるけど・・・
格闘超人でやってることって、バウンサーでやってることと一緒じゃなかったっけ？
やられモーションが用意されてないって言う。
起き上がりまでの硬直時間とかコンボの浮き具合とか、かけひきに必要な所は関係なかったんでは？
やられモーションが用意されてないって言う。
起き上がりまでの硬直時間とかコンボの浮き具合とか、かけひきに必要な所は関係なかったんでは？
任天堂のゲームって見た目子供向けっぽいからな。
子供騙しってやつ？大人も楽しめる本格派って感じがしないし
実際遊んで感じた事も無いな。
子供騙しってやつ？大人も楽しめる本格派って感じがしないし
実際遊んで感じた事も無いな。
風のタクトで皿やコップの挙動が1G下での挙動っぽく見えるようになればそれでいい
風タクにリアルさなんて不必要。
あれも絵とキャラだけで売るキャラゲーだな。
あれも絵とキャラだけで売るキャラゲーだな。
なんだこのID:9fhNQisk(14)
任天堂みたいにキャラと知名度を頼りに面白くないゲームを売ろうとしても
ネット全盛のご時世では糞ゲーはすぐに叩かれる運命であるから
消費者を騙すにも限界があるって事さ。
ネット全盛のご時世では糞ゲーはすぐに叩かれる運命であるから
消費者を騙すにも限界があるって事さ。
>>800
スマブラは面白いが？
スマブラは面白いが？
ニンテンドウゲーム論は流石にかなり激しくスレ違いじゃ無いかと思うです。。。
そもそもゲーム論？自体スレ違い
しかしゲーム機で一番大切なのはゲームというかソフトウェア
であるのは疑う余地が無いわけで。
ソフトウェアという要件を実現するのにハードウェアが
作られるとしたら、ソフトウェア、つまりゲームが要求する
モノを押さえておくのは非常に重要であると思うね。
であるのは疑う余地が無いわけで。
ソフトウェアという要件を実現するのにハードウェアが
作られるとしたら、ソフトウェア、つまりゲームが要求する
モノを押さえておくのは非常に重要であると思うね。
特に任天堂。レボみたいに「低価格、低性能」
路線で行く事が本当に正しいのか？
高性能が実現するリアルさはゲームの面白さに
本当に繋がらないと言えるのか、
任天堂はきちんと検討したのだろうか・・・
路線で行く事が本当に正しいのか？
高性能が実現するリアルさはゲームの面白さに
本当に繋がらないと言えるのか、
任天堂はきちんと検討したのだろうか・・・
おい、誰だスイッチ入れたの
間違いなく、あなたより有能な業界の人が真剣には検討してると思いますよ
>>807
と言いつつ、任天堂は子供騙し的な非リアル調ゲームを作り続けているわけだが。
リアリスティックなゲーム作りを目指した事がない任天堂なら
「リアルさはゲームに不必要」という考えを持ってもおかしくない。
そんなんだから任天堂は子供向けのレッテルを貼られるんだ。
と言いつつ、任天堂は子供騙し的な非リアル調ゲームを作り続けているわけだが。
リアリスティックなゲーム作りを目指した事がない任天堂なら
「リアルさはゲームに不必要」という考えを持ってもおかしくない。
そんなんだから任天堂は子供向けのレッテルを貼られるんだ。
>9fhNQisk
任天堂がスレ違いなのは分かるが、
お前もスレ違い
任天堂がスレ違いなのは分かるが、
お前もスレ違い
もう、誰にも止められない。
一度流れが出来ちゃったんだから仕方ないべ。
新しい技術的なネタが投入されない限りこの流れは続く。
新しい技術的なネタが投入されない限りこの流れは続く。
9fhNQisk
自分の理論が全て正しいのですか
自分の理論が全て正しいのですか
ID:9fhNQisk
いい加減”ど”素人レベルの中学生でも出来るゲームデザイン考は止めろ。
プロなら既に議論され尽くしてるレベルのものを何を今更得意げに書き込んでるんだ？
いい加減”ど”素人レベルの中学生でも出来るゲームデザイン考は止めろ。
プロなら既に議論され尽くしてるレベルのものを何を今更得意げに書き込んでるんだ？
わかったよじゃあちょっと流れを修正して技術的な話をしよう。
http://www.watch.impress.co.jp/game/docs/20050318/ageia.htm
↑のような物理演算を実現するのに、CELLとXBOX360CPUどっちが
相性いいと思う？
CELLのLSはメインメモリとのコヒーレンシが保たれていないそうなので、
物理演算と相性がいいようで、実はあまりよくないと思う。
SPEが演算に使う元データを頻繁にメインメモリとやり取りしないといけないので、
メインメモリの帯域が逼迫するだろう。
http://www.watch.impress.co.jp/game/docs/20050318/ageia.htm
↑のような物理演算を実現するのに、CELLとXBOX360CPUどっちが
相性いいと思う？
CELLのLSはメインメモリとのコヒーレンシが保たれていないそうなので、
物理演算と相性がいいようで、実はあまりよくないと思う。
SPEが演算に使う元データを頻繁にメインメモリとやり取りしないといけないので、
メインメモリの帯域が逼迫するだろう。
CELLのSPEが物理演算で生かせないとなたら、
開発者がCELLを作った意図の大半は実現されなかったと
言うことなのではないの？
それじゃXBOX360のCPUと大差無い。
CELLへの投資は無駄だった、という事なのでは・・・
開発者がCELLを作った意図の大半は実現されなかったと
言うことなのではないの？
それじゃXBOX360のCPUと大差無い。
CELLへの投資は無駄だった、という事なのでは・・・
技術的な話には疎いのであまり長文書けないのだが、
頂点シェーダーの代用や物理演算という用途がCELL（というかSPE）で
どの程度生きるのか、いまいちよくわからん。
というか、現状では生かせないのではないか、と思えてくるのだが。
この辺のことを詳しい人に解説して欲しい。
頂点シェーダーの代用や物理演算という用途がCELL（というかSPE）で
どの程度生きるのか、いまいちよくわからん。
というか、現状では生かせないのではないか、と思えてくるのだが。
この辺のことを詳しい人に解説して欲しい。
そもそも「物理演算」と言われる一連のソレが、一体具体的にどんな処理なのかって
のが分かんない。
まぁ、それを簡単に説明出来れば、ダブスチが作れちゃうのだろうけど・・
のが分かんない。
まぁ、それを簡単に説明出来れば、ダブスチが作れちゃうのだろうけど・・
帯域とか相関とかエンディアンの話はスルーしたい年頃
ある元データがあって
それをもとに計算した結果を吐き出すということをするとき
元データがなぜかころころ書き換えられてそれに追従しなきゃいけないなら
コヒーレンシを保たずに出した結果は壊れたデータということになっちゃう
でも物理演算する時の「元データ」は不変であることが前提でしょ
だって元データだもん、計算の前提だもん
コヒーレンシが保たれないことが物理演算の障害になるとは思えない
それをもとに計算した結果を吐き出すということをするとき
元データがなぜかころころ書き換えられてそれに追従しなきゃいけないなら
コヒーレンシを保たずに出した結果は壊れたデータということになっちゃう
でも物理演算する時の「元データ」は不変であることが前提でしょ
だって元データだもん、計算の前提だもん
コヒーレンシが保たれないことが物理演算の障害になるとは思えない
>>815のリンクにある 車両物理vs.Ragdoll(応用系) は
ダブスチなんかでも使えそうな気がする。
基本的に、Ragdoll物理(基本系) はヒトの動きに関係する
部分なので、生かせそうなシーンは多そう。
HALO2でもチーフのやられモーションで使われていたしな。
ダブスチなんかでも使えそうな気がする。
基本的に、Ragdoll物理(基本系) はヒトの動きに関係する
部分なので、生かせそうなシーンは多そう。
HALO2でもチーフのやられモーションで使われていたしな。
箱○のCPUは
そもそもUMAでさらにメモリに直結されていないので
論外・・・・足回りが悪すぎ！！どうしろと・・・
そもそもUMAでさらにメモリに直結されていないので
論外・・・・足回りが悪すぎ！！どうしろと・・・
>>623-632
負け犬痴漢ﾜﾛｼｭwwwwwwwwwwwwww
負け犬痴漢ﾜﾛｼｭwwwwwwwwwwwwww
×可能性だって考えれらるだろ。 →○可能性だって考えられるだろ。
物理演算やAIって処理はメインメモリにある共有データを
頻繁に参照しないといけないはずで、こういう処理はLSのような
一時領域的なメモリはあまり生きないだろ。
とすると、SPEって何に生かせるのかって疑問が出てくるわけだ。
物理演算やAIって処理はメインメモリにある共有データを
頻繁に参照しないといけないはずで、こういう処理はLSのような
一時領域的なメモリはあまり生きないだろ。
とすると、SPEって何に生かせるのかって疑問が出てくるわけだ。
なんで１回目の演算と２回目の演算をひとくくりに考えちゃうのよ
CELLが駄目ならXBOX360CPUはどうなるの？
と言われると、CELLより更に駄目って事になるｗ
しかし、そのそもCPUがボトルネックになるような
シーンがどの程度あるのかと・・・
XBOX360のCPUでもキャラ2000体ワラワラ動かせるって噂があるのにな。
これ以上CPUの性能上げても使い道が無いだけでは。
と言われると、CELLより更に駄目って事になるｗ
しかし、そのそもCPUがボトルネックになるような
シーンがどの程度あるのかと・・・
XBOX360のCPUでもキャラ2000体ワラワラ動かせるって噂があるのにな。
これ以上CPUの性能上げても使い道が無いだけでは。
ほんと誰だよスイッチ入れたの
＞これ以上CPUの性能上げても使い道が無いだけでは。
＞これ以上CPUの性能上げても使い道が無いだけでは。
＞これ以上CPUの性能上げても使い道が無いだけでは。
もう帰れよ低脳
＞これ以上CPUの性能上げても使い道が無いだけでは。
＞これ以上CPUの性能上げても使い道が無いだけでは。
もう帰れよ低脳
結論はそこに行っちゃうのかよ
なんか口調とか人の意見聞かないとことかが・・・の人みたいだが？
しかし、XBOX360のCPUが駄目と言っても、
XBOX360の場合GPUがCPU的な仕事もある程度できるので
総合的にはそんなに駄目じゃない。
頂点とピクセルは同時に高負荷にはならないというATIの
分析は素晴らしいですな。
XBOX360の場合GPUがCPU的な仕事もある程度できるので
総合的にはそんなに駄目じゃない。
頂点とピクセルは同時に高負荷にはならないというATIの
分析は素晴らしいですな。
>>ID:9fhNQisk
お前、以前CELLスレで長々と今日と同じ事言ってなかったか？
文体に物凄く見覚えがあるんだが？
お前、以前CELLスレで長々と今日と同じ事言ってなかったか？
文体に物凄く見覚えがあるんだが？
あーCELLスレにもちょくちょく書き込んでいるから多分俺かもしれない。
ま、そーでもいいけどな。所詮一名無しだし。
ま、そーでもいいけどな。所詮一名無しだし。
×ま、そーでもいいけどな。所詮一名無しだし。 →○ま、どーでもいいけどな。所詮一名無しだし。
>>830
しかしゲーム機でもCPUがボトルネックになる処理ってもうあんまり無いんと違うのか？
ディスプレースマッピング系の処理はGPU側でOKだし、物理演算なんかもHalf-Life2の時点で
ある程度実現されているし。
もうそんなにCPUパワーが必要とされる場面って無いような気が。
>>830
しかしゲーム機でもCPUがボトルネックになる処理ってもうあんまり無いんと違うのか？
ディスプレースマッピング系の処理はGPU側でOKだし、物理演算なんかもHalf-Life2の時点で
ある程度実現されているし。
もうそんなにCPUパワーが必要とされる場面って無いような気が。
つーか、最近のベンチって大抵CPUがボトルネックじゃなかったっけ？
7800GTXもCPUがボトルネックって言われてるな
物理演算なんてどう考えても当たり判定の前処理みたいな物なんだし、
やればやるだけCPUが必要なんて考えなくてもそーなんじゃ無いのか。
物理演算云々言い出してCPUが必要ないって展開は意味わからん。
やればやるだけCPUが必要なんて考えなくてもそーなんじゃ無いのか。
物理演算云々言い出してCPUが必要ないって展開は意味わからん。
次世代であっても現実世界との絵の差はまだまだ遙かにある。
この差を埋めて行くにもＣＰＵＧＰＵともにもっともっと進化する必要が
あるんじゃないのか？
この差を埋めて行くにもＣＰＵＧＰＵともにもっともっと進化する必要が
あるんじゃないのか？
>>833 超既出
ところで、Xbox 360開発者向けの、alphaキットと実機との相違を解説した
ドキュメントが出回っているらしい
http://www.beyond3d.com/forum/viewtopic.php?p=569006#569006
それによると、alphaキットは実機の三分の一の性能だが、汎用コード性能はalphaキット
(PowerPC G5 dual)の方が上とのこと。あとキャッシュのコントロールなんかを上手くやら
ないと性能が出ないとも。
ところで、Xbox 360開発者向けの、alphaキットと実機との相違を解説した
ドキュメントが出回っているらしい
http://www.beyond3d.com/forum/viewtopic.php?p=569006#569006
それによると、alphaキットは実機の三分の一の性能だが、汎用コード性能はalphaキット
(PowerPC G5 dual)の方が上とのこと。あとキャッシュのコントロールなんかを上手くやら
ないと性能が出ないとも。
>>842
・キャッシュのコントロールなんかを上手くやらないと性能が出ない
こっちは3コアでL2共用だから当たり前として。
気になるのは、
・汎用コード性能はalphaキット(PowerPC G5 dual)の方が上
だな。
やっぱり970コアじゃなくてPPE相当と考えて良いのやら。
・キャッシュのコントロールなんかを上手くやらないと性能が出ない
こっちは3コアでL2共用だから当たり前として。
気になるのは、
・汎用コード性能はalphaキット(PowerPC G5 dual)の方が上
だな。
やっぱり970コアじゃなくてPPE相当と考えて良いのやら。
XBOX360のCPUコアはPowerPC G5と同程度の性能が出せるか未知数だが
もしかしたら出せないのかもしれないな・・・
x86系CPUと同様、キャッシュをある程度増やして2コアにした方が
実行性能は高かったのでは。
もしかしたら出せないのかもしれないな・・・
x86系CPUと同様、キャッシュをある程度増やして2コアにした方が
実行性能は高かったのでは。
ディアルコアのメリットは性能低下を
防げること
intelの人間もいってるじゃん
防げること
intelの人間もいってるじゃん
PPC970は２コア合わせてもL2キャッシュはXBOX360とおんなじ1MBですよ