ゲームフレームワーク Cerium TaskManager の改良

金城　裕, 河野　真治,
多賀野　海人, 小林　佑亮

琉球大学大学院理工学研究科情報工学専攻並列信頼研

概要

ゲームフレームワーク Cerium TaskManager を開発した。 Ceriumの改良を行い改良前と比べ、8倍の性能向上を達成した
例題 改良前 改良後 性能差
ball bound 4.4FPS 37.7FPS 約8倍
FPS(Frames Per Second)

概要

Amdahlの法則より
　プログラム全体の並列化率が低ければ、マルチコアの性能を活かすことはできない。並列化率が80%から100%になる間に性能は3倍向上する(6コアの場合)

概要

改良のまとめ(ball_bound)
SPEの稼働率を落とさない為の改良点
PPEとSPE間の通信回数を削減、タイミングを変更。 Taskのパイプライン化。 テクスチャをSPE内でキャッシュ。
以上の改良により、FPSが8倍程度性能向上があった

Cellの構成

Cell Broadband Engine

Cellの基本機能

DMA Mailbox

Ceriumの構成

Ceriumの構成

TaskManager

TaskManager は、Taskと呼ばれる分割された各プログラムを管理する。Task の単位 はサブルーチンである。Task 同士の依存関係を考慮しながら実行していく。

Task を生成する際に、以下のような要素が設定可能である

RenderingEngineの構成

RenderingEngineの構成

RenderingEngineの例題

ボールが跳ねる例題 : ball bound

改良前RenderingEngine

改良前のRenderingEngine例題

解像度 1920x1080

FPS DMA転送待ち mail待ち SPE稼働率
ball_bound 4.4FPS 0.4% 53.4% 46.2%

アムダール則からmail待ちの時間を解消しないと性能は上がらない

SPEの稼働率を向上させる改良点を紹介していく
　・テクスチャをSPE内でキャッシュする
　・Mailの数の削除、タイミングを変更
　・RenderingTaskのパイプライン化

SPEキャッシュの効果

SPE内キャッシュの目的
頻繁に扱うテクスチャはキャッシュしたほうが、DMAロードする時間が省けるはず.という事で SPE内にテクスチャのキャッシュを用意した

キャッシュ効果訂正(1/2)

もともとSPE内のキャッシュにHITしないバグがあった
そこを発見修正し、「キャッシュなし」の場合と比較した表
SPEのキャッシュの効果(ball_bound)
キャッシュ FPS DMA転送待ちの割合 mail待ちの割合 SPE稼働率
無(誤) 4.4FPS 0.4% 53.4% 46.2%
有 30FPS 3% 80% 17%

キャッシュの処理を無効にしきれてなかった.キャッシュにHITはしないが キャッシュ操作は行われていた.

キャッシュ効果訂正(2/2)

正しいSPEのキャッシュの効果(ball_bound)
キャッシュ FPS DMA転送待ちの割合 mail待ちの割合 SPE稼働率
無(誤) 4.4FPS 0.4% 53.4% 46.2%
無 28FPS 6.5% 79% 14.5%
有 30FPS 3% 80% 17%
・キャッシュの操作は 1Fream で8000回x100で、重い処理となっていると考えられる
・キャッシュがきちんとHITすれば、キャッシュの効果はある

TaskArray

SPEとPPEの間のやり取りは、Mailを用いている 依存関係はグループ化できる
複数のTaskのMailを一つにするTaskArrayを実装した.

TaskArray

TaskArrayの効果を表に示す
TaskArrayの効果(ball bound)
キャッシュ FPS DMA転送待ちの割合 mail待ちの割合 SPE稼働率
改良前 30FPS 3% 80% 17%
改良後 35.5FPS 3% 70% 27%
Task毎のリプライMailが減り、PPEの応答スピードが向上させる目的 5FPSの向上がみられ、10%mail待ちが減少した

MailQueueの効果

SPEとPPEの間のやり取りは、Mailを用いている
ソフト的に別な書き込みキュー(MailQueue)を実装した。 ハードなキューに書き込めない場合にmailQueueへ書きこむ。書き込みスロットが1から 複数になった

MailQueueの効果

MailQueueの効果(ball bound)
MailQueue FPS dma待ち mail待ち 稼働率
なし 35.5FPS 3% 69% 27%
あり 35.7FPS 3% 69% 27%
Mail書き込みのタイミングをずらせる。Taskが足りなくなった時点で溜まった分の精算する が結果的にあまり効果がないのは、精算する際に同じぐらい待ちは発生すると考える
今後mail待ちの細かい内訳が必要

パイプライン化の効果

RenderingEngineの3つのTaskはバリア同期を行い、逐次的に実行されていた。
そこで、DrawSpanTaskほ他の二つと並列に実行されるように改良した

パイプライン化の比較

パイプライン化の効果(universe)
Pipeline化 FPS dma待ち mail待ち 稼働率
なし 35.7FPS 3% 69% 27%
あり 37.7FPS 2% 66% 31%
mail待ちが3%減少、FPSが2向上した。 DrawTaskに他のRenderinTaskが隠れたと考えられる。

改良のまとめ

これまでの改良のまとめ(ball_bound)
最終的にSPEの稼働率は14%削減できた。FPSは8倍に向上。

OpenGLとの比較

OpenGL(Open Graphics Library)とは、Silicon Graphics社が開発した、3Dグラフィックス処理の ためのプログラミングインターフェース。PPEのみで動作するOpenGLと処理速度の比較をした。
比較する例題には学生が実験中に作成したSuperDandyを用いた。

OpenGLとの比較

OpenGL Cerium 性能差
dandy 17.5FPS 49.5FPS 2.9倍
コア一つを使用するOpenGLに比べ、Cerium では2.9倍の性能向上が見られた。 SPEを活用、待ち時間の短縮を行い、性能向上がみれた。

今後の課題

処理全体の並列化率の向上
以下の部分をSPE実行し、並列化率を向上させる それにはCode Loadが必要(実装済み、まだ使ってない) さらに細かいプロファイリング(ex.mail待ちに細かい内訳)
[any material that should appear in print but not on the slide]