2 :
名無しさん必死だな:2005/07/07(木) 12:58:35 ID:UtbtAPl4
2get!
SM4.0ってなんだ?
DirectX 10と同じ様なもんかと。
cellはおかしいんだよ
なぜ低消費電力で理論値上性能もメチャクチャ高く
PS3に載る位に価格も安いのに実態がでてこないのか・・・
360CPUもかなり無理してきただろうからね
それを最適化うんぬんでPCには使えませんなんて
基本的にlinuxなんか使う奴は1つや2つぐらいの用途でしか
使わないしそれ一つだけの最適化なんていくらでもできるだろ
基本的にワークステージョンの考えに近いだろうからね
cellはSGIのCPUみたいだ
シェーダーモデル4.0、シェーダーモデルというのはピクセルシェーダーと
バーテックスシェーダーがどれだけの機能を持つかという基準で、
マイクロソフトの定めた物・・・だったかな
規定されている機能を満たしていればそのバージョン対応って事になる
まぁ、GPUの性能はSMだけで決まる訳じゃなく、対応してても遅くて使い物に
ならないとかもあるので、あくまで対応している機能の最低限の目安だが、
PCでDirectXを使う場合は使えるのがこの範囲に制限される
OpenGLやゲーム機の独自APIでGPUを使う場合は、GPUの持っている能力を使い切る
ためにSMに縛られる事は無い
つーか、RadeonX850 はSM2.0だしね。
>>7 採用CPUは必ずしも性能・消費電力では決まらない。
もしそれで決まるのであればMacでも、IntelよりむしろAMD採用するでしょ。
DD1テープアウトが去年夏、DD2テープアウトが今年春、ここから量産開始して、
少なくともソニー生産分はPS3に載るし、他も回される可能性は十分ある。
現状家電、PC等他に大量供給しづらいという事情もあるし、
そもそも登場したばっかりなのだから情報が少ないのも仕方ないでしょ。
でもIBMがオープン化と言ってるので、これから情報が色々出てくる。
12 :
名無しさん必死だな:2005/07/07(木) 15:48:48 ID:k4OpcKdD
つまりだ
性能がかなりハッタリ臭いんだよ
N64も大々的にワークステーション用の
凄いCPUだと宣伝したが実態は
PSのシャギをとったようなソフトばっかりだけ
メモリの問題もあったんだろうが・・・
つまり次世代機のゲーム戦争はCPUの性能
なんかあまり問題ではなくGPUで決まるんだよ
cellは糞だということだ
途中の説明のせいでまったく説得力なくなっちゃったけど^^
まだ1行書き捨てていった方がましだったかもね
結論はCellがクソだとしてもPS3が最強だということか。
判りにくいな。
>>10 確かSM2.0bだかの2.0拡張だったような
>>13 実際にIntelCPUの100倍の性能を叩きだしたCPUがハッタリですか・・・
ま、何が言いたいかは理解しましたが、主観のみで構成されている
そのような意見はvsスレで思う存分どうぞ
PS3はGPUも糞だよ。
>PSのシャギ
19 :
名無しさん必死だな:2005/07/07(木) 16:01:16 ID:xwndrQzn
日本人が話している気がしねえ(;´Д`) ・・・
R4300は高性能CPU。
コプロセッサも優秀。
だがプログラマーの負担を考えて無かった
いきなりマリオ64を出したから
あれくらいできて当たり前かと思わせた
そもそもCell(だけに限らない)が、ある用途においては相当な能力を持ち
向かない用途においては糞であるなんざ、当たり前すぎる話じゃないのか?
てかこのご時勢で同程度の価格(面積)をもつシリコンで全てにおいて
最高性能であるなんて魔法の技術があるわけないじゃん。
でゲーム用途にしぼったらCellはそこそこいいアーキテクチャーなんじゃねって事で
ワークステーションだのPCだので最高である必要はさらさらないと思うがな
>>実際にIntelCPUの100倍
300GHz相当とすると、メモリやL2とか全てがボトルネックになるような気が。
PS2が出るときも似たような事いってたけど比較に使われたPen3と大差ないXBOXより遅かったし。
知識無いので聞きたいんだけど、どんな用途の場合に100倍の差が出るの?
cellは凄い→じゃなぜintelに対抗できないの→最適化できないから→
最適化なんてやればできるよ→linuxだし大変だから→それでもcellは凄い
EEの二の舞だな
Cellを300GHz相当とみなすより、
Cellが3GHz×7なのに対してP4が200MHz相当の働きしかしていない、と考えた方が
100倍の差がどうして生じるか考えやすいかも。
メモリとCPU速度のギャップがありすぎて、伝統的な階層型キャッシュ機構だけでは
せっかくのCPUの速度が死んでしまうのですよ。(ストリーム処理の場合、ね)
>>23 >cellは凄い→じゃなぜintelに対抗できないの→最適化できないから→
>最適化なんてやればできるよ→linuxだし大変だから→それでもcellは凄い
大間違い。
正しくは、cellは凄い→じゃなぜintelに対抗できないの→土俵が違うから
最適化に関してもPCにおける最適化とゲーム機の最適化は違う。
というか、Linuxだから大変とは誰も言ってないし。
”高性能だったら全ての用途において最高でなければウソ”ですか。
凄い理論ですね〜。
我慢して64の二の舞っていってたのにもうEEの二の舞になっちゃったw
こらえ性のない妊娠だなぁ
違うだろゲームパフォーマンスも優れているなら
PCとしても優れているということはある程度説明できる
PenMや64みてもしかり
それにPCアプリなんてそんな複雑な計算するわけでもない
cellは凄い→じゃなぜintelに対抗できないの→ハッタリだから
なんか、凄い展開になってきた
>>24 実際には200MHzとかありえないわけで。
PPE+SPE*7 = Pen4*100 が成り立つとして、PPE単体でPen4の約12倍ってありえるの?
クロックは3.2Gとしてさ。
100倍差が出るのはストリーム(頂点ストリーム?)だけ?
物凄く局所的な部分で100倍なだけですよね?
32 :
名無しさん必死だな:2005/07/07(木) 16:23:41 ID:xwndrQzn
CELLは、座標変換(3DCG)や掛け算(ワークステーション)では使用するが、
PCのアプリでは使用しない浮動小数点計算が得意なんだよ。
技術的な話ができないのならVSスレに行けば良し。
ID:oycdOqFPが面白すぎる件について
でも、PC用にも問題ないでしょ。なんといってもパワーPCの3.2GHzなわけだから
Windowsと言うOS、ドライバの部分でのロス
PCアーキテクチャのロスも含まれるでしょ。
CS機の効率の良い理由には。
>>32 float や double なんぞずいぶん前から使いまくりですが。
>>33 質問が多い場合は過去ログ読みつつ半年ROMすか・・・
> 実際には200MHzとかありえないわけで。
いやいや。それぐらい、昨今のCPUがキャッシュミスのペナルティで止まってる時間は
意外に長いのです。そのボトルネックの解消を試みたのがSPEのLSとDMA。
キャッシュ通さなくてもベースクロックの400〜1033とかで動かせるんですが・・・
DRAMはレイテンシがあるでしょ。データ出せといってすぐ出てくるわけじゃない。
というか「メインメモリはCPUよりかなり遅い」ということがいいたかっただけなので、
200MHzという数字にはあまりこだわらないでいただけると有難く。
>>32 >PCのアプリでは使用しない浮動小数点計算
小数点の計算は、アクセサリにある電卓を開けばできますよ。
>>39 PCのバイオス設定かなんかでL1L2キャッシュ切ってみれ。
どんなけ遅いか体感できる。
んで、結局100倍差が発生するケースってのは・・・
>>43 メモリの速度に引っ張られるわけですよね。
今つかってるPCはメモリクロック400MHzなんで400MHz相当になる、と。
SPEは3.2GでLSも3.2Gで動作ですか?
DMAでデータを書き戻し・読み取りで発生するストールは小さいにしてもあるわけですし、
ストリームだとデータの再利用が薄い分、キャッシュの効果が出にくいと思うんですが。
なんか初心者丸出しの質問ばっかりで申し訳ないんですが・・・。
ROMってた方が良いですかね、やっぱり。
なんで今更FFTベンチを知らない奴が居るんだこのスレに・・・
FFTってキャッシュ速度に影響されやすいベンチだろ
> DMAでデータを書き戻し・読み取りで発生するストールは小さいにしてもあるわけですし、
その遅延はダブルバッファで隠蔽できる。片方でDMAがメインメモリと読み書きしつつ
もう片方でコアが計算。
高速フーリエ変換 【FFT】
1965年にベル研究所のJames W. Cooley氏とJohn W. Tukey氏が考案した、
離散的フーリエ変換と逆変換を高速に計算する手法。
画像や音声、映像などのマルチメディアデータの処理で多用される 重要なアルゴリズムである。
大規模FFT演算の実行性能をライバル社の3.2GHzのCPU・PCシステムで実行比較。
ttp://img126.echo.cx/img126/634/slide150on.jpg キモはやはりアルゴリズムとメモリアクセスにあるそうな。
フーリエ変換ってゲームであんまり使わないような気がするんだけど・・・。
>>48 なるほど・・・。
つか、Gekkoにもロックドキャッシュがあったかと思うんですが、小さいなりに同等なことができるって事すかね。
となると、箱○やレボでも出来ておかしくない気が。
>>49 SRAMは元々互換性維持によるプログラムの負担減らす為、
性能犠牲にして自動化してキャッシュとなったんだけど。
CELLは単一ハードって事で性能重視のプログラマブル化したから。
ここら辺最適化すれば単純なスペック以上の差が出るんだろうな。
まあ、intelにかなわない理由はただ一つ、Windows互換じゃないから。
appleが採用しない最大の理由は、ノート向きじゃないから。
フーリエ変換は まさに画像・動画のエンコだね。
この分野では文字通り ケタ外れに速い予感・・
あー エンコカード出せーーっ!!
まだわけのわからないことやってんのか
フーリエ変換でエンコが速いならなぜPen4が
普及した?
そのベンチはappleがG3やG4の時にやっていたペテンベンチ
に近いものがある
>>29 君は既に自分で答えに近づいている。
> それにPCアプリなんてそんな複雑な計算するわけでもない
そう。複雑な計算をしなければCellの力は意味が無い。
既存のアーキテクチャのCPUで十分だし向いている。
性能が必要な複雑な計算を必要とする時に、
そのタイトループをSPEに移して最適化する事がCellのキモなわけ。
そうすればFFTのベンチやMPEG2同時48本再生のように力を発揮する。
既存のコードをそのまま走らせて高速化するわけじゃないからね。
oycdOqFPはどちらかと言えば痴漢に見える
> フーリエ変換でエンコが速いならなぜPen4が
>普及した?
Intelの政治力。あとPentium4はエンコードにおいて速いCPUとされてるよ。
特にSSE2/SSE3なんかに最適化されたソフトではAMDよりも速い。
今の時点のCellに対して、既に市場投入されて数年経過して十分枯れているCPUを
持ち出しても仕方ないだろ。君は議論をする前に、自分の論理の破綻に気付け。
>>54 ん?
MPEG動画やJPEG画像は ひとまとまりの画素データに対して
複雑なフーリエ変換を行い、その後 量子化してデータサイズを減らすんだぞ。
P4もAthronも このフーリエ変換処理に演算能力を費やし、エンコに膨大な時間がかかるのだ。
>フーリエ変換でエンコが速いならなぜPen4が普及した?
悪いが、何を言ってるのか全く意味不明・・
>>54 > フーリエ変換でエンコが速いならなぜPen4が
> 普及した?
なんで Intel CPU は普及して、DEC の Alpha は駄目だったんでしょうね。
単にx86系だったからだろ
> なんで Intel CPU は普及して、DEC の Alpha は駄目だったんでしょうね。
ボリュームマジック。Alphaには開発コストを正当化できるだけの用途がなかった。
CellもPS3の需要があってこそ開発が可能だった。
[email protected]と
[email protected]では カタログスペックには15〜20倍程度の差しかないのに、
例えばマルチメディア処理の典型であるFFT演算などで ここまでの大差が開いたのは
アルゴリズムもさることながら、やはりメモリアクセスによる無駄・ボトルネックを
徹底的に低減するアーキテクチャを採ったからではないか。
マルチメディア処理の申し子のようなCPUだとは言える。
ただ、その他のどんな処理でも速い、というわけでは無いのは当然。
「何を強めるか?何を捨てるか?」ってのが 設計段階で徹底的に考慮されたのだろう。
だから、オフィスPC用途には 多分向いて無い。
Macには・・ あるいは向いていたかもしれんが、
インテルには それに勝る魅力があったのだろう。
価格とか、供給能力とか、チップの絶え間ない高速化とか。
社長秘書が美人だったとか
>>63 オフィス用途には無駄な機能の付いてない、素っ気無いPCが向いている。
OA機器に過ぎないPCがマルチメディア用途を飲み込もうとして肥大化
したが、結局はそれも頭打ち。今後は事務用途とマルチメディア用途で
二分化するだろう。
ベンチ一つじゃ駄目だ
appleのようにフォトショのぼかしフィルタ一つだけで
比べても駄目だ
どうせ性能はどっこいどっこいだろうが
>>66 じゃあ、箱○のCPUでMPEG2の48本同時再生をやってみる必要があるな。
ベンチという一つの指標を無視するというのであれば、
他に根拠を持ってこないと意味が無い。
>どうせ性能はどっこいどっこいだろうが
無根拠にこういう事を言い出すのはVSスレ向き。
>>66 その通りだと思う。
だから、とりあえずベンチでどっこいどっこいになったところのソースを持ってきてくれ。
>>66 IBMの大規模FFTデモを
実際のアプリケーションの形で実演したのが
東芝のMPEG2再生デモ。
DVDサイズで48本、HDTVサイズで12本、同時デコード可能。
ベンチ1つではまだわからない、というのは同感だが、
では君は 何のベンチをして欲しい?
これは、というものがあれば示して欲しい。
>>50 ロックして高速ローカルメモリとして使う事はできるかもしれませんが
メモリによるボトルネックが解消された場合は、純粋に処理能力の勝負になるわけで
そうなると理論値が高いほうが有利になる事はわかりますよね
つまりCellはボトルネックによる影響をできる限り減らして、高い演算性能を高いまま
有効活用できるように作られたと
普通の人間の考え方
Pen3 なかなかいい
PenM 15wの消費電力の割にはすごい計算能力だ
Pen4 電力食いずぎ性能もイマイチ
これをすべてほぼ同じ性能になるようにクロックアップ
Pen3 電力食いすぎ、熱すぎ
PenM 期待はずれ
Pen4 電力食いずぎ性能もイマイチ
つまりCPUなんて所詮は消費電力なんかと大いに相関関係があって
intelはPen4を捨てPen3のプロセス技術を上げたのやPenMOC版投入して
これるだろう。だがそういうことはしないしできない
なぜなら夢のようなコアなんて存在せずcellもまさにそれ
クロック分の仕事しかできない
>>74 どこから突っ込んでやったらいいんだろう・・・w
とりあえず、相関禁止な。
>>74 ほぼ同じ性能なら性能が期待はずれだったり性能がいまいちのだったりする訳ないだろ…
ほぼ同じ性能なんだから。
何が言いたいんだ?
>>これをすべてほぼ同じ性能になるようにクロックアップ
Cellでこれをやると、同じ性能になるようにクロック”ダウン” だよな?
すると、「低消費電力なのに、高性能」ってことになるのでは。
Cellの電力が低いとは言わんが、性能/電力比は 凄い優秀だと思われ・・
P4よりずっと低いと思われる消費電力で、遥かに高いマルチメディア性能。
・・・つーか、一体何が言いたいのだ?( ´ω`)
>>74 とりあえず、同じAT互換機のCPUとしてIntelのCPUよりも低消費電力で
高パフォーマンスを叩き出してるAMDのAthlonのことを忘れてない?
>>75 とりあえず「相関関係」辺りからw
あ、やっぱ、やめとこう。
Σ( ̄□ ̄;) うわやばい! コイツ”相関関係”だッ!!
逃げろっ!
|彡
意味がわからないかなぁ
クロックも上げれて性能/電力比もめちゃくちゃよくて
低発熱なんていうCPUなんて存在しないんだよ
>>74は性能=消費電力と強引にこじつけてアーキテクチャの優劣を無視して
CellをPentium4と「どっこいどっこい理論」に持ち込みたがっているようだけど
Intelの各CPUの比較を出してきた時点でアーキテクチャ無視のこじつけを
いきなり自分で破綻させてしまってるぞw
>>73 純粋にクロック辺りの命令効率ってCellの方が箱360やレボより高いんですかね。
SPEが沢山乗ってるCellの方が高そうな気はするんですが、PPCベースである以上
大きな差は出ないと思うんですけど。
flopsでは箱360の倍近くPS3lの方が上回っていましたけど、3コア対1コア+7ですから
キャッシュの恩恵が大きいなら数値上もう少し離れても良いような気がするんですが。
>>71 ultra出ますか、来ますか・・
R520と頂上決戦ですかな?
>>82 簡単なことだよ。
Intelは設計に無駄が多いからクロックも上げられなくて性能/電力比もめちゃめちゃ悪くて
プロセス微細化してもリーク電流発生しまくりで逆に高発熱になっちゃうだけなんだよ。
つか、CellってPen4より性能高くて低発熱だから、性能/電力比はめちゃくちゃ良いと思うけど…
Pen4は例え PPCも絡んでくるけど
設計に無駄がなくてもathlonのように
糞みたいに発熱するCPUもある
CPUは発熱すると安定動作ができなくなるため
さらに電圧を上げなれければならない
そしてさらに発熱する
コア毎に性能/電力のベストな状態が存在する
91 :
名無しさん必死だな:2005/07/07(木) 18:32:12 ID:BFQ0V07B
>>87 上のまとめ
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を載せた廉価組み込み版などもありうるかもしれない
蹴られちゃった・・・
>>90 そうですか。それを前提としてあなたは何を言いたいのですか?
96 :
名無しさん必死だな:2005/07/07(木) 18:41:19 ID:fm/HWvJG
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.6x7=217.6≒218Gflops
XBOX360はPPEを3つ積んで 38.4x3=115.2Gflops
Cellの設計ではSPE一つあたりではPPEで負けても、数を増やす事で演算能力を
強化する方向を選んだと
それから理論値にはキャッシュの効果は全く関係無いよ
>>91 既にGPUで○>PS3なんて崩れてると思うが
>>920 実はR520はR500(Xenos)と同じかどうかまだ分かってないんだよね。
それにXenosはコア部分は2億ちょっとで、eDRAMが1億くらい占める。
が、eDRAMを搭載できないR520はコアだけで3億あると言われてる。
だからR420の進化系だという話もある。
> R500も同じプロセスだろう?
> 一体どうやって何百万個のXENOSをMSに供給できるというのか?
これは「大きなお世話」な気がするな…。違うチップなのに。
102 :
100:2005/07/07(木) 18:45:58 ID:r6PNX/wY
R500はNECがつくる
>>95 そのCell型アプローチで作られたCPUがXBOX360に乗るわけじゃないでしょ
もしかしたらレボリューションには載るかもしれないけど ;-p
まぁ、Cell型が有効だと判明してから設計始めたんじゃ出てくるのは当分先だし
Cellの普及には影響しないだろうね
Cellはやっぱり他のどこかが採用してくれないと
EEと同じ道を辿るような気がする。
>>90 >>95 プロセッサ毎に性能/電力のベストな状態が存在するからcell脂肪。
つながりが全く分からない…(性能/電力)はCellの方がかなり高いし。
>>107 だから両者には”相関関うわ何をするqwせdrftgyふじこlp;@
>>107 自分がダメだと思うからダメだと言ってる奴なんて所詮そんなものですよ
R520については悪い噂が聞こえてくるのに、R500については聞こえてこないなら、
Xenosの生産は順調、と考えるのが順当なんじゃないのかねえ。
ATI/TSMCの歩留り情報はダダ漏れ、という前提で。
>>110 Xenosがどうかはともかく、歩留り情報ダダ漏れはないでしょ。
ATiはR520のスケジュールをアナウンスしてるわけだから、
それに遅れてる事に対する事情説明とかは必要だしね。
>>98 互換性があるっぽいんでPPCベースかと思ってました。
>それから理論値にはキャッシュの効果は全く関係無いよ
そうでしたか。
てことは、キャッシュがガッツ次第で有効活用できるCell、
従来のCPU同様のキャッシュ効率の箱360のCPUでは、
Cellの方が実効値は落ちにくく、差はもうちょっと開くってことすかね。
つか、サイズの問題が出ると思いますけど、箱360タイプで各コアにロック可能なキャッシュと
DMAが付いた構成が出来れば、Cellより柔軟で実効値もそこそこなCPUになりませんかね。
理想論なんですけど。
oycdOqFPに構ってやってるあんたらやさしいね
R520とXbox360のGPU(R500)が全く違うものなら
なぜ「R5xx」という開発コードにしたのか疑問なところだが
>>110 R520は元々は春発表で7月には発売してるという話だったから量産→90nmプロセスでリーク電流
という話が出たんだろう
R500の量産開始は8月〜9月ころだろうからR500自体の問題は出ようがないだろう
ロック可能なキャッシュと言っても、コヒーレンシの問題とかもあるしなぁ。
mpeg2を48本同時デコード、縮小して、動いているサムネイルを並べて1080動画に
して見せているっていうのはcellが得意な処理だから出来ているだけで、
別の処理させたらPen4に余裕で敵わないなんていうことはないのかしら。
R520が苦労してるのはリーク電流。新設計+90nmプロセスを同時に行った為と言われる。
XenosのほうがTr数が少ないとはいえ新設計+90nmプロセスであることは同じある上生産数が
桁違いな以上、かなり量産に赤信号が灯っていると考えるのはおかしくないと思う。
>>117 もちろん、SPEにオフロードしてない/できない処理は余裕で敵わない。
Cellの優位は、プログラム中のホットスポット(頻繁に実行する個所)を
SPE向けにC/C++で書き直す、というのが大前提。
120 :
名無しさん必死だな:2005/07/07(木) 19:09:30 ID:GLxm2rCd
>>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%以上を出せるみたいだぞ?
(任天堂に関してはノータッチなのであくまで伝聞)
>>112 そんな感じじゃないかな
CellのSPE内のLSはL1キャッシュ並の速度、レイテンシで256KBもの容量積んでると
考えると、LS内で済む処理は実行性能が高そうと想像できるでしょ
リッチなコアを載せると消費電力やダイ上のサイズの問題が出てくるので、
性能が伸びる可能性はあるけれど、発熱や歩留まりが問題になる可能性が高い
Cellは単純に性能だけを考えた訳ではなく、生産性や消費電力の事も考慮にいれて
作られてるからね
90nmプロセスでの生産について言えば、SONY+東芝だって3億トランジスタの巨大GPUを作った経験は
ないよね。EE+GSが5000万トランジスタぐらい?
Cellの第一世代はIBMの工場だろうし(歩留まり問題は過去にいろいろあった)、
綱渡りなのはどこも一緒じゃないかと。
発売延期までして再設計したってことはATIの90nmプロセス世代のリーク電流に対する見通しが甘かったということなんだろう
これがATIの一つのチームの問題だったとするのなら良いんだが、
社内全体で認識が甘かったということだと、同じ90nmプロセスで新アーキのR500にも設計上で同じような問題が
とか言ってみたり
スルーすべきだけど、ちょっとだけ
実行性能で理論値の40%出るならCellは 218x0.4≒87Gflops、
1コアはOS専用らしいXbox360CPUは 38.4x2x0.8≒61Gflops
って事でいいのかな?;-p
Cell,RSX共に90nm最大の問題であるリーク電流に関して対策をする必要が無い
これだけでもアドバンテージは大きいぞ
歩留まりの話も荒れるからするな
360の「1コアOS専用」ってのは、
「システムコールでカーネルモードに遷移できるコアが特定コアだけ」
の意味だと思うんだけど、どうなのかなあ。
360のカーネルって、NTカーネルだけどXboxのものの拡張版っていうから、
おそらくSMP対応してないものでしょ(オーバーヘッドあるから)。
スレッドはコアに固定で割り付けられるんだと思うんだけれども。
なんか、360は別に一コアをOS専用にしなくても良いって書き込みを見たが
よくわかんね
MSは最近性能には口を閉ざしLiveを猛烈にプッシュしてる
どういう事情に置かれてるのかは推して測るべしだな
>>124 発売時期が同じだというならどこも一緒だけど
○は今年中に出す予定なんだよな。
>>123 なるほど、おかげさまで形が見えてきました。
Cellの肝になるSPEですけど、コード領域ってやっぱりLSに置かれるんですかね。
突っ込んだ話になりますけど、LSに置かれるとなるとプログラムの入れ替えは実行中の
位置に上書きできるとも思えないので、PPEからの入替えになると予想しますが、
そうなるとPPEに割り込みをかけて入替えリクエスト発行・SPEをスリープ・
DMA終了割り込みでSPE起動、みたいな手順が予想されますが、
入替えが頻発するような場合はPPEの処理が結構阻害されてしまうように思えます。
あくまで予想なんですけど、なんかパフォーマンスを引き出しにくい作りの様な気がします。
コード領域がメインメモリに取れるなら全然問題ないんですけど。
>>130 普通に考えたら特定コアの1スレッドを、OS呼び出しでスレッド切り替えが起きる
オーバーヘッド回避の為に予約って事だと思うんですけどね
まぁ、>127は、ソースも無いネタにはネタレスって事で
アプリケーション用コード領域もダブルバッファにするとか。
そうすればDMAで自立的にコードとデータを取ってきて処理できる。
メモリのヤリクリは更に大変だけれど。
>>134 だからSPEのスレッド切替の粒度は荒くなり、
通常のOSのスレッドのように時分割ではなく、タスクが完了するまで実行し続けるのが
基本になる。
こんなスレわざわざ貼るまでのソース
なんか必要ないよ
まじめに討論したきゃcellスレ逝けよ
もっとも過疎化が進んでいるがww
PPE用コードとSPE用コードは違うのでは?
>>134 ゲームプログラムに限定すると、SPEのスレッド(プログラム部)を
頻繁に入れ替えたりしないでしょ。複数のスレッドを置いとくことも出来るし。
(どのスレッドを実行するかの指定は必要だろうけど)
シェーダの動的分岐対応にしたって、シェーダの頻繁な入れ替えを
嫌う側面もあるわけで。
141 :
名無しさん必死だな:2005/07/07(木) 19:44:03 ID:16+jBJbE
>>121 Xbox360 CPUの詳しい仕様を知らないのでなんともなんだけど、
そういう使い方が出来るものなの?
ある特定の実メモリと、L2キャッシュの領域それぞれを指定してロックするわけ?
>>130 SMP未対応のカーネルでどうやって3コア動かすの?
だとするとSMTも駄目なわけだし。
1コアOS専用なんてデマだろうに。大体OS専用って具体的に何するんだよ。
ちなみに俺が聞いたのは問題の1コア2スレッドの内、
1スレッドはLIVEで、1スレッドはサウンド。
まあどっちにしろ開発者の裁量に任されてるだろうけど。
スレッド数は多ければよい
なぜならうまくやれば性能低下が防げるから
N64はCPUでサウンドをまるまる処理したので
実行性能が低下しまくった
>>137 概ね134の認識は間違ってないと。
スレッド切り替えを抑える形となると、定型処理で回すのが現実的なんですかね。
モーション周りや、カリング・コリジョン・シェーダーとかかなと。
この辺りのデータって物によっては256KBじゃすまないしと思うんですが、分割して
取り込んでいくとデータの扱いが結構大変な気がしますが・・・。
なんか、妄想するととキリがないようなw
>>144 それはサウンドで1スレッド使ったって事ですやん
>>120 やっぱりCELLって性能たいした事ないのかな・・
>>144 コンテキスト切り替えにもコストが掛かるわけだが。
>スレッド数は多ければよい
なんで、そんな単純な話じゃない。
> SMP未対応のカーネルでどうやって3コア動かすの?
カーネルへの遷移が許された(ハードウェア)スレッドが一つあって、
それ以外の5つのスレッドは基本的にOSの管理外になる、ということ。
もちろん、コンテキストスイッチや排他制御はOSが面倒みてくれるだろうけど、
SMPカーネルのように、カーネル内でスレッドが複数動いて、複数のI/Oを
同時に処理したりはできないよ、と。
>>145 そこをいかにうまくやるかがcellプログラミングのキモでしょ。
まぁ256KBもあれば大抵のことはやれるとおもう。
ゲームプログラマというのは4KBとか8KBでも何とかしてきた人達なので。
840XEも悪くないCPUなんだろうけどね
現段階では最適化できてないんでしょ
>>134 SPEが実行できるのはLS上のプログラムだけです
SPEは単体でDMA経由のメインメモリアクセスできるので、基本的にはPPEに割り込みを
かける必要は無いでしょう
で、確かに入れ替えの頻発するような状況だと性能低下は避けられないと思いますが
そのような状況にならないように利用するのがCellの有効な使い方でしょうね
それからプログラムの有名な法則として10−90の法則というのがありまして、
>たいていのプログラムの場合、プログラムの一部分(約10%)が
>ほとんどの処理時間(約90%)を消費しているという法則だ。
なので、重い処理の部分だけを抜き出せば256KBで十分と設計者が判断したのでしょう
SMP対応カーネルっていっても、カーネル内プリエンプションするとは限らないわけで。
FreeBSDやLinuxの古いバージョンなんかはカーネル内はジャイアントロックしかなく、
カーネル内では複数のスレッドは走らない構造だったしね。
今のバージョンでは粒度の細かいロックを使うようになってプリエンプションできるようになったけどね。
それにカーネル内プリエンプションする方が、
リソース待ち時間の隠蔽できるしいいと思うんだけどな。
> それ以外の5つのスレッドは基本的にOSの管理外になる、ということ。
システムコールとか使えなくなるし、ちょっと厳しいような。
>>147 Cellは、これまでのPCアプリを高速に実行することが目的じゃないし。
ストリーム処理性能が、ずば抜けて高いCPU。
>>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との関連は不明とのこと。
>>145 その辺の処理だとデータのアクセスがシーケンシャルアクセスに近くなるので、
ダブルバッファとDMA裏読みでなんとかなるかと
完全にランダムですと厳しいでしょうけど、その場合はSPEが2スレッド動かせるのを
利用して片方の読み込み遅延中はもう片方が処理をすれば、DMAレイテンシを
隠蔽できますし
カーネルをSMP対応させると排他制御が複雑になり、オーバーヘッドが無視できないほどある。
サーバ用OSはSMP機でカーネル処理をスケールさせなきゃいけないのでそれも仕方ないが、
ゲーム機なら大半がユーザプログラムの演算処理だから、カーネルはシンプルなままでいい。
でないとリアルタイム処理なんてできない。
360でも、マルチコアで増えた分のスレッドは、
演算処理をメインスレッドからオフロードさせる用途で使うのが主ではないかと。
>>152 いや、実行中のSPEのコードの入替えははすがに無理じゃないのか、という意味です。
自分を上書きした後に先頭から実行できる機構があれば出来そうですが。
>>150 さすがに昔とはやっていることの難易度も大きさも違うと思いますが、
その手のカリカリチューニングがPS2で嫌われていた、敷居をあげていたところが
あると思うんですけどね。
そこまでやらずともスペックを引き出せるのが理想ですし。
>>156 モーションってシーケンシャルに出来ます?
階層を行ったりきたりするので入替えは慎重にやらないといけないと思うんですが。
いや、そういうデータは扱わなければ良いのか。
>>157 PS3なんかはPCのゲームとの互換性みたいなものを気にしなくていいけど、
PCプラットフォームのゲームだとSMP/SMT対応のカーネルを使って、
どのスレッドもシステムコールの発行ができるようにするよね。
Xbox360がシングルなカーネル上で動くとなるとPCとの互換性が無くなるでしょ。
そういう戦略をPS3側が取るならわかるんだけど、Xbox360でやるんかな?
>>158 SPE内のプログラムが自分で、自分のコードの一部を入れ替えする事は、不可能じゃ
無いとは思いますけど、やる意味があるんでしょうか・・・?
モーションと言われても色々あるのでどのモーションかにもよるとは思いますけど、
LSの256KBあれば、数キャラ分のデータは乗り切りるんじゃないでしょうか?
単にコードが大きすぎてLSに収まらないなら、それはPPEで実行する性質のものだと思う。
耐タンパ性のために、外部から遮断されたSPEが、暗号化された実行コードを自己書換えして
復号する、というのはあるだろうね。セキュリティのための仕掛けは非公開でいろいろ
用意されていそうだが。
>>160 それぞれの組み方はともかく、MSが明示的にスレッドの扱いを限定しておかないといけないわけだけど、
現状のPC方面でそういう通達とかでも出てる?
無ければ、互換性に苦しむハメになると思うのだけど。
まあXbox360がそういう方向性でいくとなれば、
大分Cellとの親和性の高い考え方な気はするな。
>>161 よく考えたら7つもあるからほかのSPEに任せればいいんですね。
稼働率を上げまくるなら、手が空き次第プログラム入れ替えてでも
ぶん回すのかなーと思ってたんですが、ちょっと頭が足らなかった感じです。
コードは個別に32KB程度でもキャッシュを持ってメインメモリから実行できれば
かなり柔軟になる気がするんですけど、諸々あって今の形になったんだろうなー。
東芝はCELL開発環境にこんな仕組みを実装
■256KBのLS容量にが収まらないことが考えられるため、「SPEオーバーレイ」と呼ぶ仕組みを実装。
プログラムやデータを主記憶上に配置し、その一部の関数だけを実行時にLSに動的にロードして実行する。
SPEオーバーレイにおける関数の入れ替えは、DMAコントローラが行う。
cellは忘れ去られました
>>167 IBMの本命=Power ソニー相手の適当な金儲け=CELL
cellもpowerなんだが。
PPEは無しで、SPE10個のほうがゲーム機に向いていると思う。
ヘテロコアのPPEにあたる部分って単に互換をとるだけでこれ以上性能が上がる見込みがないのにじゃまなだけ。
今、IBMがHD世代AV機器向けに、家電各社に売り込みしているのはCELLじゃなくて360CPUの1.6〜2.4Ghz版だからなぁ
CELL家電はソニーからしか出ないだろうね
どこの各社だよw
>>170 SPEが直接メインメモリ参照できたらね。
ゲームプログラムでストリーム処理可できる箇所は
多いものの、100%というのは絶対に有り得んし。
PPE2つ、SPE4つ辺りが個人的にベストだと思う。
>>171 IBMが家電メーカーにXbox360のCPUを売り込もうとしているというソースを出してくれ。
>>177 余り関係ないが、3.2GHzに達しない品は
どう処分するんだろうねぇ?
ちなみに、LSが512KBなら 同じチップ面積を維持しながら SPE 6個、
LSが1MBなら 4個くらいの計算になります。
いかが?
>>170 いや、メインメモリぐらいDMAで参照できるって。
何を今更寝ぼけたこと言ってんだ?
そんなことよりOSを走らせなきゃならん以上、
PPEは必須だろう。
>>180 >いや、メインメモリぐらいDMAで参照できるって。
知ってますがな。
>直接メインメモリ参照
だから、直接と断わってるわけで。
DMAで参照する限り、広範囲のランダムアクセスは厳しいだろうから
連続したデータのストリーム処理中心になるだろうということ。
>>165 SPEオーバーレイか、関数管理の仕組はどうなっているのかな
例のタグ単位管理でも関数のサイズ制限を越える場合はどうするのか
実行中のコードスワップはしないだろうし、処理結果による分岐処理で関数
コールする場合DMAのロード待ちが有ると、その間は他のSPE回って事か
XDR大忙しだね
PPE -> XDR <- DMA -> LS (256KB) <- SPE x7
メモリアクセスは妥協だ。
スパコンのようにはいかんよ。
今ある分で我慢するしかない。
Cellは まだマシな方だろう・・
Cellも苦しいが、 xenonなどもっと悲惨だし。
970MPの1.6GHz時熱設計消費電力は出ないのか
れぼりゅーしょーん
>>185 PPC970は電力効率が悪いから、レボはPPC750ベースで来るような気がちょっとする
187 :
名無しさん必死だな:2005/07/07(木) 23:01:44 ID:1P+4WlnU
せっかく帰ってきたのに、ID:oycdOqFPたんが居なくなってて(´・ω・`)
oycdOqFPじゃないけど、ここは「次世代機テクノロジー」スレなのに、FFTベンチやMPEG2同時48本再生がうれしい理由って何?
ここがCELLスレなら理解出来るけど、次世代ゲームってムービー沢山同時に再生したり動画エンコードするものなのか?
そういうことができる、ってのも次世代機のテクノロジーに含まれるからじゃない?
その性能がゲームにどう役立てられるかを考えるのも作る人の仕事でしょ。
使い方次第で文字通り桁外れの性能を叩き出せる面白いプロセッサであることは確か。
次世代機テクノロジーの話題としては中心に位置するといっていい。
>>188 >FFTベンチやMPEG2同時48本再生がうれしい理由って何?
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
それって任天堂いわく、「新しい遊び」が提供できるかもってことじゃないの。
どこかのスレの住人みたいに「俺のとこのがすごい」「いや、すごいのはこっちだ」と
言い合ってても水掛け論なので、定量的な指標でお互いの性能を評価しようとすると
まずはMIPS, FLOPSというようなピーク性能であり、次にFFTやMPEGのアルゴリズムを
実際に実行することになるわけだ。実際にそれを使うかどうかではなくて。
Cellだけでなく、他のハードウェアでも結果が公表されれば、もっと理解が深まるのだが。
PCと違って不利な側は公表しないだろうね。
PS3は、PS3-Linuxも出るわけだし、発売後はPS3-Linux上でのベンチなんかも出るだろうね。
>>191 音声は浮動少数はつかわんですよ。
頂点・光源もCPUは最近はやら無くても良いんじゃない?GPUの方が速いし。
物理演算は恩気ありまくり。超ありまくり。
他にもいろいろ恩恵あるでしょ。
というかスペックがあげれるならあげれる方が良いし。
釣られて定価が上がりまくっても困るけど。
PS3のCPUは不良品だということをお忘れなく
>>193 応用が見えるプログラマには凄さが解るんだけどね。 > Cell(SPE)
もちろん、360CPUも凄いと思うけど。
つーか、xenonに関して何の情報も入ってこないのがアレなんだよ・・
どーしたIBM。
さっさと情報を出せ
199 :
188:2005/07/07(木) 23:46:21 ID:h1iCIpPV
>ゲームプログラムだと恩恵有りまくりですよ。
その割に擬似コードの一つも見たこと無いので、本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
役に立つか確証は無いが、すごいテクノロジーなのは確定なのでスレ的にはオッケーって事なのかな。
CELLスレだと結構懐疑的に見られてるので、えらい温度差あるなぁと思って質問した次第です。
もしかしてスレ的にCELLを褒め称えてる訳ではなくウザイ痴漢がいるので、相対的にそう見えるだけなのか?
Cellは外販もする汎用CPUだけど、360 CPUは特定製品向けの組込CPU扱いで、
少なくとも製品が出るまではIBMからはほとんど情報でないのかも。
>>195 >音声は浮動少数はつかわんですよ。
次世代機では物理音源処理にも挑戦するでしょ。
5.1chの為の音の移動にも使われるだろうし。
LSに置いた波形メモリの多重合成や、圧縮された曲データの
ストリーミング解凍だけでは、3GHzが勿体無い。
自作版のcellスレも見てみるといい
>>199 >その割に擬似コードの一つも見たこと無いので、
>本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
E3カンファレンスで実演されてましたがな。
それとも、CorC++コードそのものを公開しろと?
204 :
188:2005/07/07(木) 23:56:09 ID:h1iCIpPV
>それとも、CorC++コードそのものを公開しろと?
デモのソースコードをリークしろとは言ってないですが。
今までとパラダイムの違うアーキテクチャなんだから、擬似コードでも良いので処理の流れが判らないと信用できないと思うのが普通じゃない?
他人の言うことそのまま信じてマンセーするのは盲信だよ。
>>195 ヤマハのソフトウェア音源はSSESSEの使えないペンティアムじゃ
インストーラで蹴られる程だが。
×SSESSE
○SSE
ダブった。
今までとパラダイムの違うアーキティクチャだから、みんな日経NEの特集とか
読んで、とっとと頭に入れておく努力をしちゃうんだな。
>>201,205
このスレは色々勉強になります。
もっと精進します。
>>201 ProLogicIIやQサラウンドやBBEでも固定小数点だけどね。
正直、浮動小数点より演算早いから
ゲームでも結局チューンして固定小数点化してしまうのだろう・・・
>>209 プログラマじゃないからこういう頓珍漢な事いうんでは。
>>195 AVアンプとかではアナデバの浮動小数点DSPがよく使われてるよ。
CreamWare というソフトシンセ用 PCI DSP ボードにも使われてるし。
音源や音声自体を自動生成する音ゲーとか出たりするんじゃない?
くまうた for PS3 とか。
0.1の表現すら誤差の出る固定小数点サイコー
214 :
188:2005/07/08(金) 00:13:34 ID:HR4XMhnX
メディア処理系だと精度がある基準レベルで保てれば言い訳で
浮動小数点が速い処理系であればそれでやればいいし
俺も見てみたいですね.擬似コードでいいから.
209がプログラマみたいなんで,期待.
評価関数がSPEで実装可能かどうか(適切かどうか)によると思われる。
データもfloatで持つのかな。
ADPCMのような圧縮方式はFP8みたいなのでやんのかな。
あるのかしらんけど。
さすがに次世代機とはいえ無圧縮で持つのはあまりに無駄かと思うんだけど。
PS3/360の音周りって何か情報来てましたっけ?
擬似コードうるさいけど、SPEはC言語ですから…
256KBに収まるように普通に書けばよし。
IBM製製コンパイラが勝手に最適化してくれます。
>>214 何でSPEへのAIコード実装例まで、SCEとIBMが示さなきゃならないの?
もし、SPEが苦手とする処理なら、PPEで処理すれば良い。
それだけの話。
あなたのほうが短絡思考になってる。
222 :
188:2005/07/08(金) 00:23:00 ID:HR4XMhnX
>256KBに収まるように普通に書けばよし。
メインメモリをDMAでしかアクセス出来ないんじゃなかったっけ?
コンパイラの最適化でレイテンシ隠してくれるの?
>>214 SPEをフル活用するぐらいだから、相当深い木になるでしょ。
上から3レベルまでのノードはPPE、それ以下はSPE。
PPE⇔SPEだけmessage boxで通信すれば普通にできるじゃん。
>>222 探索問題なんて並列化が容易なんだから、SPE内で99.9%は収まる。
残り0.1%ぐらいレイテンシが発生したところでどうだというんだ。
SPEがダメと言いたいなら、もっと並列化が難しいものを持ってきなさい。
226 :
188:2005/07/08(金) 00:28:05 ID:HR4XMhnX
>何でSPEへのAIコード実装例まで、SCEとIBMが示さなきゃならないの?
SCEやIBMなんて一言も言ってないんだけど・・・。
>>214 例えば、本格的なゲーム制作者がわざわざコードを書きに来るわけが無い。
Cellでアイデアを実現してみようという人も自分の種をわざわざ明らかにはしない。
じゃあどういう状況ならコードが出てくるのか。
それは自分から動く人がいて初めて出てくる。
他力本願な奴が「コードかいてくれよ〜」なんて言っても誰も書かんよ。
これは2chの他の色々な板・スレでもそうだと思うけどね。
○○を作るスレみたいなのをいくつか漁ってみ?
前向きに、こういうコードなら動きそうだけどどう?とかそういうのなら、
気まぐれで誰かがアドバイスをくれたり、同レベルの奴が、
俺ならこう書くかもみたいなのをだしてくれるかもしれない。
とりあえず今のままなら、間違いなく誰も書きはしない。メリットないし。
下位の関数(激しく重い処理)として実装するならば、256KBもあれば十分だと思われ。
>>224 こっちは例としてAI処理が出された理由が解らんよ。
SPEで標準的なプログラミングモデルは
データはダブルバッファ、片方のバッファを処理してる間に
DMAで、もう片方のバッファを入れ替える。その繰り返し。
これで、どのような実装例出さなきゃ納得いかないの?
230 :
188:2005/07/08(金) 00:34:25 ID:HR4XMhnX
>>225はAIなんてラクショー!と言い、
>>229はAIが例に出てくるなんて変と言う
どっちが正しいのでしょう?
>>188は他人に対してばかり根拠を求めて
自分の意見の根拠やら正当性については完全に目を逸らしてるなw
AIがお題で出てくるのは変だが、実のところSPEでも結構イケる、が正解
αβ以前に探索は節の合流を判別する為にグローバルなハッシュを参照できないといけないから
SPEじゃむちゃくちゃ非効率。そんなことも分からないアホしかCELLマンセー派にはいないようだな。
>>219 PS3はPS2のデフォルトと同じADPCMかPSPとの連携からAAC辺りになるんじゃないの?
無圧縮PCMはBDと言えど無駄に嵩張るでそ。
>>233 そのグローバル値をLSに一緒に投げ込まなければいけないってこと?
例えば、次のA、Bの関数で、
main() {
関数A() // 1ns
関数B() // 1ms
}
処理時間が↑だとするならば、関数B()をSPEに割り当てればよい。
仮に関数B()がSPEに展開できない大きなサイズだとすれば、
関数B() {
関数C() // 10ns
関数D() // 90ns
}
関数B内の関数D()をSPEに割り当てるだけ。
結局ボトルネックになる箇所自体は、それほど大きな容量を必要としないと思われ。
関数D() // 990ns
の間違いだ。。orz
>>233 わざわざ遠く離れた枝との合流を判別する必要なんてないんだが
SPE内の枝だけを判別すればよし
というか探索問題の並列化なんてぐぐれば腐るほど出てくるというのに
コアの同期通信が必要だと高くつきそうだが。
>>234 ADPCM等の圧縮データは一度PCMに展開しないと合成できない。
メモリが許せば生PCMデータ使った方が楽。
ゲーム機ではメモリ優先だから圧縮形式にはなるだろうけど。
241 :
188:2005/07/08(金) 00:44:07 ID:HR4XMhnX
>自分の意見の根拠やら正当性については完全に目を逸らしてるなw
本当にCELLがゲーム向けかどうか疑問に思うことがこのスレ的には問題って事?
そもそもグローバルに散らばったメモリにランダムアクセスしようと思ったら、どんなCPUでもメインメモリアクセス速度以上は出ないと思われ。
LSに乗らないってことはキャッシュにも乗らないでしょ?
キャッシュに乗るレベルなら>238が言うように探索タスクの並列化して細分したLSに対し裏でDMAぶん回しとく方法でキャッシュと同等の効果は出る。
自動じゃないけどね。
>>241 >自分の意見の「根拠やら正当性」について
何をどう思ってcellがゲームに向いてないと考えたのか、そしてそれを何故正しいと思ったのか。
ここは「次世代機テクノロジー」スレなのに、FFTベンチやMPEG2同時48本再生がうれしい理由って何?
↓
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
↓
その割に擬似コードの一つも見たこと無いので、本当に恩英ありまくりなのかうさんくさく思えてしまう訳で。
今までとパラダイムの違うアーキテクチャなんだから、擬似コードでも良いので処理の流れが判らないと信用できないと思うのが普通じゃない?
(根拠言ってくれないと同意求められても無理だから)
↓
処理の流れ。
http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm ↓
いやいや、これSPEのスケジューリングで処理の流れじゃないでしょ。
たとえばAIだったらαβ法をどうSPEで実装するとか、そういう話なんだけど。
(いきなり強引な論点ずらし乙!)
↓
何でSPEへのAIコード実装例まで、SCEとIBMが示さなきゃならないの?
↓
SCEやIBMなんて一言も言ってないんだけど・・・。
(じゃあ誰が示すんだよww)
>>241 どう使えるのかはまだわからないけど、その機能がゲームに生かされる可能性がないわけじゃない。
CELLの能力を知るうえで参考となるデータが出されたことに対して、
ぐだぐだケチつけるのも野暮だと思うけどなあ。
検索より評価関数の処理効率を突っ込んだほうが
>>242 常時グローバルなメモリをランダムアクセスは必要ない。
ただし必要な時は必要だというだけ。
SPEでどう解決するかというネタなら意味はあるが
SPEで全く問題ないと言い張るアホにはあきれるばかりだ。
>>241 SPEがAIに向いてないと、Cellはゲーム機向けじゃないということ?
249 :
188:2005/07/08(金) 00:51:32 ID:HR4XMhnX
>>236 関数BやDが使うメモリがSPE内で収まってるなら効果的だと思うんだけど、他のグローバルなデータ参照してるとマズくない?
一度ロードしたメモリを無駄なく処理に使うのがSPEの真骨頂だと考えると、そうとうモジュール化できないと難しそうだね。
ある意味オブジェクト指向的なのかな。
局所性が少ないファイル検索アルゴリズムをSPEで解決できるか?
→議論の余地あり
探索問題のような局所性があって、すでにいくつも並列化アルゴリズムが実現されてるもの
→議論の余地なく全く問題なし
最近、グローバル変数ってあんまり使わんので考慮してなかった。
252 :
188:2005/07/08(金) 00:58:21 ID:HR4XMhnX
>>244 まとめてくれてありがとう。
擬似コードって書いてるのにまさかスケジューリングの話が出るとは思ってなかったもので。
私がコードって書いてるから、具体的な例としてαβ法とか出したんだけど、論点ずらしてるように見えましたか。
すまんかった。
プログラマは与えられた条件の中で、その都度効率的なアプローチを模索するのが仕事だから、
「SPEはAIに向いているか」という大雑把すぎる議論は無意味な気がする。
とりあえずSPEは、演算量多め、メモリアクセス少なめの問題が得意であるということしか
わからないわけだし。
彼はむしろメモリアクセス多い時の方がすごい。
ダブルバッファで交互に。休みなし。
あたしもう死ぬかと思った。
さすがSuperPenisErection
257 :
名無しさん必死だな:2005/07/08(金) 01:01:54 ID:oQ6uEJ6P
>253
メモリアクセスは多くても問題ないでしょ。
ランダムアクセスが多いとスケジューリングがめんどいってだけじゃ。
258 :
257:2005/07/08(金) 01:03:44 ID:oQ6uEJ6P
SPEのおかげでスレを昇天してしまいました。
>>217 >>R520を含め、ATIの今後の新世代GPUは、Unified-Shader構成を継承すると見られている。
R520は これまで分離シェーダのままで行く、
とか言われてなかった? 統合シェーダだったのか?
しかし、両者の言い分は面白いなー
同じゲームの中でも場面によって頂点シェーダとピクセルシェーダの負荷が違ってくる。
だから、統合シェーダだ、と。 成程、納得できる。
一方で、統合シェーダにも”無駄”はある、と。
全てのシェーダがピクセル処理で占有されることなど決して無い。
にもかかわらず、統合シェーダでは 全てのシェーダにピクセル処理機能を載せないとならない。
1つのシェーダに何もかもやらせようとすると、かえって”器用貧乏”、トランジスタの無駄になる、と。
成程・・ これも納得できる。
ま、結局は実行性能で決着が付くんだろうけど・・
>>253 >メモリアクセス少なめの問題が得意であるということしか
「メモリのランダムアクセス少なめ」ですな。
連続したアドレスのメモリアクセスは
LSダブルバッファによるレイテンシ隠蔽まで含めたら得意とも言えるし。
261 :
188:2005/07/08(金) 01:04:13 ID:HR4XMhnX
>SPEがAIに向いてないと、Cellはゲーム機向けじゃないということ?
いや、前のスレでAIも物理演算もガシガシいけるみたいな話題が出てたので、例にあげただけ。
物理演算の方はコードにするとどうなるか良くわかってないので、例にあげませんでした。
>>250 >局所性が少ないファイル検索アルゴリズム
通常、ある程度以上規模の大きいデータベースは
いきなり総当たりで片っ端からデータ舐めていくのではなくて
データベース構築時に実データとは別に検索キー別の
もっとコンパクトな検索テーブルを複数生成してるのでは?
グーグルとか片っ端から全データ舐めてるわきゃ無いと思うが。
263 :
名無しさん必死だな:2005/07/08(金) 01:06:48 ID:6rDmKiwg
>>259 ATIのチェック入りのbeyond3dの記事でR520は統合シェーダじゃないと言ってる
んだから後藤の壮大な勘違いでしょ。前も後藤はNVIDIAも統合シェーダかも、
とか言ってたしなんかずれてる。
G70はシェーダーを走らせないと無駄だという意味なんだよ
たとえば現行箱でもシェーダーバリバリのソフトなんて何がある?
後藤タンの肩をもつ訳じゃないが、ATIの型番のつけ方にも問題ある気がする
268 :
188:2005/07/08(金) 01:10:22 ID:HR4XMhnX
>LSダブルバッファによるレイテンシ隠蔽まで含めたら得意とも言えるし。
LSダブルバッファって256Kを半分に割るって事ですか?
そういえばDMAでのアクセスのオーバーヘッドってどんなもんなんでしょうね?
CELLをオープンソースにするって言うから、そのうち詳しい資料とか出るのかな。
>ショボイ、あまりにもショボ過ぎる。
プリンタなめたらいかんぜよ。
>>259 ATiがR600の直前のGPUを
どうやって売るつもりなのか興味が尽きない。
プリンタ馬鹿にしてる奴はプリンタ屋に謝れw
R500とR520じゃ 確かに同じ系統だと思われても仕方が無いよな・・
実際はどうなんだろ?
プリンタごときが馬鹿みたいに消費電力食うようになったら終わりだな
メモリはともかく高速なCPUなんて必要ないんだよ
統合シェーダは高解像度にも対応しなきゃならないPCじゃまだ早いのは同意。
HDTV解像度がまだ普及しきれていないコンシューマだからできるものだね。
>>271 R400(キャンセルされたSM3.0対応チップ)とR420も違うわけで。
>>268 >LSダブルバッファって256Kを半分に割るって事ですか?
最大、(256KB-プログラム)/2
バッファサイズはデータに対するSPEの処理量によって変わる。
60分の1秒で数十バイトしか処理できなければ、その倍しかいらん。
>>272 そう思う人は別にそんなプリンタを買わなきゃいいだけの話で。
高速CPU積んだ爆速プリンタが必要な人も世の中にはいるんだよ。
>>272 業務用のプリンターだと1000w余裕で超えてるんですが・・・
>>272 消費電力あたりのパフォーマンスに優れているのがCELL。
SPEが少ないバージョンを製品として使えるのもCELL。
>>272 レーザープリンタの電源は凶悪です。
↑製造ラインのPLCがリセットして焦った。
まぁ容量無視した俺が悪いのだがwww
500w強程度じゃ全然たりね。。orz
>>268 完全にストリーム的なシーケンシャルアクセスでいいなら、リングバッファでも良い
DMAはメインのスレッドの裏で動かして、必要な時に必要なデータがメモリ上に用意され
ている状態になりさえすれば、バッファ方式は何でも良いかと
>>274 だがR420とR520が分離シェーダで、R500が統合シェーダというのも
わかりにくいぞ・・
今のところ判明したCellの用途
SPE8個 WS、医療用画像処理機器
SPE7個 PS3
6個以下 HPの複合プリンタ
謎 トヨタの車載システム
4ヶ月前に仕様が公開されたばかりのチップなのに順調だな
R520はWGF2.0じゃないぞ
ちなみにWGF2.0はDirectX10のこと
R1050とかつけてくれれば誰がみても統合シェーダってわかるのにな。
>>280 >DMAはメインのスレッドの裏で動かして、必要な時に必要なデータがメモリ上に用意され
>ている状態になりさえすれば
こういう処理が演算性能に与える影響というのはどんなもんなんでしょ.
個々のSPE内でマルチスレッドってことですよね.
>280
しかもEEの例を見ればDMAにインテリジェントな自動転送機能をつけててもおかしくない。
287 :
188:2005/07/08(金) 01:26:18 ID:HR4XMhnX
>>275 >>280 なるほど、そうなるとSPEに載ってるDMAがキモなんですね。
XDRなら十分なメモリ帯域ありそうだし。
デバック時にSPEのメモリ見れないと大変そうだなぁ。
そこは東芝かIBMがかんばってくれるのかな。
>>284 R10(トー)50(ゴー)で統合シェーダか。こいつはいい。ハハハハハ。
おやすみなさい。
>285,287
EEではDMAで送るデータ列にパケット(処理単位)毎に転送するためのタグや次のデータ列へジャンプするためのリンク情報が埋め込めたはず。
それをDMAが解析して転送をコントロール。
箱もディスプレイリストにはそんな感じの昨日はあったけどDMAのようなハードウェアアシストがあるのかは知らない。
292 :
289:2005/07/08(金) 01:34:05 ID:oQ6uEJ6P
×昨日
○機能
あと、289は以前はこうだったから次もなんか効率化する手段は入っているんじゃないかという意味。
>>265 ビリヤードやレースゲームのような作用反作用処理で並列処理は有りなの?
>>293 並列処理するほどコストが大きくないと思われ
>>289 CellのEIBはデータ128bitあたり64bitものタグ情報を持ってるしね。
>>293 あり。
現実世界では全て同時に動いてるわけで
処理順が存在する方が、むしろ、おかしい。
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となりますね。
>>294 最近のシミュレーター要素が多いレースゲームはどうだろう
>>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??に
302 :
名無しさん必死だな:2005/07/08(金) 02:54:53 ID:oUj4ykTi
301の続きです。長くてすいません^^; これで最後です。
RSXのFP16 normalizeユニット と Xenosのpixel shader interpolation
calculationsユニットのどちらもフル稼働するようなケースはあまり想定
できませんが、通常のゲームアプリを動作させる場合にどちらがより多く
活用されそうかという予想ってつく人いらっしゃいますか??
ケースバイケースだとは思いますが・・。
(統合シェーダーの効率性とか帯域うんぬんとかは別の話として素のシェー
ダー性能に影響する部分なのでちょっと興味が)
>>299 normalizeというのなんか汎用ユニットじゃないように聞こえるけど、
やってる計算ってのは、
x=v1*h1+v2*h2+v3*h3+v4*h4
の4個の積演算と3個の和演算
3D計算ではもっとも頻出するSIMD演算ですよ
元のソースではnormってあったけど、normalizeじゃなくて
ベクトルのノルム計算という意味のほうが近いと思う。
normalizeにしたければ、x=v1*v1+v2*v2+v3*v3+v4*v4と引数を同じにすればよい。
>>301 >interpolation calculations
この英単語知らなかったから辞書引いたけど、補完みたいだね。
正体が線形補完なのか、もっと高度な補完なのかは知らないけど。
アルファブレンディングは線形補完。
何に使うのかは知らないけど、俺にはROS処理の一部だとしか思えない。
もしそうだとしたら固定機能の一部としてカウントするべきだよね。
>>303の補足
そもそも本当の意味でのnormalize(正規化)ってのは。
x=√(v1*v1+v2*v2+v3*v3+v4*v4)
v1/=x,v2/=x,v3/=x,v4/=x
の12浮動小数点演算が必要。
元のソースにはnormは7浮動小数点演算だと書かれていたから、
normalizeと仮定するとおかしいことになる
>>301 >たとえば、自分の車がクラッシュして他の車を巻き込む時
>他の車のクラッシュ挙動を先に処理出来るんですか?
移動計算→衝突判定→衝突応答は別々の処理。
並列処理するのは、それぞれの段階。
307 :
名無しさん必死だな:2005/07/08(金) 03:18:12 ID:oUj4ykTi
308 :
名無しさん必死だな:2005/07/08(金) 03:19:28 ID:oUj4ykTi
>>307 訂正
もう一度299出だしたソースを読み直してみたたのですが、
↓
もう一度299で出したソースを読み直してみたのですが、
>>304 間違いた。
アンチエイリアシングは線形補完
でも48個のshaderに全てついてると書いてあるよね。
正体は何だろう
>>307 ごめん、俺も元のソースのURLを失念した。
normで7fpと書かれてたからノルム計算だとばっかり思ってたら、
後藤さんがnormalizeとかいうのでアレ?っと
>移動計算→衝突判定→衝突応答は別々の処理。
>並列処理するのは、それぞれの段階。
だとすると、衝突判定→衝突応答が再帰的に起こる場合は、殆ど並列化出来ないという事?
312 :
sage:2005/07/08(金) 03:26:24 ID:oUj4ykTi
下げ方間違えましたm(_ _)m
>>303 それは唯の内積ですよね?
それならGeforce3でも
スループット1で出来ていたと思いますが。
(8bit固定小数点ですが)
G70では16bit浮動少数点内積の為に
専用演算器を設けているんですかね?
>>312 >やっぱりFP16 normalizeって書いてありますね。
本当だ。それだったら7fpというのが間違いなんだろうか…
でも正規化処理なんてそこまで出現頻度高くないぞ
でてきたとしてもsimd*2+aluで1clockでできそうだし
>>311 >衝突判定→衝突応答が再帰的に起こる場合は
細かく積分して、最初から起きにくくすんのよ。
後は、完全な剛体と考えないこと。
>>314 shaderプログラムでは内積の使用頻度がTOP
対してsimd unitを1つには内積以外にもいくつも命令を用意する必要がある。
それじゃあ内積だけを1ユニットにすれば、性能/ダイ面積の向上に繋がるのではという、
判断だと思った
>>316 なんか腑に落ちんな。
次世代機の話の筈だが。
正規化は使いまくりでは。3Dcでも使うっしょ。
使いまくりって、それは何と比較してかによる
少なくとも内積より使うってことはない
>>315 逆数平方根は流石に1クロックは無理かも。
SSEだとスループット4みたいですし。
これを6倍速ぐらいの専用ユニットにして
スループット1にしたりして。
>>321 いや1つのpixel shaderが、2つのshader unitを持ってる。
だからその図も後藤氏も正しい。
俺も寝ます
>>319 3Dcとかで使うという事であれば、図の上ではテクスチャ処理用プロセッサと
接続されているShader Unit1に搭載されている理由になりそうですね。
>>318 次世代機だと、どうなると思ってたの?
その処理概要を書いてみ。
ぶっちゃけ、厳密さより物理演算処理できるオブジェクト数が増えるほうが
視覚インパクトが大きいわけで(それも、100倍、1000倍の世界)
>>323 あ、その通りですね。
ボケてました。もう寝ます。
皆様おはようございます
>>306 処理的にはそうですね
1つ1つ処理して演算結果を出さなければ駄目
演算を並列化出来ても処理は並列化出来ない
>>316 なんかCellは物理演算の並列処理が〜って話しで
よくある作用反作用なビリヤード処理を思い出して書いてみた
この前のディープインパクトって凄いよな、計算通り宇宙の彼方で
衝突させたもんな、寝たら起きれ無そう・・どうしよう外が明るい
>>329 >演算を並列化出来ても処理は並列化出来ない
演算の並列化は、並列演算処理と言われてますよ。
あと、3つの処理を並列化する必要は最初からないです。
(複数のSPEが同時に動き続けることには変わりないので)
>よくある作用反作用なビリヤード処理を思い出して書いてみた
2体問題は教科書にも載ってますが
>衝突判定→衝突応答が再帰的に起こる場合は
これは多体問題にも発展するんで
よくある話じゃないです。
>>330 >あと、3つの処理を並列化する必要は最初からないです。
いや3つの処理を並列化って意味じゃなくて・・
現在の処理結果が次の挙動を決めるわけで
>2体問題は教科書にも載ってますが
簡単な例でビリヤード出しただけ
9ボールじゃなくて4096ボールでリアルタイム物理演算して画面で
動かすとか(車でも)
>>331 あぁ〜なんか、いいたとえじゃないな
落ちます
1フレームの間にそんなに複雑にぶつかる物なの?
流体シミュレーションとかのような粒度でもなくて、
所詮ビリヤードだのでしょ?
フレーム単位で駄目なら、
>>316にあるように細かく積分する事で対処できるだろうし。
細かく積分ってなんだ?
判定サイクルを細かくするってことかな
そっか時間ごとに移動距離が足されていくから積分って言うのか
RSXもリーク電流対策で苦労しているみたい。
110nmから90nmにシュリンクしただけでは駄目だったもよう。
110nm450MHzで発売か?
リーク電流よりその凄い情報がそんなに簡単にリーク出来ると思ってるお前のが凄い
そういえばRSXってなんでこんな時間かかってんだ?
要はG70だろ。
オブジェクトが多いときの衝突処理をオブジェクトごとにやってたら、演算順番で結果がかわる。
普通は>306のように処理を分けて並列化する。
精度上げるときは皆さん言っている通りdtを小さくする(1フレームに数回処理する)
PC用のGPUはCPUから直接VRAMを読み書き出来る設計になっていないからね、G70そのままというわけにはいかないでしょ。
単にFloxIOと繋ぐだけならともかくNUMAというのもネックになっているのでは?
あとは110nmの時点で90nmにシュリンクすることを考えて設計されていたのかというのも考えられなくもない。
G70とアーキティクチャを共有しつつ、設計は別、という話では。
つまり110→90nmシュリンクではなく90nmで新規の設計。
FlexIOに加えて省電力も入れているかもしれない。
GDDR3がATI主導の規格であることも考えと、
・ nVidiaがVRAMとしてXDR2を採用
・ 65nmプロセスでRSXもXDR2採用
・ Cell、RSXともにメモリはXDR2の1Gbit品 2個ずつに変更
というコストダウンの筋書もありうるか。ちょっと大変すぎるか。
プロセス変更もあるけどソレに加えてredwood対応のせいじゃないの?
いまだにPCI-E接続なんでしょ?
>>346 nVIDIAにしても、まだXDRのノウハウが蓄積されてないから、まずはRSXでFlexIO(SLI向け)と
Cellとの連携でXIOの実働データを参考にしてG80くらいからXDR2に対応するんじゃない?
XDR(2)への移行が技術的に正しくなきゃ、nVidiaだってやらんだろうけどね。
将来のGDDRでは、グラニュラリティと帯域速度の問題がどの程度生じるのかに
かかってる?
XDR2の価格次第でしょうな。マイクロスレッディングとかどのくらいRambunに払う事になるのか
わからんし。メモリーは高性能より、量産低価格そこそこ性能が求められるし。
GDDR系は、そろそろ等長配線がキツくなってきてないか?
帯域と容量を考えたら次世代GPUはXDR系しか選択肢は無さそうだと思うけど。
何かGDDR系でその辺の新技術とかあったっけ?
>>350 >Rambusの予測では、GDDRの動作周波数が8GHzを超えるのは2015年と予測されているが、
>XDR2では2007年で、2015年にはより高速な周波数を実現できる
例えXDR2採用して性能上がっても価格も上がる、ではハイエンド以外で戦えない。
XDR2に移行するにしてもチキンレースになるだろうね。
XDR2のライセンス料はそんなに高いのか?
メモリの「高い」はたいてい「数量でないから高い」で、
PS3ぐらいのボリュームがあると、それはなんとかなるらしいんだが。
>>354 いい製品かもしれないけど、元々導入考えてなければ
ハード設計やらバランスやら考え直しなわけで
メモリ帯域は重要だが最優先ではないことはRDがPCのメインストリームにならなかった事からも
わかる。価格が安くなる=大量生産なんだが、XDR2がどの程度の価格製品になるかは未知数。
RDRAMが流行らなかったのは、Intelの開発失敗が一番大きいような。
開発難度が高かったからね。でも、XDRではそれが逆転する事になるでしょ。
XDRの方が開発が楽だから、後は値段がどれ位の物になるか次第かと。
RDRAMに関しては当時としては実行性能がDDRと比較して別段高くなく
値段は飛びぬけて高かったので市場に受けいられなかったのでは。
RDRAMは高く、DDRは安く、DDRでもボトルネックにはあまりならなかったが、インテルはRDRAMで強行。
安いほうがいいという市場に負けたという流れだったっけ。
やっぱRDRAMは最初の頃のマザーがこけたのがなぁ
Intelで交換騒ぎあったのあれぐらいじゃね?
みんな、鬱陶しいラムバスに余計な金を払いたくなかったんだよ。
ゲームプログラムの並列化って、どういう流れになるんかね。
ミドルウェアやマルチスレッド化されたライブラリを使うといった曖昧なものでなく、出来ればアセンブラレベルまで降りて検証してみたいんだけど。
ちなみに研究目的なので、実用的でないとかいうのは無しの方向で。
なんだこの閉古鳥具合は?
だれかハードのこととか
プログラムのしやすさ比較とか
皆に分かるようにチンコに例えて説明してくれ
>>364 んなもん実物がないのにどんな話しろと?
それなら、コントローラーからの入力からになるかな。
これは1プレイヤーの場合は並列化出来ない、複数の場合もまあ、シングルスレッドだなLSにロードしたプログラムだけでSPE内で回す、XDRはアクセスしない。
>>364 360のGPUはお前のチンコみたいなもんだ。斬新な構造だが一度も使われて無いので未だ未知数
368 :
名無しさん必死だな:2005/07/08(金) 23:31:03 ID:gE8CBjDU
入力の後は、行動ルーチンか。
ここから物理演算とか入ってくるんだよな。
斬新な構造のおちんこってどんなのだろう。
I/Oから読み込んで結果をメモリに格納するだけの処理をSPEに割り当てたら
オーバーヘッドの方が多いだろう
たぶんPPEでサクっと終わらせると思われ
当たり判定座標の配列組むけどデーター量から見てLSには入りきらないよな。
やっぱりXDR読みにいくのか?
>>362 スッドレの粒度は関数レベルですよ。
>>372 LSに収まるよう細かく読んでいくしかないんじゃない?
PenIIIで32バイトごとに読み込むプリフェチみたいなイメージで。
小さいL1キャッシュと違って、LSは256KBあるからダブルバッファにしても
100KBぐらいははいけるだろう
当たり座標判定に使うだけのプログラムなら10Kにもならないだろうし
任天堂とMSは本気モード
SONYは夢見る乙女モード
分かってる?GKさんよ
vsスレでどうぞ。
379 :
もちつけ:2005/07/09(土) 00:47:58 ID:z2T1lyqa
,,...- ''''''' ''' ー---
キュルキュル _,,,,.../
彡 彡 彡 ,,,......-..:::':'::" _ノ
三三三三三三エエエ===ゝ:、:,:,:.:- ' "
(
\ ;
ヽ 、 _,,,,.......ノノ、,,,_
" '''--- ''''''"
省電力と各部の処理スピードバランスをとるために、部位によってクロックスピードが
違うだけ、クロック表示するソフトが対応出来てないので、変な表示になるようだ
半導体としては別に珍しい事じゃない、CPUだって部分的には倍速だったりするし
>>372 球同士の判定なら、位置と半径しかいらんし。
複雑な形状を判定する場合は、階層化して処理するんでしょ。
【レボリューション ハード情報(リーク)】
CPU:4コア (各2.5GHz)一次キャッシュは128KB、二次キャッシュは512KB
GPU:RN520×2コア(16MB混載)
メモリ:512MB共有
PPU:物理シミュレーション専用のプロセッサ(32MB)
・最も革命的な部分は「無料のオンラインシステム」
・性能的にはXbox360より遥かに上
・720p(プログレッシブ)と1080i(インターレース)HDTV規格に対応
・E3でのコントローラーの発表は未定
・コントローラーが感圧式とか無線
・DSより進化した「音声認識機能」
・無線による「DSとの連動」
ttp://www.unika.com.cn/article/article.php/2572 終わった・・・ 完全に衝を突かれたな・・・
インチキリークに必ず顔を出す物理演算チップってなんか根拠があるの?
社長さんがそんなことを匂わせたとかさ。
>>384 低クロックでも性能的に対抗できそうな可能性はそれだけだから。
でも、物理演算チップって3Dゲームを作る時にしか用が無いから
2Dゲームやその他の用途では全く使えない盲腸チップ。
CellのSPEや箱○GPUの統合シェーダのような柔軟性は無い。
というか物理演算チップを載せるコストを考えたら、
高クロックなCPUやGPUを載せる方がコストパフォーマンスが良い。
コスト重視路線の任天堂が、そんな無駄にコストのかかる物を載せる事は無い。
任天堂が物理演算で
ゲームが面白くなると一番思って無いでしょ
2Dで使えんという事は無いと思うが
オブジェクトを同一平面上に束縛すればいいだけやん?
>>389 そんな使い方するなら専用チップの意味が無いな。
高クロックの汎用チップのほうが良くなる。
> でも、物理演算チップって3Dゲームを作る時にしか用が無いから
> 2Dゲームやその他の用途では全く使えない盲腸チップ。
コレに対するレスだから汎用チップのがいいとかはおら知らね
>>391 「使えない」じゃなくて「使い物にならない」のほうが良かったかな?
>>387 SFCパイロットウイングスでは、わざわざDSP載せてたくらいだよ。
物理演算より座標変換の補助が目的だったのかもしれんけど。
基本的にゲームキューブの踏襲なんだろうけど
1T-SRAMはどれくらい大容量化が可能なんだろう
きっと768Mbitチップ×2とかだ
>>382みたいな妄想が出てくるって事は、
任天堂のレボのコンセプトって受け入れられてないんだな。
>>387 直感的な面白さを追及する上で、物理演算は非常に有効な手段。
むしろグラフィックの変わりに任天堂が次世代で一番力をいれそうな分野だと思っていた。
そういう意味では性能を重視しないと言われるレボは意外。
噂だとPPC970MPの1.6GHzだっけか?
それだけでもう俺のノーパソより3倍速いよ
VMXもふたつ載ってるし
他社がもっと凄いからコレで十分なんてとても言えないけど
次世代には違いないんじゃない
現時点で出てるレヴォの性能についての情報は例外なくデマ。なんで
未だにこのスレに繰り返し出てくるんだろうね
>>399 言わなくてもみんなわかってますから・・・。
物理演算で面白いゲーム・・・
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サイズディスク
>>400 妄想なのに今情報が出てる製品を少し
延長した程度の発想しか出来ないのが悲しい。
REGE FURY MAXX知ってるのかと
XGI Volari Duo V8 Ultra知ってるのかと。
>>405 ゾンビ数千体は無理でも、アヒルや足軽なら沢山動いているよ。
アヒルは、AIの載ってないただのオブジェクトな訳で
>>405 ウンウン、そうだといいですね( ´,_ゝ`)
なんで360はキャラ大量に出せて
PS3は360ほどキャラだせないってなってんの。なんか技術的証拠あんのかな。
>>405 どういう理屈でCellには無理なんだ?
プレイヤーに寄ってくる程度の処理だぞ。
ゾンビがテキパキ動くんだろ
どうでもいいが全部倒せるとかそれ以前に腐臭で死ねそうだな
>>405 VSスレでタコ殴りにされて逃げてきたのか?
ここでは発言に根拠がないとねぇ
SPEには、条件分岐のペナルティが大きいとか、コードサイズがLSで制限されるなどの
AIロジックの実行に不利と考えられる特性もあるが、
まあ現実のゲームではどーとでもなるであろう。
>>413 鼻栓
この言葉を送ろう
儲も鳴かずば撃たれまい
>>412 これから事業部立ち上げるのかヨ
兼任役職多いし。
つーか、数千体のゾンビにAI使ってるとは思えないんだけど…
個々に係数が設定されていて、徒党を組んでむかってくる奴もいれば一人で逃げてる
奴もいる、ぐらいのことは期待してもいいような気がする。ゲームとして面白いのは
どんなモデルだろう?
SPEでメインメモリからデータ読み込む時は
struct list {
void *data;
struct list *prev;
struct list *next;
};
みたいな自己参照構造体のデータは、データが連続してないし次のデータ読み込むまでその次のデータ読み込めないから厳しそうだね。
検索でよく使う2分木や8分木も自己参照構造体なんだけど、この辺はPPEで処理しろって事なのかな?
8分木って地形コリジョンによく使われるから、コリジョン検索はPPEの仕事になりそうだね。
Dead Risingや無双みたいなワラワラゲームは
AIがどうのこうのというよりも、単純にポリゴンをどれだけ出せるか
というのが勝負だと思うけど。そうなれば圧倒的にPS3のほうが得意なわけで。
>>422 listを配列で確保しておいて2分木を構築すれば記憶領域を連続化できる
けどな。メモリ割り当てを独自でやれば問題ないんでは?
>424
記憶領域を連続にできるものはlist使わないんじゃない?
listの旨味は挿入削除にコストかからない点だと思う。
木のサイズがLSに収まるなら、確かにその方法で良いと思うんだけど。
SPEでの処理するメンバだけ別に取り出して連続なデータ構造にするとか、
同時に複数枝探索してメインメモリアクセスのレイテンシを隠蔽するとか、
必要なら方法は生み出されるでしょう。
大雑把に言えば、SPEのための最適化はかかる手間は大きいが、得られる性能も大きい。
費用対効果で考えると割に合うのではないかな、と。
とりあえずプログラマ的には楽しそうだ。
ポインタアレイ渡すのも爆死コースだな
階層が深くなければ問題ねーや。欝だ死のう。今日はもうこねぇよ。
数千体のゾンビの処理なんかAIといっても物理演算と同レベルだろうな。
別に並列化できなくも無いよな。
ポインタの再帰的参照でディスクリートなメモリエリアにアクセスするのは、普通のCPUだってキャッシュ効率最悪になるし、必要ならSPEでも先読み処理しておけば処理速度は同じじゃない?
めんどくさいのは確かだけど自動処理関数も作れそうだしコンパイラしだいじゃないかな。
Listなんて一番対応が簡単なパターンだよ
単にListを順に処理するだけで良いなら、DMA用スレッドがメインの処理スレッドの裏で
*nextと*data読み取って、DMA発行するだけでいいんだから
Listを線形になら、メインスレッドが処理している部分よりも先行してDMA発行が可能
だから、完全にデータ転送レイテンシを隠蔽できるパターンだ
八分木のように分岐が必要な場合は、例えば最初に全体を2つに分割して、そのツリーを
交互に
判定で次に必要なデータ判明→DMA発行→別のツリーの判定→DMA発行
という順で処理すれば、隠蔽は可能だ
素人でもこのぐらい思いつくんだから、プロはもっといい方法思いつくだろうさ
>>425 未使用ノードの管理は大したコストじゃないよ。削除するノードを
未使用ノードのリストに繋ぐだけだから。インライン関数で
展開できる程度。
私も素人ですけど、NUMAなんて単に分離メモリの間を
ブリッジで繋いでるだけのものじゃないの?
並列処理じゃある程度効果はありそうだし便利だとも思うけど、
大抵GPU専用のローカルメモリがあるだろうから、
そんなに劇的な差にはならなさそうな気がします。
専門家の皆様どうなんでしょ
>432
>425は書き方悪いのかもしれないが、いいたいことはツリーの動的変更に自由度があるということでしょ?
継承してノードの大きさが変わっても、ノードの数が極端に増減してもListならメモリの再確保必要ないし。
>424に対する意見なんだし、配列化できるかって話では?
437 :
名無しさん必死だな:2005/07/09(土) 12:26:16 ID:DqE0caew
>>402 外付けHDDの次は、外付け電源ユニットかよ!!
それ以前にDVDケース3枚分の大きさとかはたんなるハッタリで終わらせる気か?
わらわらゲームはスマッシュ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.
>>434 そもそも、Listのノード順と配列のメモリ位置が同等なら、すでにListじゃないしww
ゾンビの例で言うと、もっと複雑なシーングラフなわけで、、。
シーンのトラバース順とメモリ配置に因果関係なんか作ってたら、正直やってらんねーよ。
トラバース順なんて、ちょっとした事でどんどん変化するものだし。
オイオイ、えらい事実が発覚しましたよw
>746 名前:名無しさん必死だな sage 投稿日:2005/07/09(土) 12:36:47 ID:FszcfBG8
>
>>737みたいなお子様は英語が読めないのかwww
>>XBOX360CPU=240Gflopsは最新開発機材に添付されていたスペックシートに書かれていた。
>>360CPUは最終的に、1coreあたり2命令/clockに増強されたそうだ(CellのPPEは1命令/2clockの2命令同時実行)
(ノ∀`)アチャー
>>426 既存のアルゴリズムが使えないのは職業プログラマ的には辛いだけなのですが・・・
>>443 既存アルゴリズムは使えるでしょ、SPEに合わせた改良が必要ってだけで
出来合いのルーチンをそのまま使う事しか出来ないような人は、もとからプログラマ
なんて向いてないと思われ
>442
ちょっと前に話題になっていた気がするが?
いや、いまだにこのネタVSスレで振りかざしてたからね。英語サイトに書かれてると説得力あるらしいw
450 :
434:2005/07/09(土) 13:21:07 ID:pXASzork
>440
えっと、なぜ私にレス?
>434は>432に対して論点がかみ合っていないって言うだけだよ。
ちなみに自分は>430だし、SPEでもListを配列的に連続した特定メモリエリアに押し込めて使う意味は無いと思ってる。
>>429 ワラワラゲームならキングダムアンダーファイアとか、
箱1(キャッシュ削ったP3)でも150体動いたから。
衝突モデル等よりさらに簡単なんじゃ。
>451
そうだよね、どっちも単位時間当たりの周囲の状況に対する応答を処理(内部の状態遷移含む)していくだけだし。
違いといえば、AIは場合(レベル)によっては複雑な評価関数を処理しなければならないのと、衝突判定なら単位時間を短くとらなきゃならない可能性があるって事かな。
>>446 未だにキャッシュサイズだとか転送とかを弄って自己満足してる連中もどうかと思うけどね。
そういうの好きな人種が多いのはわかるが、そもそもハードベンダがやればいい仕事だし。
もっとやらんといけない部分は沢山あると思うしね。海外に先越されてる。
実際、結局は大手でも使えない自作ライブラリは止めてミドルウェアにシフトしてる所多いし。
>>450 深い意味はないよ。
>>454 海外に先行されている分野は、それこそ自分で新しいアルゴリズムを考えなきゃ
ならない物が多いし、SPEの最適化で悩むようなプログラマは、そんなレベルに
無いと思われ・・・
アルゴリズムとデータ構造の最適化はプログラムの基本なんだし
456 :
名無しさん必死だな:2005/07/09(土) 14:01:50 ID:KccXX2ya
PS3の学習曲線はPS2よりはるかに悪いだろうな。
つまりPS3の性能を生かしたソフトはPS3末期にしか出てこない可能性が高いということだ。
FLOPSに偏重しすぎの使いづらいハードを押し付け
printfデバッグを強要してそれを使いづらいという開発者を無能呼ばわり。
それがSCE&GKクオリティ。
性能に違いはない
よくてGCと箱ぐらいの違い
この2機種もGCだけ30fpsとかいう
ソフトが皆無だった
所詮そんなもん
本日のID:ID:KccXX2ya
PPE+SPEx1ですらEEと同じくらい開発が難しいと言われてるのに、開発環境はPS2の時と同程度と、ソニー幹部自ら発言
本当64の時の任天堂よりも遥かにグダグダだよ
>>454 いや、その自己満足で出来る事が増えるならプログラマ以外も喜ぶから、自己満足じゃ無いと思うよ。
確かにハードベンダーがやってくれれば最高なんだけどね。
まさに夢の開発環境。
>>456 森へお帰り
cellのSPEを使ったソフトは当分出てこない
とかいうか出せない
実際の話、今の開発環境ではSPEはゲーム用途では背景動画の再生くらいにしか使えない
>>460 仕様が達成出来て終い。じゃないからね。
汎用性と保守が大事。言われるまでもないと思うが。
それはハードベンダがやんないと。
で、結局破棄してミドルウェアに頼るなら、最初からやらない方が良い。
コストの無駄。要するに自己満足。
>PPE+SPEx1ですらEEと同じくらい開発が難しいと言われてるのに
初耳だ。
今までの情報を一通り見てればそんな結論にはならないと思うが。
ていうかレスしちゃいけない人みたいだな。
つか、勘違いしてるのが多いね
別にSPEやPPEに最適化されたコード書かなくても
Cellはそれなりに動いてくれるわけですが
(コンパイラの問題もあるが)
>>463 自社ライブラリを持つ事は無駄なのか・・・
ミドルウェア製作会社ならともかく、ゲーム業界なんてハードが切り替われば過去の
資産なんて使い物にならなくなる&ゲーム以外の用途に使う事なんて考えずに
最適化するのがあたりまえの業界で、汎用性と保守性を第一に考える?
Cellを使ったサーバーやら、PCならともかく、ここはゲームハードテクノロジースレだよ?
ミドルウェアを持たなく失敗した例
まさにEEじゃないか
>>466 無駄とまでは言わないが、HAL層の最適化に注力してりゃいいって人はごく限られてると。
後、考え方が少し古くない?
続編や復刻が多い今日、汎用性と保守性は重要性上がってるでしょう。間違いなく。
>ここはゲームハードテクノロジースレだよ?
ハードに特化してるのか、、。ならソフト屋の出る幕はないな、、。
汎用コードでとりあえず組んでって、必要だったら最適化していくのが今の主流 かな?
ゲームエンジンのミドルウェアひとつ数十万ドル+何パーセントかのインセンティブとかいわれてるわけで、
そういうのが本当に必要な中小にとっては結構引くよな。
体力のある大手は自社開発して、経験ふくめて会社の資産にした方が後々も有利だし。
今のレトロゲー的に後々になって再販する商売も考えれば、いつまでも紐付きなのは怖い話でもあるしな。
てか塊魂とか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の再設計には4〜6週間かかる。nVIDIAのG70発売前
に、ATIはすでにR520の再設計を二度行っていたが、それ
でも、満足のいく結果が得られなかった。
(略)
R520の生産でこれだけトラブルを抱えてるのに、10月発売
が予定されているMSのXbox360用のチップ、R500を数百万
も一体どうやったら出荷することができるというのだろう?
両チップは同じ新しい90nmアーキテクチャを使っている。
専門家からも、R500の生産はムリポという意見が出てきたね。
Xbox360、まじ来年春以降に発売延期になりそうだ。
どこに句読点打ってるんだよ;
王様ビームあびながら転がしてくる...
>>471 FF11は少し知ってるんだが、、かなり泥臭い事やってる。
デザイナがやらんでも出来るような事を、手作業で。
それ聞いて、「なんだ、そんなもんか」と思ったけどな。
内のデザイナに同じ事要求したら、「ふざけんな!プログラムで何とか出来ないの?」て言われるような事。
GPUの開発遅延で、箱○の発売は来年延期がほぼ濃厚か。PS3より発売が
遅れたら、性能で劣る箱○はまじでやばいね。テクモとか、箱○に荷担
しているメーカーも会社も業績に影響が出るのは必至か。
ますますドリキャス臭が漂ってきた
>>474 まぁドロくさいことやらんとメモリにのらんでしょありゃ
通信制御、漢字変換、マップデータになに着てくるかわからんキャラ表示だかんね
この際R600を載せてくりゃいいのに
DVDもHDDVD
G70<>RSXと違って
R500<>R520は完全な別設計
目標性能以外に共通点はないよ
R500もR520も、同じTSMCの90nmプロセスで製造で、R520の開発が遅延して
いるのは、製造上の問題だから、R500もやばいでしょ。
RSXもR500もなんかパットしない。
X-GPUが一番よかったな
今でも画質の面で見劣りしない
いくらシェーダー性能が上がってもそれだけなんだよ
ちょっとプレームが安定するかとかいうその程度の
違い。5年先でも見劣りしないGPUをつくって欲しい。
>>479 R520で問題が生じているのはTSMC 90nmプロセスにおけるリーク電流だろ?
これはR500にも当然問題になるよ。R500にのみ何らかのリーク電流対策をしていないと駄目。
しかも、後藤なんかはR520も分離シェーダだと言ってるけどな。
もしそれが本当ならR500とR520は共通点が多い。
>>482 スマン。R520も統合シェーダの間違い。
>472
ソースは出せないけど、確実に内部状況知ってる人間にそこまで遅れているとは聞かなかったんだけどな。
R500とR520もeDRAM以外同じようなアーキテクチャだともいってた。
自分がだまされただけなのか?
ATIの中の人のインタビューでは、
XenosとR520は全く異なる、というわけではないって言ってたな。
仮にXenosとR520が同一アーキテクチャだとしても、
24パイプモノ(Xenos相当?)は通常のハイエンドGPU並に取れるらしいし、
クロックも500MHzと低いわけで、それほど大きな問題ではないような。
とっくに発表・販売されているはずのチップが遅れていることは確か。
PC向けチップがBF2特需に乗れていないのは痛いと思う。
>>484 ソースも出せないような情報を、どう信じろと?
通常のハイエンド品と同等なら、年300万程度の生産量はある訳だし、
歩留まりは時間がたつにつれ向上するので、問題はほとんどないだろう
>>484 内部事情知ってる人間が、流れたら痛手になるようなことを外部のものに話すわけないと思うが。
生産が遅れるならR500はボツにしそう
年300万じゃ 日米欧で発売3日で品切れだろw
それとも、XBOX360ではそれで十分なのかな?
んじゃ次スレのタイトルは
【ゲーム総合】次世代機テクノロジー11【スレ】
にでもするとしよう。
RSXもリーク電流の問題が・・・
急遽110nm版を投入し
クロックも落とす
494 :
484:2005/07/09(土) 16:20:40 ID:pXASzork
>487、他
ごめん、信じてもらいたいわけじゃないので適当に流して。
>>446 そうか、俺はプログラマには向いていなかったのかorz
既に俺の書いたコードも100万台以上市場に出ているけど怖いね。
でも、そういや最近は仕様しか書いてないや。
90nmでの高クロック製品の生産能力でいえば
実績のないソニー東芝FabのRSXの方が遥かに危険
>>496 ソースでも引っ張ってきてから言ってくれ
>>485 R520は32パイプで設計されてるらしいから24パイプの物は多く取れる。
けど、Xenosが初めから24パイプで設計されてたら多く取れないのでは…?
このスレ、ソース、ソースいう奴
ウザすぎ
ソニーはトランスメタの社員を大量に雇って、リーク電流対策に
LongRun2の実装をしてくるだろうから、R500よりは歩留まりいい
だろう。
このスレをよく読めばわかるけど、反論出来ない時の逃げの言葉ですから
>ソースを出せ
ネット上にすら根拠の無い噂話のほうがウザいです
R500はNECのUX6でつくられるのですよ
R520はすでに2度再設計して、32パイプはほとんど取れず、24パイプ
取れたらラッキー、大半は16パイプらしく、いま三度目の再設計で、
設計完了が一ヶ月から一ヶ月半だから、順調に行って8月中旬から9
月にテープアウト、それから製品発売まで二ヶ月として10〜11月
に店頭に並ぶ。
一方、R500は(もう少し構造が単純な)48パイプの統合シェーダー。
48パイプを数百万チップ確保するのは今年いっぱいは無理だろうね。
LR2は技術的にまだ載せらないんじゃないかとかいう話が昔あった気がするけど、
あれってeDRAMがくっついてる場合だっけ?
>R500はNECのUX6でつくられるのですよ
それは別ダイのeDRAM部分だけ。GPU本体はTSMC。
>>503 eDRAM+ロジック部分だけNECで、メインは台湾じゃなかったっけ?
>>504 Xenosは48パイプじゃなくて48シェーダーユニット
ピクセルシェーダー換算で24パイプ相当
ID:8lRWG0WRの発言などを読んでいると
いかにソースが大事か痛感いたしますw
>>505 SOIにLR2は乗せられ無いんじゃんかったっけ?
バルクCMOSのGPUだと乗せられるんじゃないか。
ソースのない英語の書き込みがなぜかこのスレではソースになってしまう件
UX6は工場ではありませよ
ソースなんて基本的に張られてもすぐどこにいったか
忘れるしいちいちアドレスまでも保存しているのか?
過去ログからも探すのもめんどくさい
RSXもTSMC?
>>504 レボは発売遅いんだから、それで別に大きな問題はないんじゃね?
>>516 すまん、R500のほうの話か。勘違いしたよ
>>515 SCEIだろ…
そういえば、PS2との互換をとるとき、GSの48MB/sという帯域が問題になりそうだけど、
そこはどうするんだろう?SBとかに4MBのeDRAM入れてあるのかな?
>>508 テクスチャユニットが16個なので16パイプ相当と
言った方がいいような気がする。
>>511 G70やRSXを事前にリークしたinquirerと、
便所の糞カキコ一緒にするなよ・・w
事前のリーク情報は実は中国経由なんだが
PC関連やその周辺のリークなら中国経由の情報はかなり確度が高い。
GPUやCPU、マザーボード関連のベンチなどは事後の情報とほとんど重なる。
情報セキュリティが甘くて重要情報ダダ漏れの裏返しではあるが。
>>524 そんな管理が甘いところで作っているRSXっていったい...。
>>525 台湾で作られている某ゲーム機の話だぞ
PS3の中の人が作れるのはSONY(Cell+RSX)とIBM(Cell)だけ
つーかRSXの”確かなリーク情報”なぞ例のパッケ写真以外に何もない
NECで製造する石の方の噂は全然伝わってこないが
こーゆー場合は順調にいってる証拠だな
>>468 続編はともかく、復刻を考えて効率を犠牲にし汎用性や保守性を優先するのは
無駄でしか無いとおもうが
復刻ならプログラムそのものではなく、ドキュメントやデータ、詳細仕様の方が
圧倒的に重要じゃないか?どうせコードはそのままじゃ使えないし、詳細なドキュメントと
元データがあれば移植プログラム自体は大して難しく無いだろう
まぁ、汎用性や保守性にしたって、全てをCellベッタリにする必要は無いのだから
高速化が必要な部分だけ対応するようにすれば、そんなに犠牲になるとも思えないんだが
>>527 まだ全然作ってないから、全然伝わってこない。
でも、本当にR500メイン部に設計変更が生じたら、
NEC側の製造にも影響はあるかも。
>>528 そういう話も踏まえた上で、
>ゲーム業界なんてハードが切り替われば過去の
資産なんて使い物にならなくなる
というのは違うんじゃ?と言ってる訳だよ。
ゲームエンジン側でカリカリの最適化が必要だとは思えないし、
エンジン部分と仕様は分かり易く分けるべきだし。
で、Cellアーキテクチャがどれだけ汎用性等を犠牲にするかは
ちょっと想像付かない。が、他よりかは依存性が強そう。
因みに、C++やスマートポインタは賛成派?反対派?俺は推進派。
とあるミドルウェアでは、恐ろしくクラスのネストが深い構成になってる。
でも、パフォーマンスは全然高いんだよね。
効率の面から言うと、コードでの最適化なんて、余程ハードよりな部分以外はナンセンスだし、
そういう風潮になって来てると思うんだが。君の周りではそうじゃない?
SPE向けに最適化されたライブラリが高い性能で動作すれば、
開発者は高水準のPPEコードを書くだけでよくなる、という考え方もあると思うけどね。
Cell依存のコードが局所化できない、ということはないので、要は書き方、使い方だと思うけど。
>>530 んー、それならカリカリの最適化が必要じゃない部分はPPEで処理すれば
いいんじゃないかな?CellはPPEまで含めてCellなのだし
で、SPEが活用できる部分はルーチン単位でSPEに投げるようにすれば、お手軽に
高速化可能 と
ちなみに、C++やスマートポインタは賛成派だよ、ただしスマートポインタにベッタリ
頼るぐらいなら別の言語使う派だけど
あと、クラスのネストって継承関係の事なら、きっちり設計されていれば、仮想関数を
大量に使わない限り、いくらネストしてもパフォーマンスへの影響は大した事無いのでは?
プログラミングの手間という効率から考えれば、ハードウェアベッタリの最適化をするのは
ナンセンスと言う事はわかるけど、ハード能力をしっかりと活用する事が望まれるゲーム
プログラミングではナンセンスとは思わないなぁ
そりゃ、楽に組めるに越した事は無いけどね
ヘッドルーム!
ヘッドルーム!
そういや昔Max Headroomってあったなぁ
>>532 >SPEが活用できる部分はルーチン単位でSPEに投げるようにすれば、お手軽に
高速化可能
もしそうできるのであれば、いいんだけど。
スクラッチパッドスタックのように、コードサイズがオーバーした途端暴走。とかは勘弁して欲しい。
>仮想関数を大量に使わない限り、いくらネストしてもパフォーマンスへの影響は大した事無いのでは?
そうだけど、うるさい人は際限なく言うしね。
>ハード能力をしっかりと活用する事が望まれるゲーム
プログラミングではナンセンスとは思わないなぁ
少なくとも、今の国内ゲームのレベルとハード能力から考えれば、
歪なコード書かないといけないようなケースは、そうはないかと。
次世代でどう変わるのかはわからないけど、時代の流れを逆流して欲しくは無いな。と。
>>530 ”ゲーム”と一括りにしているが
30フレームで良い2DのRPGと
60フィールド出力が求められる
3Dのスポーツやアクションでは
最適化の必要性は同じに語れないのでは?
>>535 >スクラッチパッドスタックのように、コードサイズがオーバーした途端暴走。とかは勘弁して欲しい。
さすがにフルのC,C++がサポートされている環境なのだから、そんな事は無いと思うけどね
IBMとSCEと東芝がどこまでプログラミング環境を整えるか次第だがIBMがCellブレード
サーバーを作ってるのだから、そんなに酷い環境と言う事は無いと思うよ、
もちろん個人的な推測(妄想)だけどね
さすがに、今PS3を触れるような人からのリークはありえないだろうし
>時代の流れを逆流して欲しくは無いな。と。
理想で言えばそうだけど、ある程度の最適化はどんな物にでも付き物だからねぇ
コンパイラが素晴らしく賢くなってくれれば、将来的にはそうなるのかもしれないけれど
TLPに向かいつつある現状でも、綺麗にスレッド分けしてくれるコンパイラなんて無い訳で
性能をそんなに求めないなら可能なんだろうけど、ゲームだとどうしても性能を追い求める
方向になっちゃうだろうし
>>536 >ハード能力をしっかりと活用する事が望まれるゲーム "の"プログラミングでは
と言う事で
2DRPGなんかでは、それこそSPE使わなくても十分すぎるほどのパワーがあるだろうし
>>537 なんか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という情報は気になる情報だけどね
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とか怪しい言い回しだな。
Cellはともかく、360 CPUがなぜすでにあるPPC970コアよりもシングルスレッド性能の低い
(同クロックで半分?)PPEを採用したのか、という疑問は確かにある。
>>544 サイズもでかいし、超爆熱になるからだろ。PPEx3でもやばいと言われてるんだから。
ピーク性能は捨てて、970コア+大容量L2キャッシュで勝負するのだ。
これでこそ開発者のためのハードウェアであろう。
まあ、それも寂しいか。
PPE 3個 って、むしろバランスが悪いかもね・・
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
>>540 元発言は、ゲームプログラムの実行を想定した上で丁寧に
分析してるのに(その中身は、このスレたCellスレで推測されてきたことに近い)
>XBOX360のCPUはピーク性能(カタログスペック)重視、Pen4、Athlon64クラスに及ばない実性能
>CellはSPEはあんまり使えない、DMAは遅い。LS小さすぎPPEが冴えない。
次元の低い要約すんなよ。要約だけ見て語る馬鹿もいるんだから。
>>549 すまん。
てかめちゃくちゃ長いし要約するの面倒くさかったんだ
と言うか感想みたいなもんだな
SPEのDMAは粒度が荒いので(128バイトだっけ?)、
普通にメインメモリの4バイトだけアクセスしたいときは「遅い」だろう。
MS-Intel間の交渉が不調に終わる
↓
IBMとの交渉に緊急に切り替え
↓
PPC970からゲーム機にいらない部分をカット&必要な機能を拡張したものをオーダー
↓
ゲーム機に不要な部分をカットしたものはPPEならあるが、拡張となると設計の時間が厳しい
↓
PPE*3のマルチコアで対応
こんな感じじゃね?
970コアはAppleとの絡みで、ゲーム機用の値段では売れないのかもしれんね。
>>552 PS3のGPUみたいな感じか。
cellGPUのパフォーマンスがあまりよろしくない
↓
Nvidiaとの交渉に緊急に切り替え
↓
cellと協調動作できる新しいGPUをオーダー
↓
6800の改良版のG70ならあるが、新設計となると設計の時間が厳しい
↓
G70クロックアップ版で対応
cellはGPUにしたらもっと性能でなかったよ
あの英文ではボロカスにいわれてるから
nvidiaはいい仕事したんだろ
実際、RSXは 要求性能を十二分に満たしてるだろう?
いい設計だよ。ゲーム製作者も少し安心したのでは。
最悪でも、どんな技術不足な会社でもPPEとRSXだけなら扱えるだろう。
PPEだけでもP4より高性能なんだろ?
これ前にガイシュツの記事じゃん
この記事を書いた奴は後藤以下の
前知識の持ち主だと書いた覚えがある
普通に考えて両者のパフォーマンスを詳細に知っててリークするやつなんていないだろ
>>557-558 たぶん誰も信じてないと思われ。
ネタが無いから遊んでるだけでしょう。俺もそうだし
そんなのはこのスレだって一緒だ
Attendうんたらとかいうに載った記事か?
一つだけ確かな事はID:AlTZ22OSがID:oycdOqFP以下のツマラン香具師だってことだ。
>>556 というかRSXは去年までのSCEの発言だと
時間あったらまた帯域ケチってeDRAM実装する気だったぽいしな。
結果的にコスト増でもロジック満載チップ積んだのはゲーマー的に御の字。
ってか普通に考えてCELLへぼでしょう?
RmUTmFy8 = oycdOqFP
か。いつもの人乙。 キミの脳内ではヘボなんだろうなぁw
MSって最初はインテルCPUで行こうとしてたの?
つ 凶
>>566 Intelの人が採算が合わないからと降りたとの記事を読んだことがある。
もしIntelチップだとしたらPenD乗せられる所だったろうから
ユーザーとしてはIntelが蹴ってくれて助かったんじゃない?
PS4では 最初からIBM・nVIDIAと協力してやってほしい。
572 :
名無しさん必死だな:2005/07/10(日) 03:17:48 ID:G7pKTaot
>>556 PPEだけだと確実にP4に負ける、VMX強化版の箱○PPEにさえも負ける。
クタの話だとRSXはNVIDIAと組むことの第一歩みたいなこと言ってたが。
IBMの副社長も日経のインタビューで、既にCellの第二世代の設計思想
についてソニーと議論を始めたとか言ってた。
実際は5年先のこの世界がどうなるかなんて全くわからんが。
>>572 箱○のPPCとCellのPPEってスペック的には
浮動小数点演算能力同じだけどVMXのどこらへんで差がついてるのかな?
レジスタの本数?
箱のVMXは32本から128本へレジスタ数が増えてるけど、
CELLのVMXは仕様が公開されてないから比べようもない。
ただ、スペック表から読み取れるVMXの演算性能自体は
どちらも同じ。
箱のVMXのレジスタが128本ってのがよくわからんのよ。
PowerPC ISAでは論理レジスタ32本じゃないとフォーマット的にまずいんでは?
たしかPowerPC970は物理的にはそれぞれ80本だったはずだから数自体はおかしくないと思うけど。
CELLのVMXは32本(IBMのサイトかどっかで見た記憶有り)、Xenonのは128本(リーク文書)。
360 CPUのVMXのレジスタ128本は公式に発表されてるんだけれども、
元々のVMXの命令フォーマットはレジスタ32本用だから、どう対応してるんだろうね? という話。
レジスタ指定を5bit→7bitに拡張したVMX命令なのか、register renamingで暗黙に使うのか。
ゲーム機用に命令セット拡張しちゃいかん事は無いし
レジスタ7bitにしちゃうとPowerPCの命令フォーマットから逸脱する上に、
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 それは仕方ないんじゃない。
RSXは殆ど情報でてないみたいだから、G70から想定しか出来ないし
発売時期の差から情報公開にも差はあるだろう。
>>582 後藤タンはCPUに関しては、Cellに入れ込んで
GPUに関してはXenosに入れ込んでるけど
ハードヲタ的には普通の姿と違うかな?
特に後藤たんの場合、過去記事からも
統合シェーダは心待ちにしてた感じだし。
Cell発表 (゚∀゚)=3 ムッハー → 直後にPentiumD発表 ('A`)
Xenos発表 (゚∀゚)=3 ムッハー → RSX発表 ('A`)
この記事のテンションの落差は読んでて笑えたw
>>582 高性能だから、と言う事じゃなくて
新技術として面白い方をより取り上げると言う事じゃないの?
>>582 後藤氏は新しい物好きだからな。
新技術にチャレンジとか、凝ったギミックとか、そういうのに萌えるんだよ。
製品の価値としては、既存の技術でもうまくまとめ上げた物のほうが
高い場合も多くて、彼もその価値はきちんと認めるんだけど、萌えない。
後藤氏が新製品のレビューとかしないのは、彼自身がそれをちゃんと認識しているから
かもしれない。
591 :
名無しさん必死だな:2005/07/10(日) 11:23:13 ID:YHcfE2Pu
後藤タンはPSよりだったんだけど、GPUが自分の想像してたのとまったく違ったのが相当ご立腹だったみたい。
最初のPS3スペック発表時、RSXこき下ろした後のXenosのマンセー振りがすごひ。
しかもどちらも想像で筆走らせてるありさま。
>>591 単に発売日が近くて積極的に情報をくれるATIと、煙に巻くようなことしか言わない
NVIDIAの余裕ある対応の違いでしょ
>>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部のクロックが
負荷に応じてそれぞれ動的に変わるらしい。
なんかまるで非同期クロックチップを思い出させる感じ。
Xenosのテクスチャーパイプって
テクスチャーフィルターとか行えるのですかね?
それともフェッチのみでSIMD演算機で行う?
CELLって本当に性能良いのかね・・
CELLにがんばって欲しいけど、海外あたりの分析見ると相当駄目っぽいので不安だなぁ
スレ違いを気にしてこっちにも書き込んだのは分かるが
反射的にただのマルチポストに見えてしまう2ちゃんねる脳の悲しさ
○はGI搭載
RSXのレジスタ数が十分なので、
シリーズパラレル型レジスタ生存グラフを用いた方法、
並列性を抽出・レジスタ数が多いても良い結果、ベクトルプロセッサはレジスタ数が非常に多い上に、
ベクトル演算であるが故にレジスタに必要なトランジスタ数がベクトル化倍だけ多いので、360より楽です。
599 :
名無しさん必死だな:2005/07/10(日) 12:25:02 ID:jWOjz1m5
Cellはベンチ結果がいいので、開発者が慣れたりライブラリが整備されればよく活きるだろう
CELL版GPUではなくRSXを採用した理由
単位データに対する演算量は少ないが
大量にデータを処理しなければならない場合、
やっぱりCELLでは不向きと判断したのではないか・・
>>595 そういう記事をあれこれ言うスレなんだから張ろうよ。
どれが既出かわからんけど…
あの長い英語の長文だろ
XBOX360のコアは実際のゲームでは
一個しか使われないだろとか書いてた記事ね。
あの記事はどうも…
ベンチってアテにならないんだよね、同一環境で同一ソフトで実行すれば
ある程度信頼性はあるんだろうけど、得て不得手やちょっとした事で数値
は変わるし。メーカーが提示した数字なんてはなっから問題外だよ
ゲームという特殊なアプリである以上、汎用性と効率性が図られているか、
あとはハード特性の情報開示がされるか否か。
性能良いです、でも特定の方法にした場合のみってハードは問題外だな
>>593 モバイルの技術を取り入れて
クロックを可変にすることで電力消費の低減、ヒートシンクの小型化
ファンの静音化に貢献した、みたいな内容ですね。
電力を6800から大幅ダウンしたと言うが、ここに秘密があるのだね。
クロックを550MHzまで上げても大丈夫なように出来てるようだ。
>Shader Clock:430MHz/Rop Clock:430MHz/Geometry Clock:470MHz
このGeometryってのは どこにあるの?
シェーダやROPとは違う場所にある演算機?
中身の使用状況を見ながらクロックを変えてるのかもね
同じゲームならオーバークロックしても中身の使い方は違わないから
各ユニット(Shader,Rop,Geometry)のクロック比は変わらない
停止したとたん基本の430にもどる
おもしろ〜
610 :
名無しさん必死だな:2005/07/10(日) 13:46:27 ID:DIQjAlBv
>>599 FFTベンチはCellに有利なベンチで汎用CPUのPen4を比較対称としている時点で
うさんくさいと思う、メモリ帯域が全然違うのにCellすげーとか言われても
ふーんって感じ。
せめて同じメモコン搭載しているAthlon64とやるべきじゃないかな。
定格で3.2G動作するAthlon64ってあったっけ?
>>610 別にメモリ帯域がいいのは問題ないだろw
ゲームと無関係なベンチしかやってないのが問題なんだろ。
せめてMSくらい機材貸して3DMark作ってもらってゲーム雑誌のDVDで
プログラム自体と録画ムービー配布してくれればいいのに。
>>610 Pen4のベンチもIntel純正コンパイラでカリカリに
チューンした結果ですよ。残念でしたw
>>メモリ帯域が全然違うのに
言いがかりも極まれり。
まさに、ボトルネックとなっているメモリ帯域を向上させたのがCellアーキテクチャなんだろ。
その内、「SPEを使うなんて卑怯だ。 PPEだけで勝負しろ!」とか言い出すんじゃないだろな?
>>611 AthlonFX2.8GHzと比較したらもっと差が縮まるんじゃね。
俺も遅いPen4とじゃぁ比較にならんのじゃないかと思う。
フェアにやるならPenM、Power5、Athlon64FX、Cell2.4GHz開発機で比べるべき、
>>614 そのうち同じUMAで勝負するべき!!
とかいいそうだな
ゲーム開発に関係無いベンチでいばっているこいつらっていったい...。
結論としては検索エンジンすら使えない子供はROMってなさいと言う事ですね
ゲーム開発に関係のあるベンチマークなんて、過去のゲーム機において出た事
あったっけ?
少なくとも公式になんらかのベンチマーク結果を発表したゲーム機なんて、無いと思うんだが
発表されるのはピーク演算能力と、ピーク表示可能ポリゴン数ぐらいだよなぁ・・・
実効性能の数値と言われる物も、どんなソフト使ったかすら解らない状態での
公式発表では無い曖昧な数字しか見たことないぞ
つまりFFTベンチはソースにはなりえないって事でFA?
そんなマイナーなベンチでいばられても・・・
FFTベンチってのは
画像や動画、音声などの圧縮や解凍といった処理の際につかわれる。
CELL搭載のエンコシステム出して・・
あからさまな単発IDラッシュワロスwww
実際にゲーム機に搭載されるCPUでの実効性能を、公式なベンチマークとして発表した
非常に有益な情報でFA
他のCPUの理論ピーク性能と実行性能の比と、Cellの場合の比を比べると面白いかもね
意味ないベンチみたいだね
その他のベンチなら負けないぞっ、
と言いたいのだろう。
よろしい。 自分たちに有利なベンチを探してきなさい。
待ってるよ
ベンチさえ出せないCPUよりはいいと思うけどね。
それと、メモリ帯域を理由にCellが駄目だと言ってた馬鹿がいたけど、
128MBのメモリアクセスがあっても実効性能が十分出たという証明になったし。
>>623 フーリエ変換なんかゲームじゃムービーぐらいにしか使わないからなぁ。
Cell信者唯一の心の拠り所が否定されてしまいました(w
さあ、どうする?
マイナーなベンチって・・・
FFTはHPCチャレンジベンチでも性能評価項目に
入ってるほど重要な計算ですよ。
おそらくいま行われているであろうUE3エンジンのCell最適化が一つの試金石か。
それがどの程度大変で、どの程度の効果があるのかわかれば、
PS3の将来がどっちなのかも見えてくるだろう。
>フーリエ変換なんかゲームじゃムービーぐらいにしか使わないからなぁ。
なるほど
やはりベンチに意味なかったか
>>633 それでもゲームには関係無い、さあどうする?
>>632 フーリエ変換が実際にどういう演算をしているか知った上でそんな事言ってるなら
オメデタイ人だ・・・ 積和演算って知ってる?
>>616 つーか、Cellの性能を示すために同クロックのPen4を引っ張り出した訳だし。
>フェアにやるなら
という前提に意味がなさそうな。
>>637 その前にフーリエ変換が実際ゲームにどういう役に立つのか答えなさい(w
>>636 それは浮動小数点演算がゲームには関係ないといってるのと
同じだぞ。
ID:yysRcZ4O
いつもの人?
君にはVSスレの方がいいと思うけどな。
ベンチの中身を理解できない奴は、背伸びしてここに来ても仕方ないよ。
すぐにVSスレ化するのな('A`)
それから、Cellの性能否定材料として使われやすい、LSに乗り切らない量のデータを
扱った例として、性能低下があの程度で済んでいるという意味でも非常に有益な情報
なのに・・・
まあこの板にあるスレである以上仕方ないところ。
>>641 「ソースを出せ」「VSスレへ行け」はCell信者の敗北宣言。
定期的に来るのはお仕事だからなのかね
>>645 妄想で語ってれば、どんなハードウェアでも負けないで済むもんねw
アンチならソニーらしいハッタリって納得しとけば、いらぬ恥をかかないで済んだの
に、VSスレにカエレ。
アンチCellの人は
ここで頑張れば頑張るほど
現実を思い知らされることになってるのに…
けなげと言うか…
いったろ?cellはItanium2だって
分散コンピューティングが一番似合っている
>>645 ソース出せ、ってのは当たり前じゃないのか?
http://ascii24.com/news/i/topi/article/2004/09/06/651405-000.html 波の表現には、Gerstner(ガースナー)波形計算とFFT
(高速フーリエ変換)の統計モデルがあるが、ここではGerstner波形
を採用している。その理由として芦田氏は、FFTの統計モデルでは、
リアルな波を表現できる半面、計算(プリレンダリング)に時間が
かかること、同じ波が繰り返し出てきてしまうことなどを挙げた。
ただ、リアルタイムレンダリングの必要がない映画などではFFT
の統計モデルが使われており、同じ波の繰り返しはカメラ位置
を切り替えることなどでカバーしていることも説明した。
CELLであれば、リアルな水面波シミュレーションが実現できそう
ですね。まさにプリレンダと同じ手法が使えるんです。
SPEがFFTのような連続データの処理に好適なのはさもありなんなのだが、
個人的には、(メモリ上で連続していない)linked listが
実用的な速度で扱えるのかどうかに興味がある。
今のところ、アンチCell派には耳の痛い情報ばかりだな
いや、定量的に、どの手法でどの程度のコードの複雑化と速度悪化(対PPE比で)が
あるのかな、と。
>>657 そのスレッドは実際にコード書いて検証した話じゃないんで、
いわばこのスレと同レベルというか…
XBOX360のCPUがXBOXのCPUの2倍程度の実効性能しか出ないと書いてある時点で・・・
2倍程度はないな
そんならkameoの群集シーンなんかできるわけないはずで
あれでさえまだαキットらしいから
そういえば、CellのPPEのベンチ情報ってあったっけ。
同クロック換算のG5よりだいぶ悪いのではないかと思うのだが。
問題は開発が楽かどうかじゃね
性能高かろうが低かろうがソフトレベルじゃたいした差はない
クロックが4.3倍になってるのに、実性能が二倍だったら最悪だわな。
ありえるとしたら、XBOXCPUの理論性値の二倍の実性能って事かな
PPE単体は見たこと無いな
色々な資料から推測するに、XBOX360 CPUのコアに近いようだが、性能についての
記述は見たこと無いな
性能が高ければ、富豪的プログラミングのような手法も選択できるようになる。
PPE単体の性能を考えて 何ほどの意味があるのかな?
全体で1つのCPUなのに。 一体何と比較するのか。
まさか本当にSPEを使わずにゲームを作るつもりか。
>>670 2Dアドベンチャーゲームならそれでも十分だろうな、いわゆるギャルゲーの類とか
おそらくほぼ同じコアであろう360 CPUのシングルスレッド性能が類推できる。
「XBOXのCPUの2倍程度の実効性能しか出ない」説は、おそらくシングルスレッドで
VMXを使わないコードで比較した時の話だろう。
PPEの割り切り方を考えると、これもありうる数字じゃないかと思っているのだが…
開発が楽〜って言ってる奴は何が言いたいんだ?
企業からすれば、一番売れてるハードに開発投資するに決まってるだろ
開発者が楽〜で開発投資先が決まるとでも思ってるのかね
cell信者言い訳見苦しい
開発コストが下げられるなら損益分岐点も下がるわけで、
特にまだ両者ともシェア0%の状態では、開発の容易さは機種選定の上でそれなりに
重要なファクターでしょう。
たとえばもしWindows版からのベタ移植が容易じゃなかったら、□は360用のFF11を出さない
だろうと思う。
そうやって同発ソフトが決まり、ローンチが成功したり失敗したりして普及台数が
定まっていくわけで、開発の容易さというのは(決定打ではなくとも)
まるきり無駄というわけではないのでは。
>>672 じゃぁ、CellのPPEはP3の2倍程度の実効性能ってこと?
開発コストの占める割合の中で、プログラミングの容易さはさほど影響が無いよ。
しかも、Windowsのベタ移植って言っても、Windowsでゲームを作ってて、
ゲーム機にそのまま移植できるような弾を持ってるメーカーは少数派でしょ。
>>674 フーリエ変換がゲームに役立つ例を挙げら無かった時点で敗北しているわけだが(w
以後、FFTベンチはソースにならないという方向で。
向こうはPCとコンシューマ機にマルチで出してる所多いのかな?
日本は殆どないよねコンシューマが先でPC移植とかカプコンがやってるな
プログラミングの容易は影響ありまくり
まず変な延期が少なくなる、最適化も容易
GT4の製作現場TVに出てたけど苦しそうだったな
バグ→延期のオンパレード
日本のPCゲーの中心はエロゲですから
CS機とマルチができない
世界にはPCとコンソール同発してるゲームは山ほどある。
日本メーカーでもコナミはMGSやSHなどをPC向けにも移植してる。
まあ日本では売られてないが。
GT4クラスだと、開発が難しいのもさることながらPS2では性能たりなくて、ギリギリまで性能搾り出すハメになってるから難航したんだろね。
>>678 不利なソースは参考にしないのに、有利な情報は噂話レベルでもソースにする
オメデタイ人達ですね
市場は開発者が決めてるとでも思ってるのか
勘違いもいいところだな
スレ違いだから信者隔離VSスレへどうぞ
>>678 >>652 >>682 PCで出す場合、OpenGLという手段もあるわけで。
特にMacでもゲームを出すような場合にはOpenGLしかない。
MSもHaloのMac版をOpenGLで書いてたしね。
市場は開発者の決断にかかってるのもたしか
大手に関しては(開発費数億かけるところ)開発が容易か容易でないかは、あまり関係ないだろうな
だけど小さいメーカーだと、かなり気になるところだと思う。
現状PS2が一人勝ちだけど、開発環境がいいとでも?
開発環境で市場をみるなら、箱が勝ってるはずですね
あれ?w
そういやあ箱とレボの開発環境どっちがいいとかって話聞かないねえ
>>686 PCでOpenGLは絶滅危惧種なんだよ。
Haloはホントに特別な例で、これは元々Mac向けに開発されていたのを
MSに買収されてXBOXタイトルに加えられてしまった。
OpenGLを積極的に使うのってCarmackくらいなもので、
ここ最近OpenGLだったタイトルなんてD3くらいしか知らない。
LinuxやMac向けに後に移植する際OpenGL使うのはどこでも普通だね。
確かGCってOpenGL使ってたよなあ。
レボも引き続きOpenGL使えるって事だな。
このスレの
>>191以降でも既出の話題を蒸し返しですか
191 名前:名無しさん必死だな[sage] 投稿日:2005/07/07(木) 23:36:15 ID:fsrn1LfO
>>188 >FFTベンチやMPEG2同時48本再生がうれしい理由って何?
つまり、浮動小数点演算が必要なストリーム並列処理が大得意と。
頂点演算、光源計算、物理演算、音声合成、etc
ゲームプログラムだと恩恵有りまくりですよ。
>>693 UnrealもOpenGL対応してるけどね
だからLinux版が出せる
>>678なんか見てると、アンチは
FFTベンチの結果を必死に
ないものにしたがってるんだなあ
というのが分かるw
よっぽど衝撃的だったのかねえ?
>>632 フーリエ変換は画像・音声信号の周波数解析をするための「積和演算」の一種、一内容
最近のゲームにおける 3Dの座標変換・ベクトル演算は この「積和演算」を繰り返し行うことで実行される
頂点演算やピクセル処理を行う GPUのシェーダユニットのメインは このための「積和演算器」
シェーダ性能を高める とは、シェーダユニットを並列化し 「積和演算機能」を高めること
実際、G70ではGF6800に比べて ピクセルシェーダ内の積和演算器の数が 16個 → 48個 と 3倍に増やされてる
何故こんなことをしたかと言うと、nVIDIAが代表的な1300のゲームのシェーダ処理を研究した結果
積和演算機能を強化すれば ゲームの性能が最も上がりやすいと判断したから
つまり、FFT(高速フーリエ変換)が速い → 積和演算が速い → ゲームにおける3D処理が速い
と、まさにゲーム性能に直結している
SPEは、GPUでいう「シェーダユニット」のようなものだと考えてくれ
そして、例のFFTの結果は
”Cellは (ゲーム性能に直結する)積和演算の(カタログ値だけでなく)「実効性能」が高い”、という意味なのだ
よくわからんけどなんか高評価っぽいから
ゲームにゃ関係ねーつって叩いとけ、が正解じゃね
ソニーを叩く事だけが生き甲斐の人が多いんですよ
Cellに文句つけてる箱○信者はどうしようもねえな。
箱○CPUはベンチ結果公表してるのかと。
同じベンチやったら、Cellにぶっちぎりで負けるから公表できませんよね。
せめて、信者曰く得意な分野でのベンチ結果ってのを見たいね。
>>701 同じベンチやっても
それがゲームに何の関係が?つって
よく調べもせず噛み付いて来るんだろうけどな
>>657に書かれてるみたいな
「いくら演算速くても、SPEでまともな処理できるか」的意見も
それなりに理解できるけどね。たとえばC++オブジェクトの1メンバに
SPEのコードからアクセスしたい、というと、かなり面倒なのではないか。
360のような対称型マルチスレッドなら何の造作もないことなのに。
箱○はPPEそのまんじゃないか
XBOXとPS2の時も比較ベンチはあったが
PPEをあまり貶すと、xenonが自爆するよw
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.75x1.5x1.6=4.2GFlops
同条件だと多分これ以下になると思われる
これはXBOX360側にありえないほど有利な状況を仮定した上での結果だけど、それでも
10倍程度の差が付く事になる
>>698 G70はシェーダー演算器の塊みたいなものだと思うが、
G70だけで追いつかず、Cellにまで回ってくることがあるのか疑問。
ゲームにおけるCellの役割は3D処理では無く、
むしろ非グラフィック分野、AIや物理計算などが主だろう。
続き
115.2 GFlopsと発表されている性能からすると、最大でピーク性能の20.8%、Cellと同条件
に近いときは3.6%しかで無い事となる
まぁ、実際のゲームでこのままの差が付くかどうかは別の話だが、Cellがあの条件で叩き出した
20%、41GFlopsという数字がどれだけ凄いかという事を示すには十分だろう
こんな試算も過去にされてたな
PPEはGCみればいいと思うが
>>694 GCはOpenGLは使えませんけど。
リファレンスにOpenGLとの比較がたまに出るくらい。
>>707 AIは良く知らないが、物理演算は行列演算が基本
積和演算は行列演算を高速に行う為に使われるものなんだよね
>>711 そうなの?どっかでGLライクだかなんだかな話を聞いたけど、違うのか。
ちなみにEpic Gamesの副社長はPhysX(NovodeX)と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とはかなり違う。
>>678 無知な人が恥も外聞もなしにわめいたお陰で、
素人にもCellの凄さがわかりやすい良スレになった。
HD DVDの山田さんみたいな物かな
>>707 今後のGPUの方向性として
・動画再生支援の強化
・物理演算機能の強化
が挙げられる。
実はこれを先取りしたのがまさに Cell
物理演算で重要な演算は
・力学計算
・衝突判定
この内、衝突判定は話題の”PhysXチップ”などのような
物理演算専用チップにはかなわないかもしれないが、
力学演算には Cellの膨大なパワーがいかん無く発揮されるだろう。
少なくとも、xenonチップには 物理演算をブーストするような
機能は何も付いていないのではないか。
コンパイラがPPE向け最適化で命令を並べかえれば、
in-order命令実行のインパクトは小さい? そんなものかね。
そう言えばPPC970だとRISC命令のはずのPPC命令セットですら、
もはや複雑過ぎるようで、わざわざシンプルな内部命令に砕いて実行すると言う
今のx86系CPUみたいなことやってて、もう純粋なRISCとは言い難い現状。
PPC命令セットとの互換ですら、今となっては性能的なな足枷と言うことか。
だからSPEは、200以下に絞り込んだのかもな。
100個以下、じゃなかった? >命令セット
老練のIBMアーキテクタが それで足りるとか言って。
構造もシンプルに、命令セットもシンプルに。
いいのではないか。
↓この日経エレの記事な
次のミーティングはオースティン。SCE鈴置が会議室に入ると、
IBMの席に初老のエンジニアが。30、40代が多い中、一際目立つ。
時折考え込みながら、一心不乱にペンを走らせている。
「あれは誰だろう?」
IBMが案を提示する順番に。すると、その初老が立ち上がる。
「ともかくコンパイラが扱いやすい命令セットにすべき。200では
多すぎる。私の試算では100個以下で事足りる」
先ほどまでペンを走らせていた紙を掲げながら説明をする。
そこには機械語で記述した手書きのサンプルプログラムが。
その鬼気迫る姿に誰もが圧倒した。
更に続く・・・
いや、TLPを高めるからといってILPを捨てるのはあんまり良いことではないけれど。
トランジスタ数やチップ開発コストとのトレードオフでやむをえず、というか。
実際、Cellも第2世代でPPEを2命令同時発行に改善した。
1命令ではあんまりだと思ったんだろう。
続き
それもそのはず、APU命令セットの定義はそのエンジニアが
ソフト技術者としてのキャリアの締めくくりとして選んだ仕事
だったのだ。彼の名はMarty Hopkins。世界初のRISC型
CPU「IBM801」の開発者の一人であり、その道では知る人ぞ
知る人物。老練技術者の言説に技術者達の目から鱗が。
コンパイラを知り尽くすMartyのアドバイスを若手技術者
がシミュレーションで検証する。
その後も、コンパイラの最適化作業を助けるためにアドレッシング
モードを追加するなど貴重な助言を残した。そして、APUの
命令セットがほぼ固まったのを見届けて、30年勤務したIBMを
後にした。
RISCの産みの親の一人であるIBMのエンジニアが
最後の仕事であるCellの設計で自分の美学を込めて現場を去ったということか
トランジスタ、多いよな。>Cell
まぁSRAMに2.5MBも取られてるのだが・・
面積もRSXより大きくなるだろうね。
>>727 あれ?Cellが2億5000万くらいで、RSXは3億越えだったような?
プレスコはキャッシュ2Mにしてもあのザマ
トランジスタの多さって意味あるのか?
どちらもトランジスタ数多いけど、それでもGSよりはダイサイズが小さくなっている。
とりあえずG70は問題なく出荷してるね。
いつぞやのnVidiaとは大違い。彼らは失敗から学習する組織なんだろうか。
>>729 うん。
Cell(DD2)が 2億5000万トランジスタ・ 235mm~2、
RSXが3億トランジスタ弱・ 推定 200〜240mm~2程度じゃないかな。
正確にはわからんけど・・
どっちも90nmプロセス。
トランジスタ数と面積は必ずしも一致しない。
>>733 スマソ、
>>657の記事には半分とは書いてなかった。
3コアで、プレスコ1コアより小さいから云々て感じだった。
>>720 Xbox360の開発キットにはリアクターという物理演算エンジンがついているよ、UE3にもね。
物理演算はソフトでの効率のほうが性能に直結するからミドルウェアの性能次第。
特にゲームの場合、ポリゴンのカリングと同じでばか正直に力学計算なんかやってたら使い物にならないよ。
そんな速攻で論破されることをわざわざ書きに来なくても、と思った。
>>735 いやさ・・
「Cellは動画のエンコしか使えない」 と誰かが言うから
「3Dゲームの演算にも強いよ」 っつったら、
「GPU的な機能は足りてるよ。 Cellは物理演算は出来ないのか?」 っつうから、
「いや、それも得意だよ。 Cellの得意分野だ」 って答えただけでさ・・
チップ本体に物理演算をブーストするような機能が付いてないのに、
ミドルウェアで付いてるから心配無い、むしろCellで馬鹿正直にリアルタイム演算するのは無駄、
なんて言われても・・・
「ああそうですか、頑張ってください」、としか言いようがない。
>>737 物理エンジンを「チップ」だと思ってるに一票。
>>738 成程・・
例えば 「NovodeXエンジン」と「PhysXチップ」を混同してるのか・・
同じ処理でも 専用チップを積めば60fpsでるのが、
P4とかその手のCPUだけで行うと 1〜2fpsしか出ないってこともあるぞ。
物理演算アクセラレーション機能は実装してたほうがいい。
せっかくのミドルウェアが無意味になってしまう。
Cellのソフト環境の充実度はどんなもんかねぇ。
ちなみにDirectXのHLSLコンパイラは
とてもよく出来てると思うんだが
いまだにauto変数にconstすら付けられない。
もう2年以上歴史があるはずなのだが。
IBMだから大丈夫はちょっと楽観的すぎると思うのだが・・。
物理演算が強化されるとバーチャの人形くささも直る?
次世代にはそこら辺期待したいけど、正直に力学計算しなくても無問題なの?
それ系のソフトを実行してみればわかると思うけど、
単純なポリゴンモデルでも 気持ち悪いくらいクネクネ動くぞ。
物理的に演算しながら・・
綺麗なテクスチャ張ったキャラで動かしたら
印象は全く違うゲームのように見えるだろう。
Cellは そのあたりが楽しみ。
>>741 次世代機はより正確な物理演算が行えるというより
とりあえず物理演算が組み込めるようになったと言う方が
近いかと。
本当に現実と同じ物理演算だけでバーチャ作ったら
動きが遅くてHPゲージの意味の無いものになりそうだ。
もちろん スパコンじゃないんだから、
演算能力の許す範囲の物理演算だね
ま、ゲーム程度なら そこそこ見れるものができるかも
現実じゃないからゲームは楽しいという部分もあるしね。
別にリアルな殴り合いを求めてるわけじゃないし
格闘ゲームに物理演算のような確率への依存性が高い要素を導入するのは微妙なような・・・。
そういう要素をもった格ゲーもありと言えばありなんだが、バーチャのように歴史が
あるソフトは下手に革新的な要素を盛り込めないから難しいところ。
格闘ゲームのスレ見たらわかるけど「この技入ったら硬直何フレでXX技確定」なんて世界に
物理演算は求められていない気がするな。
次世代機の格ゲーヲタの間ではフレーム数じゃなくて
物理演算の働きを頭の中で読みながら戦うようになる
とかいう事になるのかもしれない
俺にもそれがどういうことだかよくわからんが格ゲーヲタの能力は凄いからな
遊びじゃない
箱1に物理演算を取り入れた格闘超人ってのがあったと思うがあれはどう評価されてたのかな?
即回収&存在抹消された事以外知らないんだが、ゲームシステム的にどうだったのかと。
単に物理演算を入れるのではなくて、物理演算を使った+αがなければ
ゲームとしての面白さはないと思う
格ゲーに物理演算つかうなら背景と乳揺れぐらいだろ。
3D格ゲーに細かく物理演算使ったら
コンボなんか出来ないと思うが
>>754 だな。
軽くはじいただけで人が高々と浮いてしまう時点で物理法則に反してる。
でもリアルにすると空中コンボそのものが成立しなくなって面白くなくなってしまう。
格闘ゲームを面白くするためにはむしろシステム面の改良の方が効果が大きいと思うね。
ガードすると固まってしまう制限とか、投げ失敗モーションが明らかに不自然とか、
起き上がりの攻防が単調とか。そこらへんの改良の方が面白さを増すと予想。
物理演算するからニュートン力学に沿った動きしかできなくなるってわけでもないだろ。
格ゲーなんてもはやキャラゲーなんだけどな。と
今日スターウォーズEP3のゲーム買ってしまった俺が言ってみるw
1対1の限定状況だとあんま効果はない。三国無双みたいなやつのほうが効果的だろう。
RTSとかね。
出来る出来ないと使う使わないは別問題だし。ゲームデザインに関してはまた別の
スレがふさわしいと思うが?
格ゲーに物理エンジンの例ならすでにEAがFight Nightで示してる。
スローモーションでKOシーンが妙にリアルなバーチャとかどうよ。
例えばミドルキックをガードした場合、本当に物理演算を重視するなら
足の長さの分だけキャラが後ろに後退しないといけないんだよね。
でも現状は、至近距離でミドルキックをガードしても少ししか後退しない。
足がキャラののめり込んじゃってるのが現状。
これをリアルにするだけでもゲーム性はかなり変わるはず。
>>756 ゲームに求められている物理演算は厳密に力学計算しなくてもいいような気がするな。
そうすると、物理演算をブーストする機能は特別必要じゃなくてフェイクの
ほうが処理も速くてゲーム向きだという事になる。
762 :
猫ファイト:2005/07/10(日) 19:16:53 ID:ecEOjoLP
「物理演算」で検索するとおもしろいのがあるな。
winnyの作者も格ゲーと物理演算との関係に注目していたようだ。
763 :
760:2005/07/10(日) 19:17:19 ID:9fhNQisk
>足がキャラののめり込んじゃってるのが現状。
↓
足がキャラにのめり込んじゃってるのが現状。
>>761 物理演算が何のために必要か、というとつまりはリアルさの向上だろ。
でも格闘ゲームの場合、現状キャラの動きやシステム面の方がリアルさを阻害してるわけさ。
まず改良すべきはこちらでしょう。物理演算よりモーションの改良の方がリアルさを増す。
蹴る瞬間に足の質量が500Kgに増加して、その衝突を物理演算で厳密に計算したら
ゲーム的面白さが出ないかな。
むしろゲームに物理エンジンの面白さは現実ではありえない
法則を構築できるという部分にもあるから、
どこかにフェイクなり漫画的強調を入れるのは必須かもしれない。
まあリアルだから面白さが増すとは限らないからね。
ゲームとしてのフェイクはどこかに必要。
個人的には、格闘ゲームの場合のフェイクは「キャラのパワー」だけでよいと思う。
不自然なモーションは極力配慮すべき。
767 :
766:2005/07/10(日) 19:24:50 ID:9fhNQisk
×不自然なモーションは極力配慮すべき。→○不自然なモーションは極力排除すべき。
今日はキー入力ミスが多い・・・
ビリヤードとか重力をシュミレートした落ちゲーとかなら物理演算がゲームを
面白くするかもしれないが、既存のゲームは物理学を無視したところに面白さが
あるのでフレームシティみたいに撃ったドラム缶がリアルにころがるとかいう
のは意味が無いとおもうな。
こういうのは任天堂の得意分野なんだがSCEは当たり前の使い方しかしないからなぁ。
格闘の人対人の処理は物理エンジンよりさらに特化した骨格シミュレータが出てくるかもな。
素のエンジンだと大雑把過ぎて使いづらいかも。
箱に物理エンジンがロイヤリティーフリーで標準搭載されるなら
環境へのリアルな干渉(ブロックが壊れたり金網がひしゃげたり)は当たり前になるんじゃないの。
相手が浮いた時に殴る場所が変わったらどこ飛んでいくかわからんと思うよ
浮いた時に自分が攻撃した場所が足だったり手だったりするわけじゃん
ここまで細かくしたら面白くないか
物理演算はいいんだが、問題は格闘ゲーマーも納得できる対戦バランスを構築できるかどうかだ。
開発者自身も予期せない動作が大量に発生してしまうわけだから、バランス調整はより大変になる。
>>768 >こういうのは任天堂の得意分野なんだが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の演算性能を発揮する可能性もある。
物理演算で一番面白みが増すとしたらクロスシムじゃないかと思うが。
顔が変形するとかより女キャラのコスが体に沿ってぷるぷるのするするに
動くのだったら見てみたい。
パンチラがNGなら、パンツ脱がせばいいのに
何でよりリッチになった演算能力とメモリの使い道が格ゲーリアル一辺倒なんだ?
ビルの爆破解体でも、逆に築城シミュレータでも
合戦物SLGでも敵をより賢くしたり
地形その他のパラメータの種類と精度が上がるだけでもディティールが細かく出来たり
もっとマシな使い道は幾らでも有るだろう。
>>770 そうとも限らないだろ。
空中コンボで、体を殴った時と手を殴ったときで吹っ飛び方が違ったとしても
面白さが阻害されるとは思わない。
VF4あたりでも空中コンボでヒットさせる技の種類によって吹っ飛び方が違うよ。
そのバリエーションが更に増えるわけだから、コンボの多様性という意味では
物理演算は面白さにプラスに働くと思われる。
最大10.5TFLOPSの演算性能
^^^^^^^^^^^^^
すげぇ
格闘ゲームの場合、ヒットするゲームデザインの条件っつーのは、
@操作、ルールがある程度シンプルであること(初心者の敷居が低い)
A技術介入の余地が多い(上級者もやりこみがいがる)
というのがあると思う。
物理演算は、@に対しては影響を与えないが、Aに対しては影響を与える。
物理演算が多様なモーションが生み出し、多様なモーションが多様な状況を生み出すはず。
各状況に対応した最適な行動っつーのは上級者も研究のしがいがあるだろ。
ヒットした場所で威力や吹っ飛びが違うって
ようはスマブラだろ
スマブラはキャラゲー。
ゲーム内容は期待されてないよ。
>>769 物理演算とモデルに対する加工は別次元の話のような気がしますが。
>>776 9fhNQiskがやりたいからでしょ、実際、格闘ゲームで
その手のアプローチは格闘超人とかでも多少取り入れようと
してたりしたけど、たいした進化もなく格闘ゲームがマンネリな
キャラゲーに成り下がってるし。海外はともかく日本で格闘ゲームは
ゲームがポリゴンに流れるきっかけつくったジャンルだし。
個人的にもそれで技術がビジュアルに反映され見栄えが変わるなら
FPSで物がリアルに壊れたり無双みたいなのでキャラが1000体でるより見てみたい。
でも今の日本の格ゲーつくってるところにそんな技術あるとは思えないけど。
ファイティング武術…いや、なんでもない。
なんでだ?
必然だろ
>>783 >技術がビジュアルに反映され見栄えが変わる
ファイトナイト3がそうでは?
格ゲーである以上、リアルタイムに反応できるほどはっきり差が出て
かつ、ゲームパッドで操作しなければいけないんだから
反応や操作を細かくする事はゲーム性の妨げにしかならないっしょ。
ブルース・リーのCG映画ボツになった?
>>783 >その手のアプローチは格闘超人とかでも多少取り入れようとしてたりしたけど
そもそも格ゲーの面白さの核心は対戦にあるわけだから
対戦人口ゼロの格ゲーなんかが売れるはずが無い。
あとキャラ性も音楽もへぼへぼだったんだろ。
格ゲーに物理演算(エンジン?)ってのは、主にバランス調整の問題じゃないのかと。
少なくとも見た目によりリアルに(破綻無く)なるのは確実だとは思うけど、プレイヤーの入力
によって起こる状態の可能性も同時に増えすぎて、それを全て管理しきれるかってのが問題だと。
見た目に美しく吹っ飛ぶのは良いけど、その吹っ飛び方はゲームとして不利すぎ無いか、
有利すぎないかって部分の調整が殆ど不可能になる。
もっとアバウトにバランスが決定出来るゲーム、VS群衆みたいな無双風のゲームなら
物理演算の取り込みようもあるかもしれないけど、細かなあらゆる全ての挙動までが
ゲームバランスとして調整しなきゃならん格ゲーでは(今のままでは)難しいんじゃないかと思う。
格闘ゲームの場合、ゲームデザインも重要だけど、
それ以上に対戦を楽しめる環境や対戦を盛り上げるシステムの方が重要。
格闘超人はその辺がダメダメだった。
まあ、それ以前に「格闘超人」ってやる気無さそうなタイトルである時点で
終わってるけど・・・
格闘超人でやってることって、バウンサーでやってることと一緒じゃなかったっけ?
やられモーションが用意されてないって言う。
起き上がりまでの硬直時間とかコンボの浮き具合とか、かけひきに必要な所は関係なかったんでは?
>>772 おまえさん、任天のゲームしたことないの?
キャラゲーっていうのはゲームがロクでもないものでも、
キャラの力で売れるゲームのことだよ?
普段どんなゲームしてんのさ
任天堂のゲームって見た目子供向けっぽいからな。
子供騙しってやつ?大人も楽しめる本格派って感じがしないし
実際遊んで感じた事も無いな。
>>790 その辺の調整は細かくバージョン上げていく事で対応可能なのでは?
それこそバーチャ4みたいに。
バーチャ4だって最初のバージョンでは強過ぎる技が結構あって
バランス的には酷かったぞ。
風のタクトで皿やコップの挙動が1G下での挙動っぽく見えるようになればそれでいい
風タクにリアルさなんて不必要。
あれも絵とキャラだけで売るキャラゲーだな。
なんだこのID:9fhNQisk(14)
>>798 そっとしておいてやれ
きっと任天堂に親を殺されたんだよ
任天堂みたいにキャラと知名度を頼りに面白くないゲームを売ろうとしても
ネット全盛のご時世では糞ゲーはすぐに叩かれる運命であるから
消費者を騙すにも限界があるって事さ。
ニンテンドウゲーム論は流石にかなり激しくスレ違いじゃ無いかと思うです。。。
そもそもゲーム論?自体スレ違い
しかしゲーム機で一番大切なのはゲームというかソフトウェア
であるのは疑う余地が無いわけで。
ソフトウェアという要件を実現するのにハードウェアが
作られるとしたら、ソフトウェア、つまりゲームが要求する
モノを押さえておくのは非常に重要であると思うね。
特に任天堂。レボみたいに「低価格、低性能」
路線で行く事が本当に正しいのか?
高性能が実現するリアルさはゲームの面白さに
本当に繋がらないと言えるのか、
任天堂はきちんと検討したのだろうか・・・
おい、誰だスイッチ入れたの
間違いなく、あなたより有能な業界の人が真剣には検討してると思いますよ
>>807 と言いつつ、任天堂は子供騙し的な非リアル調ゲームを作り続けているわけだが。
リアリスティックなゲーム作りを目指した事がない任天堂なら
「リアルさはゲームに不必要」という考えを持ってもおかしくない。
そんなんだから任天堂は子供向けのレッテルを貼られるんだ。
>9fhNQisk
任天堂がスレ違いなのは分かるが、
お前もスレ違い
もう、誰にも止められない。
一度流れが出来ちゃったんだから仕方ないべ。
新しい技術的なネタが投入されない限りこの流れは続く。
>>808 いや、いいんじゃね?子供向けで。
正しいと思うよ、任天堂の方向性として。
俺が親なら間違いなく3機種の中でレボ買うし。
家族で遊べそうなゲームもあるし。
9fhNQisk
自分の理論が全て正しいのですか
ID:9fhNQisk
いい加減”ど”素人レベルの中学生でも出来るゲームデザイン考は止めろ。
プロなら既に議論され尽くしてるレベルのものを何を今更得意げに書き込んでるんだ?
CELLのSPEが物理演算で生かせないとなたら、
開発者がCELLを作った意図の大半は実現されなかったと
言うことなのではないの?
それじゃXBOX360のCPUと大差無い。
CELLへの投資は無駄だった、という事なのでは・・・
技術的な話には疎いのであまり長文書けないのだが、
頂点シェーダーの代用や物理演算という用途がCELL(というかSPE)で
どの程度生きるのか、いまいちよくわからん。
というか、現状では生かせないのではないか、と思えてくるのだが。
この辺のことを詳しい人に解説して欲しい。
そもそも「物理演算」と言われる一連のソレが、一体具体的にどんな処理なのかって
のが分かんない。
まぁ、それを簡単に説明出来れば、ダブスチが作れちゃうのだろうけど・・
帯域とか相関とかエンディアンの話はスルーしたい年頃
ある元データがあって
それをもとに計算した結果を吐き出すということをするとき
元データがなぜかころころ書き換えられてそれに追従しなきゃいけないなら
コヒーレンシを保たずに出した結果は壊れたデータということになっちゃう
でも物理演算する時の「元データ」は不変であることが前提でしょ
だって元データだもん、計算の前提だもん
コヒーレンシが保たれないことが物理演算の障害になるとは思えない
>>817 Cellスレに逝けよ・・・
加えて過去に散々蒸し返されてきた話題だし
>>815のリンクにある 車両物理vs.Ragdoll(応用系) は
ダブスチなんかでも使えそうな気がする。
基本的に、Ragdoll物理(基本系) はヒトの動きに関係する
部分なので、生かせそうなシーンは多そう。
HALO2でもチーフのやられモーションで使われていたしな。
>>820 元データが不変というのが違うと思うが。
物理演算した結果のモデルに更に
アクションが加えられて変化するという
可能性だって考えれらるだろ。
箱○のCPUは
そもそもUMAでさらにメモリに直結されていないので
論外・・・・足回りが悪すぎ!!どうしろと・・・
826 :
823:2005/07/10(日) 22:25:43 ID:9fhNQisk
×可能性だって考えれらるだろ。 →○可能性だって考えられるだろ。
物理演算やAIって処理はメインメモリにある共有データを
頻繁に参照しないといけないはずで、こういう処理はLSのような
一時領域的なメモリはあまり生きないだろ。
とすると、SPEって何に生かせるのかって疑問が出てくるわけだ。
なんで1回目の演算と2回目の演算をひとくくりに考えちゃうのよ
CELLが駄目ならXBOX360CPUはどうなるの?
と言われると、CELLより更に駄目って事になるw
しかし、そのそもCPUがボトルネックになるような
シーンがどの程度あるのかと・・・
XBOX360のCPUでもキャラ2000体ワラワラ動かせるって噂があるのにな。
これ以上CPUの性能上げても使い道が無いだけでは。
ほんと誰だよスイッチ入れたの
>これ以上CPUの性能上げても使い道が無いだけでは。
>これ以上CPUの性能上げても使い道が無いだけでは。
>これ以上CPUの性能上げても使い道が無いだけでは。
もう帰れよ低脳
結論はそこに行っちゃうのかよ
なんか口調とか人の意見聞かないとことかが・・・の人みたいだが?
しかし、XBOX360のCPUが駄目と言っても、
XBOX360の場合GPUがCPU的な仕事もある程度できるので
総合的にはそんなに駄目じゃない。
頂点とピクセルは同時に高負荷にはならないというATIの
分析は素晴らしいですな。
>>ID:9fhNQisk
お前、以前CELLスレで長々と今日と同じ事言ってなかったか?
文体に物凄く見覚えがあるんだが?
あーCELLスレにもちょくちょく書き込んでいるから多分俺かもしれない。
ま、そーでもいいけどな。所詮一名無しだし。
837 :
836:2005/07/10(日) 22:55:49 ID:9fhNQisk
×ま、そーでもいいけどな。所詮一名無しだし。 →○ま、どーでもいいけどな。所詮一名無しだし。
>>830 しかしゲーム機でもCPUがボトルネックになる処理ってもうあんまり無いんと違うのか?
ディスプレースマッピング系の処理はGPU側でOKだし、物理演算なんかもHalf-Life2の時点で
ある程度実現されているし。
もうそんなにCPUパワーが必要とされる場面って無いような気が。
つーか、最近のベンチって大抵CPUがボトルネックじゃなかったっけ?
7800GTXもCPUがボトルネックって言われてるな
物理演算なんてどう考えても当たり判定の前処理みたいな物なんだし、
やればやるだけCPUが必要なんて考えなくてもそーなんじゃ無いのか。
物理演算云々言い出してCPUが必要ないって展開は意味わからん。
次世代であっても現実世界との絵の差はまだまだ遙かにある。
この差を埋めて行くにもCPUGPUともにもっともっと進化する必要が
あるんじゃないのか?
>>842 ・キャッシュのコントロールなんかを上手くやらないと性能が出ない
こっちは3コアでL2共用だから当たり前として。
気になるのは、
・汎用コード性能はalphaキット(PowerPC G5 dual)の方が上
だな。
やっぱり970コアじゃなくてPPE相当と考えて良いのやら。
XBOX360のCPUコアはPowerPC G5と同程度の性能が出せるか未知数だが
もしかしたら出せないのかもしれないな・・・
x86系CPUと同様、キャッシュをある程度増やして2コアにした方が
実行性能は高かったのでは。
ディアルコアのメリットは性能低下を
防げること
intelの人間もいってるじゃん
PPC970は2コア合わせてもL2キャッシュはXBOX360とおんなじ1MBですよ