My life as an APE

交通違反（赤信号停止違反）の通知をもらい、ガックリと崩ずおれる。
仕事の帰りがけに柿の種をつまんだら、それがお腹に来て帰路に急いでいた
ある夜だったが、焦るあまり赤信号に引っかかり華麗に自動撮影にヒット。ご当地では、赤信号停止違反は罰金＋教習コース。
あの時柿の種をつまむのを我慢していたらと、運命の皮肉を感じる。
#ついでに「華麗なる一族」の運命の皮肉的な結末にもガックリ。

さて、あまり披露する話でも無いのだが、自分は昔からお腹が弱く、腹痛との縁は長く、深く、暗い。墓場まで持っていかねばならない秘密も多い。
人生、シークレットが多いほうがミステリアスで魅力的といわれることもあるようだが、そんなことは無い気がする。
特に、日本の本屋に行くとかなりの高確率で腹痛になる。大体、入店後１０分以内に自動的に腹痛→厠直行コースだ。
オンラインで同様の質問をしている方もいるようなので、これはそこそこ普遍的な問題のようだ。
http://oshiete1.goo.ne.jp/kotaeru.php3?q=224177
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1310668528
そんな腹痛と共に生きる人々に、ちょっとしたライフハックを紹介したい。

本屋腹痛問題について、原因と対策を長年試行錯誤してきたが、ついに近年、自分なりの答えにたどり着いた。
これまでに考えたあり得そうな原因は
・心理的な問題
　本屋という閉鎖空間での緊張感、または活字に対する無意識の抑圧
・視覚的な原因
　本屋の中を歩きながら活字をみることで、視覚が酩酊する
などだったが、現時点で一番有力な仮説は「新刊書籍に特有のインクの臭気が原因」の化学物質説だ。書籍のインクに含まれる独特のインクの臭い物質が、どうも腹痛の原因になっているのではないだろうか。
その根拠として
・古本屋ではインクの臭気が抜けているためか、腹痛がおきにくい
・アメリカの本屋ではインクの匂いが違い、腹痛が起きない
などの状況証拠が挙げられる。

さて、その対策として最近試しているのが本屋に入るときには鼻をつまんで、インクの腹痛誘発成分をできるだけ鼻に入れない、という対策だ。傍目には鼻をつまんだちょっと変な人がいる、という恥ずかしい展開だが、死活問題なのでなりふり構っていられない。
自分としては、この対策をはじめてから本屋から厠直行率が当社費50%減程度削減されたかと思う。本屋問題に悩まれる御同輩にはぜひとも試してみていただきたい。

コメントいただいたので、GPUのキャッシュコヒーレンシについてもすこし考えてみる。なお、以下はあくまで勝手な推測なので悪しからずだ。
GPUキャッシュのコヒーレンシを考える際のキーは、
GPU内部でのデータハザード（特にReadAfterWrite/RAW）対策として、ラスタオペレーションの結果を効率よくストアフォワードできるのか、それともそんなの無茶なのか
という点になる。

パイプライン処理、データハザードについてはWikipediaを参照されたい。
キャッシュメモリのコヒーレンシについても同じく

GPU内部にはテクスチャキャッシュ、頂点キャッシュ、変換後頂点キャッシュ等、数種類のキャッシュメモリがある。このうち外部ストレージからのデータフェッチをキャッシュするのはテクスチャ・キャッシュ、頂点キャッシュの二種だ。GPUではパイプラインが非常に深く、回路をシンプルに保つためもあってこれらのキャッシュメモリの不整合に関してはこれまで無視されてきた。この対策として、

Destination（カラーバッファ、深度バッファ）はソースとして同時参照できない

リソースをCPU側で更新する際にはLock/Unlockを必要とする

という制約がAPIレベルで課せられている。
API設計の面での自由度が格段に高い組み込み機、特に一部のUMA設計なゲーム機では、ソースバッファとデスティネーションを同一アドレスにして描画中のバッファ状態を参照、シェーダ処理に使う、というテクニックが存在したようだ。この場合、データのコヒーレンシは保障されないが、ゲーム機の映像処理ではFake上等、目立た無ければOKな世界なので、案外問題にならかった様子だ。
また余談だが、モダンなGPUの強力機能の一つHiZ/階層ZはDepthBufferの情報の一部をHiZ用メモリに転送している。が、よくよくベンチマークをとると、Depthバッファの情報がすぐにHiZに反映されておらず、若干のレイテンシがあることが分かる。ここでもコヒーレンシが維持されてなくともパフォーマンスに影響があるだけなので大きな問題がない。

GPU内部でキャッシュのコヒーレンシを維持したい場合とは、例えば例えば半透明プリミティブの描画順番をうまく解決するために、現時点での（１ないし複数の）カラーバッファ、深度バッファの状態を正しく把握したいケースなどが考えられる。
この場合、直前の描画プリミティブによって更新されたバッファの内容をシェーダ内で正しく参照できればよいことになる。

原理的にはプリミティブ描画を行なうごとにキャッシュをフラッシュすれば正しいデータが常に取得できるがパフォーマンス上は大きなペナルティとなり、よろしくない。このため、ラスタオペレーションを行なった後のデータをGPU内部でGPUキャッシュに効率的に反映できる仕組みが必要となる。
こうした問題に対してCPUではストア・フォワードといわれるバイパス回路で対応している。データがパイプライン内で生成された以降、出来るだけ速いステージでデータ参照ソースに結果を反映させる仕組みで、多くのRisc、Pentium4、Core2アーキテクチャなどで採用されている。
http://journal.mycom.co.jp/special/2006/conroe/005.html

ところで、CellBroadbandEngine等に搭載されているPPCコアではストアフォワード無しというかっとんだ 大胆な割り切った仕様になっている。このため（一部には）悪名高いLHS（LoadHitStore）ストール/フラッシュがパフォーマンスに大きな影響を与えている。LHSは、レジスタファイルへの書き込み後読み出しであるReadAfterWrite/RAWとはまた別のもので、STQの長いトンネルを抜けるまで待つ必要がある。
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/BE_Handbook_v1.0_10May2006.pdf
http://www-03.ibm.com/servers/eserver/pseries/hardware/whitepapers/power4_3.html
Load Hit Store: A younger load that executes before an older store to the same memory location has written its data to the caches must retrieve the data from the SDQ. As a result, as loads execute they check the SRQ to see if there is any older store to the same memory location with data in the SDQ. If one is found, the data is forwarded from the SDQ rather than from the cache. If the data cannot be forwarded, as will be the case if the load and store instructions operate on overlapping memory locations and the load data is not the same as or contained within the store data, the group containing the load instruction is flushed, that is, it and all younger groups are discarded and refetched from the instruction cache. If we can tell that there is an older store instruction that will write to the same memory location but has yet to write its result to the SDQ, the load instruction is rejected and reissues again waiting for the store instruction to execute.

さて、GPUでストアフォワードが効果的に実装可能か、という点については、ある一定の制限範囲内で実用になるのではないだろうか、という気がしている。ならないかもしれないが。
1)GPUでは三角形（ところにより四角形）のプリミティブを描画単位とするが、通常描画時、つまり任意アドレスへのデータエクスポートを行なわないという制限下では、ひとつのプリミティブ内ではデータ重ね書き（WriteAfterWrite/WAW）は起きない。また、データが更新される領域もトライアングルセットアップ時に予測できる。
このため、GPU内部のキャッシュラインが128バイトといった大きな単位であっても、キャッシュライン単位のダーティビット管理で十分であるし、更新頻度もプリミティブ単位の管理で効率的な動作が予想される。
#ただし、数ピクセル以下の面積のマイクロプリミティブの描画では大きなオーバーヘッドになる可能性もある。
2)また、GPUの設計は粒度の低いHWスレッド管理となっており、テクスチャフェッチ、頂点フェッチなどのオペレーション時のレイテンシをある程度許容する設計となっている。ストアフォワード処理に対してテクスチャフェッチと同程度のレイテンシで対応できるのであれば許容範囲と考えられる。

といった点から、いつか来るべき未来にはGPU内部でのキャッシュコヒーレンシ問題も解決されるのでは、と考えている。
ただし、キャッシュコヒーレンシを解決する手法以外にも、現行のGPUの制限を撤廃する手法として別のアプローチも考えられる。ありうる方向性としては以下のようなものだろうか。

Parallel Data Cache@nVidia路線
　Parallel Data Cacheはサイズ16KBのシェーダ全体からアドレッシング可能なレジスタファイルかと思われる。Parallel Data Cache上でのコヒーレンシ維持については不明だが、おそらくはアトミックなアクセス命令が用意されているのではないだろうか？
Parallel Data Cacheの方向性の行き着く先としては、キャッシュサイズの増大、要するにCELLによく似た思想かと思われる。CELLの256KBのローカルストア内ではGPU処理が難しいことはPS3が身を呈して証明してくれている。今後64MB超の混載RAM容量が可能になれば、あるいは現実的になるのかも。
ラスタオペレーションのプログラマブル化
パイプライン後方の　アルファ/ステンシル/深度テストからラスタオペレーションに至る道のりを別途プログラマブルにする、という道。A-Buffer/R-Buffer/その他大勢Bufferの方向性といえる。ラスタオペレーション部分だけをDoughterDieにするという（どこかで聞いたような）アプローチにも適用しやすく、結構現実的なソリューションかもしれない。
GPUキャッシュのコヒーレンシを何とかする
今回考えてみた道筋。ATI/AMDの汎用演算リソース的なGPUの方向性からすると、こちらのほうが汎用的で良い感じなのではないか。GPUが汎用DSPとして脱皮するためには乗り越えるべきハードルであろう、と勝手に想像する。

写真は近所のマクドナルドの遊具コーナーと星条旗とマクドナルド旗。
マクドナルドの遊具コーナーは子連れには重宝する。

さてGDC2007も無事に終わり、ほっと一息、と二週間くらいのんびりすごす。
GDCでは多くの知り合いに久々に再開できてうれしい。
ますます巨大化しているGDCだが、自分としては数年前から、セッションの内容云々よりは社交の場、ヒントをもらう場と割り切っている。書籍コーナーも意外と役立つが。ともあれ、ゲーム開発者の技術共有の場としての初期の目的からはすでに大分変節している感がある。

本年は次世代機向けのプロジェクト第一世代が一巡したこともあり、巨大or肥大プロジェクトを振り返る的な内容に注目した。
ほとんどに共通していたのは、より効率的に製作工程の試行錯誤（Iteration）ができるように、環境を整えましょうという点。欧米デベロッパのツール至上主義はずいぶん昔から兆しはあった。８年前に訪問したとある西海岸デベロッパに「ツールプログラマのポジションが一番高い」といわれ「ひょえーそんなもんかいな～」いう印象があった。（当時はアプリケーションのプログラマが花形で、ツール作成チームはちょっと地味な存在だった）。そうした傾向も、ここに来て花開いた感がある。
今日では大規模チーム内でのエンジニアの役割はほぼツール製作とエンジン製作で、基本的にはゲームコンテンツ作成には携わっていない。内製ツール外販によるエンジンミドルウェアの勃興も基本的には同じバックグラウンドだろう。

その他聴講したセッションについてつらつらと。
TR1:C++OntheMove
聞きたかったセッションだが徹夜明けで寝坊。ｶﾞｶﾞｰﾝ
仕方がないのでオーディオファイルを入手して聞く。プレゼンがわかりやすいのと、彼は長年のMyボスだったので聞きとりに苦がない(これ大事)。
話としてはTR1について。Boost系のライブラリをすでに使っている面にはそれほど新規性はないかもしれない。

http://www.tantalon.com/pete.htm
↑のページにあるプレゼン資料も非常に有用。

From "Ouendan!" to "HELP!": Inside the Elite Beat Agents
「押忍！闘え！応援団」のローカライズについて。「応援団」は英語ローカライズに際して大胆に内容を変更してスマッシュヒットに成功。こうしたローカライズが可能だったのはチームのバイ・カルチャー性に依存するのかな～、とふと思う。

Under the Compiler’s Hood: Supercharge Your PLAYSTATION3 Code
SNSystemのエンジニアのコンパイラ最適化の話。聞くに、かなりバランスの悪いコンパイラという印象が強まる。
言語仕様向けの汎用的な最適化と、PS3向けの非常に野心的な機能を同時に実装中。「プラットフォーム非依存のコード生成を先になおした方が良いんで無いかなー」という印象。
http://www.snsys.com/news/23010701.asp

Designing GEARS OF WAR: Iteration Wins
Gears Of Warのデザイン時には試行錯誤を繰り返しましたよ、という話

Developer's Game Choice Award
http://www.gamechoiceawards.com/
本年も波乱なく、本命「Gears Of War」がChoceAward取得。「大神」が直接の受賞はなかったが多くにノミネートされていたのが印象的。また、例によってEA系のタイトルがことごとく無視されていたのも印象的。

Keynote: A Creative Vision - Shigeru Miyamoto (Nintendo)
宮元茂氏＠任天堂のキーノート。詳細は
http://www.famitsu.com/game/news/2007/03/09/103,1173397229,68263,0,0.html
等に詳しい。
「執念」をもって取り組むという点に感銘を受ける。実現したい事柄に関しては決してあきらめずに、10年でも20年でも、実現するか、命果てるまで続けることが必要という点は非常に感銘を受ける。「苔の一年岩をも通す」というか。一歩間違うと人生を棒に振るため万人には推奨されないかとおもうが、そんな生き方もありかと思う。

Final Fantasy XII Postmortem
FinalFantasyXIIの開発ツールについて。後で聞くと、去年のCEDECでの講演と同じコンテンツであったらしい。
会場の反応としてはやや薄い。講演のメッセージとしては、「ツールを整備してIterationできる環境を整えました」という他のセッションと同様なのだが、同通の所為もあり、メッセージがうまく強調できなかった気配。
社内ツールの命名センスはヒット。「モーションさん」等。

Real World SPU Usage
SCEの1stPartyタイトルではSPUをこんなことに使いました、という話。収穫としてはAI等の汎用Scalar処理もガンガンSPUに振っているという点。当たり前といえば当たり前だが、キャッシュミス一発でひたすらストールできるPPE環境よりは、SPU内で無駄は有れどもScalar処理をさせてしまっても幸せになれる、という話。

Reflections of Zelda
Zeldaの開発プロセスについて。
これもまた「試行錯誤の繰り返し」の一言に尽きる
http://plusd.itmedia.co.jp/games/articles/0703/09/news111.html

Taking Control of Your Middleware
ミドルウェアを採用するときには何がポイントか？
・全ての利点と欠点を検討して採用を決めましょう
・サポート経費を含むトータルコスト、サポートできる質問件数はいくつか、OnSiteサポートを依頼するときの経費、上限は？
　など契約内容を精査しましょう
・常に複数の選択肢を持つようにして、バックアッププランを用意しておくこと
等が語られる。

Sort-Independent Alpha Blending
http://www.houmany.com/htmls/grafx.html
半透明マテリアルのアルファソート無し描画をPixelShaderにて実現しようという試み。原理的には、高Precision（16bit推奨）のカラーバッファにカラー値、Alpha値、コンスタント値をTweakしながらストアし、第二パスでデコードして近似値を求める、というもの。4段階重ね合わせまでのサポート。
実用的には微妙なところ。
アルファソート問題の解決については、(次世代GPUでは対応されると思われる)GPU内でのキャッシュコヒーレンシの問題が解決されれば、シェーダ内からのDestBuffer参照によって解決可能な問題だ。（A-Bufferの実装でも対応可能だが、A-BufferのHW実装はややAdhocな感じがする）今後のGPUに期待。