Sony Santa Monica揭秘《战神3》在SPU中的新的编程技巧(全日文,慎入,已初步汉化)

  • 米兰的红与黑


    GDC2009では、この開発中の「GOW III」におけるプログラミングテクニックが「Practical SPU Programming in God of War III」と題したセッションで披露された。



    SPUは、CPUタスクとGPUタスク、両方の助っ人

    「GOW」シリーズは、どれもハイテク満載な出来映えで、テクノロジーリーダー的な作品として評価されてきた。今作「III」は初のPS3作品ということで、どんなテクニックが盛り込まれているのか、開発者たちからは熱い視線が寄せられている。セッションを聴講した結論から言えば、PS3におけるゲーム開発において、非常に堅実なアプローチのマルチスレッド・プログラミングを実装していたと思う。



    Sony Santa Monica、Jim Tilander




    Sony Santa Monica、Vassily Filippov


    まず、語られたのは、ゲームプログラムの基本的な並列化アプローチについて。一般的なゲームアプリケーションでは、ゲーム進行やゲームルールを司る「シミュレーション」部、描画するオブジェクトのデータ収集や描画コマンド作成までの「シーン」処理、実際の「レンダリング」処理の3つの処理に分かれる。



    「GOW III」に限らず、一般的なゲーム処理の流れはこのような3フェーズからなる


    これを並列化する第1段階となるのが、ダブルバッファの概念の導入だ。ダブルバッファとはその名の通り出力先のバッファを2つにするもの。描画の場合にはレンダリング先のバッファをデュアル化することを意味する。あるフレームの描画を開始した直後から、次フレームのシミュレーションの処理を開始し、見かけ上、シミュレーションと1つ前のフレームのレンダリング(描画)をオーバーラップさせることができて、実質的にシミュレーション部の処理コストが隠蔽できる。

    CPUとGPUは個別に動けるので、最も基本的な並列化が実現される。だとすれば、CPUをさらにマルチコア化して、CPUで処理しているシミュレーション部とシーン処理部を2つのCPUに割り当ててオーバーラップさせて実行すれば、シーン処理の処理コストを隠蔽できる。これはちょうどCPUのパイプライン構造とよく似た考え方の並列化だ。

    ただ、各処理フェーズの処理時間は均等でない。シミュレーション処理とシーン処理が短くてもそこにオーバーラップしているレンダリングに時間がかかれば、それに足を引っ張られて、オーバーラップさせての並列実行が理想通りにはいかない。2人で一緒に歩こうとしても、速度の遅い同行者の方にペースが落ちてしまうのと似た理屈だ。



    CPUとGPUとで処理をオーバーラップさせる最も基本形の並列化




    マルチコアCPUならば、そのほかのCPU向けた宿毛オーバーラップできるはず




    並列化してもうまくパフォーマンスが上がらないとき、並列化した作業のどれかが極端に時間が掛かっている可能性がある


    「GOW」チームが考えた、この状況の最もシンプルで短絡的な解決方法とは「処理時間のかかっている処理フェーズをなんとかして早く終わらせる」というきわめて単純なものだった。

    具体的にどうやるかというと、万能な「助っ人CPU」(Helper CPU)に、遅い方の処理を手伝ってもらって早く終わらせる。ではその万能な助っ人CPUとはなにかといえば、PS3においては「SPU」(Synergistic Processor Unit)だ。




    そんなときは誰か に助けてもらおう




    PS3にはCELLプロセッサのSPUがあるじゃないか


    SPUとは、PS3のCPUのCELLプロセッサの中に7基(8基のうち1基は歩留まり向上のために無効化)搭載された128ビットSIMD型RISCプロセッサのこと。本来はSPUと呼ぶ場合は演算ユニット単体を指し、ローカルストレージメモリを含んだ全体を指す場合はSPE(Synergistic Processor Element)と呼ぶが、最近はあまり区別なく呼ばれるようで、セッション中のスライドもSPUと記載されているので本稿もこれに倣うものとする。

    SPUは“コ”プロセッサ的に捉えられることが多いが、汎用プロセッサでありしかも、1つ1つが他のプロセッサ(メインプロセッサのPPU:Power Processor Unitや他のSPU)から独 立して動作できる。





    SPUは、コプロセッサではなく立派な汎用プロセッサである。しかも超高速な!


    「GOW」チームでは、GPUで実行される処理内容、PPUで実行される処理内容、それぞれをSPUでも処理できるように、SPUの処理モジュールを開発。特にPPUのコードはSPUのコードと極力コンパチにして開発し、負荷状況に応じてリアルタイムにPPU版コードとSPU版コードを切り換えて実行する仕組みを実装した。

    つまり「GOW III」では、SPUに対して決まり切った「SPUの得意そうな仕事」を固定的にさせるのではなく、PPUやGPUが担当している処理内容を、必要に応じてSPUが肩代わりできるように処理系を設計したのだ。そしてPPUやGPUの負荷状況に応じてSPUで実装された、そうしたPPU/GPU応援モジュールを支援に駆けつけさ せるというイメージだ。




    こうなっている処理を……




    こうしてしまおうという方針。SPUに、CPUタスクもGPUタスクも手伝わせる。これが「GOW III」のSPU活用方針だった


    ところで本連載の読者ならば、GPUのアーキテクチャに「統合型シェーダー」(Unified Shader)という概念があるのを知っていることだろう。汎用シェーダーユニットはフリーランスとしておき、頂点処理に負荷が高ければそのフリーランスな汎用シェーダーユニットを頂点シェーダーとして起用し、ピクセル負荷が高ければ、より多くの汎用シェーダーを今度はピクセルシェーダーに割り当てていく。これが、統合型シェ ーダーのアーキテクチャだ。




    「GOW III」においてSPUを助っ人に起用したモジュール一覧


    「GOW III」ではそんな感じに、その時点でのシステム負荷に応じてSPUを、PPU支援に向かわせたり、GPU支援に向かわせたりさせたと言うことだ。

    ちなみに「GOW III」において、SPUで実装したPPUやGPUの支援モジュールは以下のようになっている。


    シミュレーション部
    アニメーション
    布のシミュレーション
    衝突物理シミュレーション
    プロシージャルテキスチャ生成

    シーン処理
    カリング(描画不要ポリゴンの切り捨て)
    影生成
    プッシュバッファ生成
    その他のタスク

    レンダリング処理
    ジオメトリ処理各種
    サウンド処理

    イメージ的にいえば、「GOW III」では支援にやってきたSPUによって、マルチPPUになったり、マルチGPUになったりするというイメージだ。これはシンプルだが独創的 なSPU活用方法だと言える。




    各タスクがどのくらい時間を要したかを可視化するデバッグツールを開発。上がPPUタスク。 下がSPUタスクを表わしている




    ボトルネックを探し出し、SPUを助っ人に向かわせるようにプログラムをモディファイ・チューニング



    「GOW III」のSPU最適化回想録

    シミュレーション部、シーン処理、レンダリング処理の各処理系においての、特殊な最適化ケースについても語られた。具体的には、処理系によってはSPU専任タスクとしてしまったり、PPU専任タスクを残したりというような細かいチューニング的な振り分けの話だ。まずはシミュレーション部について。

    「GOW III」に登場する見上げるような巨大な敵キャラ「タイタン族」はまさしく動くゲームステージという感じで、その衝突判定処理は非常に高負荷でSPUでの支援が必要不可欠だったとしている。その巨大さ故に、相対的に小さい主人公へのカメラのズームインや、タイタン全体を捉えるズームアウトが頻繁に起こり、衝突判定用の形状モデルは、LODを駆使した低解像モデルで行なうのではなく高解像モデルで行なったため負荷が高くなってしまったようだ。そこで巨大なタイタンについての衝突判定は細かく分割してSPUに処理させる方策をとったとしている。この衝突判定の仕組みはレベルデザイナーやアーティストがタイタンが出てこないところ(例えば、絶壁に掛けられた縄ばしごなど)にも適用され 、役に立ったと振り返っている。








    タイタン族の衝突判定は分割してSPUに任せた


    布のシミュレーションについては、主人公クレイトスのスカートのほかにも無数の敵キャラの衣装に適用されるが、これらのシミュレーション結果は他の物理シミュレーションに影響を与えない、いわば独立した視覚効果用物理シミュレーションであるためリアルタイム性を必要としない。そこで、シミュレーション部の最初の頃に処理をSPUに依頼したあと、バックグラウンドでのんびりと実行させ、レンダリング開始時まで放置しておけるような実装にしたとしている。なお実行は、 5基のSPUに発注するようにしている。






    布のシミュレーションはゆったりとしたペースで処理


    シーン処理では、カリング処理のうち、視錐台内外チェック、表示モデルのリスト生成、可視/不可視ビット生成、遮蔽チェックなどはSPUタスクとして割り当てているが、遮蔽関係処理や可視ビット関連処理はPPUでも行なっている。

    シーン処理では、描画のための最終下準備ともいえるプッシュバッファ(メインメモリ側にGPUに実行させるコマンドリストを作成しておき、これを必要に応じてGPUに実行させる仕組み)の生成は当初はPPUで行なっていた。頂点バッファ設定、シェーダー定数、テクスチャ情報の設定、3Dモデルの取りまとめなど、膨大な数のポインタを渡り歩くようなデータ採集処理はPPUのL2キャッシュのスラッシングを引き起こし、パフォーマンスを引き下げてくれたため、こうした処理のSPU版は、小さな処理グループに分けてそれらを複数のSPUで取りかかるような処理系にしたとしている。

    また、あるモデル処理を行なっている間に並行して別モデルのフェッチを行なうようなダブルバッファDMAの仕組みを導入し、メモリアクセスコストの隠蔽を極力行なっている。このプッシュバッファ生成には5基のSPUで取りかかる実装としたが、デバッグ処理ではPPU版の処理系にスイッチできるようにしたとも述べている。これは、SPU版の処理系ではデバッグ用の処理系までがSP Uのローカルストアに載らなかったためだ。






    プッシュバッファ生成も基本的にはSPUで


    レンダリング処理では、不透明オブジェクトの頂点処理とそのライティングの負荷低減に取り組みそれらをSPUで処理するように設計している。ジオメトリ処理関連のSPU委任の定番と言えば、ソニー謹製のSPUベースのジオメトリ・プロセッシング・エンジン「Playstation Edge」(PS Edge)だ。「GOW III」では、頂点データはすべてPS Edgeで処理してしまい(≒SPUでの頂点シェダー処理)、PS3のGPU(RSX)に受け渡している。つまり、RSX側の頂点シェーダーは基本的に活用しない実装としたのだ。

    具体的な「GOW III」の頂点シェ ーダーのパイプラインは下図のようになっている。




    「GOW III」の頂点シェーダーのパイプライン


    青いマスがPS Edgeをコールしているもので、緑のマスは「GOW III」オリジナルのカスタム頂点陰影処理になる。PS Edgeが採用する圧縮頂点データを解凍し、スキニング、カリングもPS Edgeを利用する。この後、頂点単位の法線ベクトル生成と、これを用いた特別な頂点単位のライティングは「GOW III」チームのカスタムメイドだ。これをRSXに受け渡す書式にまとめる処理をPS Edgeで行なって、頂点シェダー処理が完了する。なお、「GOW III」では、1描画コールあたりを1ジョブとし、およそ1フレーム辺り3,00 0個のジオメトリ・ジョブを発行しているとのこと。




    「GOW III」では頂点シェーダーはSPUで代行。RSX側の頂点シェーダーは活用せず。実は、最近のPS3タイトルはこの実装が多い。RSXは評判が悪いが、SPU頂点シェーダーはすこぶる評判がいいのだ

    「GOW III」では、ピクセル単位のポストプロセスフェーズでもSPUを活用している。レンダリング後のフレームの各ピクセルからキューブマップを参照して色補正をする特殊なポストプロセスを「GOW III」では採用しているという。これはDefferred Shadingとか、あるいはキューブマップを活用した疑似的なイメージベースドライティング(IBL)のようなテクニックのようだが、主題はそこではなく、このポストプロセスに用いる動的なキューブマップの生成にSPUを活用したと述べている。シーン内の指定した場所から6面分の動的な環境マップをレンダリングするようなイメージになるが、これは6個のSPUを起用して生成しているという。こちらも布のシミュレーションの時と同じで、急がないタスクなので、実際にはSPUが あいているときにゆっくりと計算させているとのこと。






    「GOW III」特製の色補正に用いるキューブマップ生成にもSPUを起用



    「GOW III」チームからPS3開発者へ贈る言葉

    講演の最後にTilander氏とFilippov氏は、「GOW III」の開発経験から学んだ教訓を、これからPS3の開発に挑戦するデベロッパーに向けて述べている。


    並列プログラミングを大前提としたPS3のポテンシャルを活かせ
    CELLプロセッサは非対称マルチコアプロセッサにカテゴライズされ、CELLプロセッサ内のメインCPUのPPUと、その配下のSPUは機能/スペックが異なる。確かにそうなのだが、「GOW III」チームの両氏はSPUを汎用プロセッサとして捉え、直面した負荷/ボトルネックをSPUによる支援で低減するような設計方針にすれば、難しそうな並列プログラミングも幾分か簡単になるのではないか、こう言いたいわけだ。

    早まった最適化をするな
    「CELLプロセッサのパワーはSPUの活用にあり」。このソニー側のメッセージに囚われて、ゲーム設計の初期からSPUをどう活用するか悩むべきではない。「ユーザーのゲームプレイ体験をどう面白くするか」に注力してゲームを設計し、必要になったら最適化を考えればいい。こう両氏は述べている。確かにマルチプラットフォームでなくPS3専用でゲームを開発する場合にはこのアプローチは理にかなっているかもしれない。

    速度を測れ
    SPUは、データをローカルストアに持ってきた後の処理がめちゃくちゃに高速。だから、一見速くなりそうにないやり方でもSPUで実装してみるといい。そしてSPUでの実行結果とPPU、GPUだけとの結果を比較してみよう。やってみる価値はある。これが両氏のメッセージだ。

    「GOW III」の開発においては、口悪く言えばSPUを行き当たりばったり的に活用していったわけだが、それでも十分な成果が得られたようだ。SPUはそういう使い方でも十分威力を発揮してくれるということを言いたいのだろう。



    非対称型マルチコアCPUであるPS3のCPU、CELLプロセッサは、確かにこれまでのメインストリームなコンピューター製品には無かったものだ。それだけに手強い印象があるし、非対称マルチコアCPUだから「非対称な特性を効果的に活用しなければならない」という先入観を開発者たちに与え、もっと言えばそうした強迫観念のようなものすらPS3からでていたように思う。

    「GOW III」開発チームは、こうしたCELLプロセッサのイメージをまったく気にせずに、SPUを汎用プロセッサとして活用し、そうした使い方として十分成り立つということをこの講演で主張してきた。

    まだ発売前のタイトルなので、彼らの今回の主張は、実際に発売された「GOW III」を触れてみるまでは信じられないかもしれないが、それでも「そういう発想もある」ということは広く伝えられたのではないかと思う。
  • M
    Melchior
    日文貌似是对图片slideshow的解释。幸好我还懂英文
  • c
    chm128256
    有人可以翻译一下么?
  • k
    kaximu
    有些专业词看不懂。。。
  • k
    kaximu
    GDC2009,在开发中的[GOW3]编程技巧,在名为[Practical SPU Programming in god of war3]发布会上被公布出来

    SPU是协助CPU任务与GPU任务的人
    [gow]系列,不管哪个都满载着高技术。作为技术领导性的作品来评价。本系列第三作为PS3的前几个作品。究竟加入了说明技术呢?被开发者用热烈的视线注视着。从发布会的听讲的结论来说,在PS3上开发的游戏,我想可以非常确定的探讨(研究)多线程编程的实际运用。

    首先。作为话题的是,关于游戏编程最基本的并行编程。一般性的游戏应用间互操作,管理游戏进行与游戏规则[模拟]部分,绘图的对象的资料手机与绘图命令到完成为止的[场景]处理,实际的[渲染]处理分为3个部分

    不限於[gow3],一般性的游戏处理也继承这样3个阶段
    这作为并列化的第一个阶段,导入双重缓存区概念。双重缓存区就如其名一样,输出信号先进入2个缓存区。意味着可以在绘图的情况下渲染可以先对缓存进行双路处理化。某个框架的绘图开始之后,之后开始下一个框架的模拟处理。一般,可以模拟与之前一个框架渲染重叠。隐藏实质性的模拟部分的处理。

    CPU与GPU是分别运作的,被实现最基本的并行化。那样的话,CPU更加多核化,用CPU处理的模拟部分与场景处理部适当的分割给CPU的2个核心来执行。可以隐藏场景处理的处理过程。这里有一点与CPU的管道构造的想法相似的并列化。

    但是,各处理阶段的处理时间无法均衡。模拟处理与场景处理即使缩短,那里重叠的渲染所花费的时间,也会导致性能下降,被重叠的部分并行执行无法如理想的一样。即使2块一起处理,一方的速度的延迟也会导致另一方的步调下降。
  • k
    kaximu
    LZ看到 把题目改下。我有时间就翻译下。今天太困就翻译到这里。
    小弟水平太菜...请各位指点。
  • k
    kaximu
    */-54 对于 CPU与GPU处理重叠 最基本的并列化

    不止是多核CPU,也可以面向其他的CPU也可以处理重叠 (宿毛 应该是地名。不知道放这里什么意思)

    在并列化也无法很好的使执行效率上升的时候,并列化后的作业无论哪一个都有极端的耗费时间的可能性
    [gow]小组考虑后,这个状况的最简单的解决方法是[比较占用处理时间的处理阶段尽早的结束]这样一个非常简单的方法。

    具体的实现下来就是,在万能的[协助CPU],协助处理慢的一方,使其早点结束。那么那个万能的协助CPU究竟是什么呢?在PS3里面被称作[SPU](Synergistic Processor Unit)

    在那个时候谁来协助

    是PS3中CELL芯片的SPU吗?

    SPU是PS3的CPU—CELL芯片中的七个单元(八个单元中的一个基于成品率而无效化)被搭载128BIT的SIMD型RISC芯片。本来SPU只有在演算unit单体时的命名,包含局部压力存储器(不知道这个词翻对不对,没查到就按自己理解的翻译了)全体都称为了SPE。但因为最近不怎么区分这些了,发布会中的幻灯片全部都记载成SPU,在本稿中也仿照这样。

    spu是被大多被协处理器所捕获,一般用处理器也可以,并且一个一个独立出其他的处理器(主处理器的PPU:Power Processor Unit与其他的SPU)运行。(PS:这句问题可能比较多。而且感觉原文短句有点问题)

    SPU,与协处理器不同,伟大的通用处理器。而且是超高速的!
    [GOW]小组把GPU执行的处理内容与PPU执行处理内容,作成都可以在SPU中处理,开发SPU处理模块。特别是PPU的编码与SPU的编码尽量开发成高兼容性。对应负荷的情况实时PPU版编码与SPU版编码替换执行的结构装配。

    就是说[GOW3]中,对应SPU决定[SPU高效的工作]并不做固定性的处理。PPU与GPU担任的处理内容,设计成必须可以对应SPU协助处理的机制。之后对应PPU与GPU的负荷状况安装,然后就可以加速协助PPU/GPU支援模块。大概就是这种印象。

    变成这样的处理...

    变成这样的方针,SPU协助CPU任务与GPU任务。这就是[GOW3]活用spu的方针
    话说回来如果是本连载的读者,大概知道在GPU的架构中被称作[统一渲染]的概念吧。通用渲染单元作为自由的,如果在顶点处理负担高的话,那个自由的通用渲染单元就作为顶点着色器使用。像素负担高的话,更多的通用着色器在像素着色器中分配使用。这就是统一渲染架构。

    在[gow3]中SPU起到协助作用模块一览

    在[GOW3]就是这样感到,在某个时刻让SPU、PPU的协助,GPU的支援对应系统的负担。
    另外在[GOW3],装配了SPU的PPU与CPU的支援模块如下

    模拟部:
    动画
    布的模拟
    碰撞物理模拟

    场景处理
    去除不需要在绘图上的多边形
    生成影子
    推动缓冲区
    其他的任务
    プロシージャルテキスチャ生成 (这个词实在查不到...)

    渲染处理
    各种几何处理
    声音处理

    就给我的印象来说,[GOW3]因为SPU的协助,有种一会变成多PPU,一会又变成多GPU。这可以说简单而独创性的活用SPU方法


    各任务需要使用多少时间的可视化调试工具的开发。上面表示PPU任务,下面表示SPU任务

    找出瓶颈,使用SPU协助的程序调整

    [GOW3]的SPU最佳化的回忆录

    于模拟部,场景部,渲染部处理的各处理,即使找到特殊的最佳化的例子口语。具体的是,根据处理机制处理作为SPU专有任务,确认有无残留PPU专有任务之类区分细节微调性类似的事。首先关于模拟部分。

    在[GOW3]登场的需要仰视才能看到的巨大敌角色[泰坦族],感到其震撼的动作游戏场景。那个碰撞判断处理是非常高负荷的,SPU的协助是必不可少的。因为过于巨大,相对变小的主人公的镜头放大与泰坦全体的镜头缩小切换过于频繁。碰撞判定用的形状模型、在LOD驱使下并没有使用低解析度的图像模型,而是还在继续使用高精度模型的原因,使得负荷变高。所以关于那个巨大的泰坦碰撞判定的细分交给SPU处理是一种策略。这个碰撞判定的策划设计师与美工 泰坦还没有出来的时候(比如说:被挂在悬崖上的绳桥之类)被采用。重复的使用有效的。(一时想不起来怎么翻了...这句)

    泰坦族的碰撞判定分割交给SPU

    关于布的模拟,虽然适用于主人公クレイトス的裙子以及无数敌人角色的衣服。这是模拟结果其他的物理模拟的结果影响所带来的。就是说为了独立的视觉效果用物理模拟实时性是必须的。这里,模拟部分的最早的时候处理依靠SPU之后,交给后台慢慢处理。作为像到渲染开始时才放置一样装配起来。另外执行时要请求5个SPU单元。

    布的模拟顺畅的处理

    在场景与カリング处理的同时,视锥台内外检查,表示模型的目录生成,可视/不可视比特生成。遮掩检查之类作为SPU任务分割为适当的部分。遮盖关系处理与可视比特关联性处理PPU也可以执行。场景处理,为了绘图最终准备推动缓存(内存旁边被CPU作成执行命令列表,这是必须对应GPU执行的结构)的生成当初是由PPU来执行的。顶点缓存设定,着色器定数,纹理参数设定,3D模型读取等等,大量数的指针到处更换的数据采集处理输入PPU的L2缓存。导致性能下降,这样处理的SPU版,分割为小的处理组分别有复数的SPU来处理的处理机制。

    还有,某个模型处理的同时另一个模型的读取指令开始执行这样的类型缓存在DMA结构中导入,访问存储器的隐藏极力的进行。(这句貌似也有点不对)这个推动缓存生成5个单元SPU开始装配。调试处理PPU版处理系统中可以开关这样描述。因为这就是在SPU版处理系统调试用的处理系统 SPU的本地存储没有装载。

    推动缓存生成基本的是用SPU

    渲染处理,不透明对象的顶点处理与其灯光的降低负荷的解决方案,那些就设计成交给SPU处理。在谈到几何处理关联的SPU委托的基本,SONY谨制的SPU基础的几何「Playstation Edge」(PS Edge)。在[gow3],顶点资料所有都用PS Edge处理。(用SPU处理顶点着色器)。交给PS3的GPU(RSX)。因此,RSX边的顶点着色器基本上不作为灵活使用装配。

    具体的[GOW3]顶点着色器管道如下图

    [GOW3]的顶点着色器管道

    青色框是PS Edge请求的东西,绿色框是[GOW3]原本的定制的顶点阴影处理。PS Edge采用压缩顶点数据解压,スキニング(削皮)、カリング都被PS Edge所利用。在这之后,生成顶点单位矢量法线与,使用这个特别的顶点单位的读写[GOW3]小组定制的。这个整理成在RSX上适用的格式用PS Edge处理。顶点着色器处理结束之后。另外,[GOW3]一个绘图请求作为一个工作,大概一个框架大约生成3000个多边形的工作量。

    在[gow3]顶点着色器用SPU代为执行,RSX边的顶点着色器并不活用。事实上,最近的PS3标题这样执行的很多。RSX判断不好,SPU顶点着色器判断极其好用。

    在[GOW3]中,即使像素单位的主机阶段进程(猜的)也可以活用SPU。渲染后框架从各像素参照立方体地图修正颜色的特殊主机阶段进程在[GOW3]中采用。这就是Defferred Shading,或是立方体地图的活用疑似想象最好的读写(IBL)一样的技术。那个并不是主题。描述这个在主机阶段进程使用动态立方体地图的生成活用SPU。像场景内指定的场所开始动态的分为6面环境地图渲染的构思一样。这是在6个SPU作用下生成的,这边也是模拟的同时,不紧不慢的任务,实际上SPU被设计成在有任务时不紧不慢的计算。

    [GOW3]特制的色彩校正用立方体地图生成中SPU的作用

    [GOW3]小组们对PS3开发者的赠言:

    演讲的最后Tilander与Filippov,从[GOW3]的开发经验学到的教训,向从现在开始挑战PS3开发的开发商讲述。

    并行编程活跃于作为PS3的潜力的大前提

    CELL处理器作为非对称的多核处理器,CELL处理器内主CPU的PPU与其下的SPU的机能/规格比较怪异。确实时那样。[GOW3]小组2人了解到SPU时可以作为通用处理器。直接面对负荷与瓶颈因为SPU的协助而减低这样的设计方针。采用了这样的方针的话,看上去很难的并行编程也变的几分简单了吧?

    不要过早优化

    [CELL处理器的能力在于活用SPU]。这一边被SONY的信息所困扰。不要在游戏的设计初期就开始烦恼SPU的活用化,而应该在[如何让客户的游戏体验更加有趣]上着重设计。在必须的情况下再考虑最优化。2人这样描述的。确实非多平台PS3专用游戏的开发情况中这个做法可能是明智的。

    测速
    SPU,数据在本地存储中使得之后的处理相当的快。所以,看上去好像没有比这个更快的方法,但是在试着SPU执行下。用SPU执行的结果与PPU、让我们与单一个GPU的结果比较。值得一试。这就是2人的信息。

    关于[GOW3]的开发,说句难听的话就是一直使用SPU的活用,而且还像是得到很好的成果。SPU即使在那种使用方法下也可以发挥很强的威力。

    作为非对称多核CPU的PS3的CPU,CELL处理器,确实到现在为止的主流的电脑制品没有太多关系。但却留下那么强硬的印象。因为是非对称多核CPU,所以给开发者留下[必须有效地利用非对称的特点]这样先入为主的概念。甚至一些痴迷似乎更PS3的这样的概念。

    [GOW3]开发小组,就这样完全没有理会CELL处理器给人的这样的印象。把SPU作为通用CPU活用,之后其作为使用方法被公认在本次演讲中作为主张。

    还有在发售之前的标题,他们这次的主张。到接触到实际发售[GOW3]为止都不相信。即使这样[也有这样的感想]我认为这不是应该广泛的报道吗。

    PS:*/-20 终于翻译完了。*/-20 我也知道我水平不够,里面有不少问题。望大家多多批评.*/-54
  • 米兰的红与黑
    先要感谢下kaximu,现在大家可以看了,觉得哪里有问题可以提出
  • k
    kaximu
    哎。。。白翻了。。。没人看 555*/-58

    突然发现米兰的签名 通过这个翻译确实觉得做游戏机编程 都尽力对应游戏机做了不少优化。哎 玩游戏还是游戏机才是王道啊
  • c
    chm128256
    我在看啊 感谢你哦 我今年最期待的游戏就是这个了
  • 8
    89083134
    MARK一下起来看.........

    太晚了.........
  • k
    kaximu
    呵呵 努力没白费*/-30
  • s
    snakewl
    多谢翻译啦兄弟。PS3的CELL如果用好可以性能很赞,如果弄不好,画面及帧数就比X360差了。在GTA4上我就大有体会啊*/-95……当然也跟PS3的256内存和弱弱的GPU有关系……
    独占大作方面,GT5的画面也就那样了,1080P下锯齿还是很多的,16台车同时竞赛时,感觉fps也有下降。MGS4倒是不错,希望战神千万别让俺们失望。。。
  • k
    kaximu
    CELL芯片是多芯片 而且还是非对称的。。。这个是最要命的。。。跨平台的游戏 移植到PS3上几乎等于重新开发个
  • n
    nu123
    狂顶kaximu!!!!~~~~*/-27*/-27*/-27
  • k
    kaximu
    */-30 3Q o(∩_∩)o...