SPU-Based Deferred Shading in BATTLEFIELD 3 for Playstation 3 This document discusses using the SPUs on the PlayStation 3 to perform deferred shading for Battlefield 3, offloading work from the GPU. It provides an overview of the SPU-based deferred shading approach, including breaking the screen into tiles that are processed by multiple SPUs in parallel. Algorithmic optimizations discussed include

僕が抱える不治の病のひとつに、floorとceilのどっちがどっちだか永遠に覚えられないという病気がある。 特に問題なのが、あの記号である。あの記号は、僕の直感とは反対の意味を持つ。 僕の直感では、↓この記号は「天井が降りてきて値が減る」というイメージ ↓この記号は、「床が上がってきて値が増える」というイメージ なのであった。これは逆で、上の記号のほうがceilで切り上げ、下の記号のほうがfloorで切り捨てである。 と、いうわけで、仕方が無いので、僕はこれを「自分の直感とは逆なんだからねっ!!」というように覚えていたのだが、そういう覚えかたは肝心なときに、「あれ…逆ってどっちだったっけ…」とかなりがちである。 この覚えかたを、「可動式床天井方式」…それの反対なので…「反可動式床天井式(以後、反可式)」としておこう。 僕は長いこと反可式で覚えていたわけだが、あまりにどっちがどっちだかわから

(2016/02/10 追記: EASTL は長らく EAWebKit の一部としてライセンスが不明瞭なまま公開されていましたが、この日 BSD ライセンスで正式に公開されました https://github.com/electronicarts/EASTL) 若干古いものですが、2007 年に発表された、Electronic Arts によるゲーム開発向けの改良を加えた STL、"EASTL" の仕様。 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html 仕様だけで実装が公開されてないのが非常に残念なのですが、それは別として、何故こんなものが必要なのか、どういう事情でこの機能が盛り込まれたのか、といったゲーム開発現場の事情が細かく解説されていて、とても参考になります。特に、既にある程度 C++ に習熟してい

平たく言えば、最適化はともかくとして、"高速なシーケンサとしてCPUを使いたい"がために作られる小さなコンパイラというジャンルのライブラリがある。 必要性 これらのライブラリは、パフォーマンスに関する魔法の薬では無い。ある特定の目的のためには良く働くが、通常のコンパイラよりも特殊な目的のために設計されている。 大抵、"コンパイルすべきプログラムがコンパイル時に決定できない"場合に用いられる。qemuやnanojitの場合は実行対象のプログラムであり、orcの場合はデコードのパラメタ等。 従来は、パラメタに応じてコードを全て書くとか、コードの自己書き換えのようなことが行われていた。 http://www.geocities.jp/daichi1969/synthprog/index.html#osc3 このコードは、Ring/Sync/FMの状態に応じて動作する「汎用の」ルーチンと言える。し

■ ご契約の流れについて 評価 ご依頼頂くことで30日間の「無償評価ライセンス」を発行させて頂きます。 30日間を超えて評価頂く場合、またはプロトタイプ開発に合わせて評価を行いたい場合などのご要望により 「有償評価ライセンス」もご用意しております。詳しくは担当営業までお問合せください。 ご導入 ご導入にあたって以下のライセンス契約を締結させて頂きます。 – ソフトウェアライセンス基本契約書 – ソフトウェアライセンス個別契約書(タイトル毎) – 機密保持契約書（NDA) – 反社会的勢力排除に関する覚書 ご延長 ライセンスは有料によりご延長可能です。 ご延長は基本的に自動継続となります。 終了されたい場合はご契約期間終了の1ヵ月前までにご連絡くださいませ。 ■ ライセンス許諾費用について 各ビジネスやご事情に応じて、違いがございますので担当営業までご相談ください。 ■ テクニカルサポートに

CPUの動作速度と比較して、メインメモリは遅い。 PCで使われているスカラ型CPUは内部にキャッシュを持ち、メインメモリとの動作速度の差を吸収しようとしている。 キャッシュにヒットすれば即座に読み出せるが、ヒットしなければメインメモリからの読み込み待ちとなり、膨大なウェイトが入る。 CPUのL1キャッシュは物によって違うがだいたい32byteか64byteあたりのキャッシュラインサイズで、メインメモリのどこか1つでも読まれると、32/64byteがキャッシュにロードされる。 普通は近いアドレスへのアクセスが多いだろうから、このようにすることで、連続したメモリに対するアクセスを高速化しているわけだ。 逆に言えば、完全にランダムなメモリアクセスをするプログラムはキャッシュ効率が非常に悪く、スカラ型CPUはキャッシュにヒットしなければゴミ同然で、このへんを考えることは実行速度にとっては重要だ。

Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode