Cell Task Manager Cerium の
SPU内データ管理

多賀野海人、小林佑亮、宮國渡、河野真治

琉球大学

Apr, 24, 2009

研究の背景と目的

研究背景

  • Cell に搭載されている SPE は Local Store (256KB) にしかアクセスできない。

  • メインメモリにアクセスするには MFC を用いて Direct Memory Access 命令を 送らなければならない。

  • また、この DMA には待ち時間が存在する。待ち時間の間 SPE が動作しなければマルチコアプロセッサのパフォーマンス が極端に下がる。

研究の背景と目的(Con't)

研究目的

  • SPE 内のデータ管理を行い Cell プログラミングの並列度を確保する手法を提案する。

  • 本研究室で開発した Cerium というの Rendering Engine を 用いたゲームプログラミングを例題とする。

  • 描画に必要な Texture データは、SPE の LS に収まりきらない場合があるので、 データを分割して転送、処理する必要がある。

  • 既に SPE 内にデータが転送されている場合、そのデータの管理を SPE 内で行うことによって、 DMA 転送待ち時間の間も SPE 内での処理を継続させる。

発表の流れ

  • Cell アーキテクチャの概要
  • Cerium
  • Rendering 部分の高速化
  • 比較
  • まとめと今後の課題
    •

Cell アーキテクチャの概要

  • Cell アーキテクチャの概要
  • Cerium
  • Rendering 部分の高速化
  • 比較
  • まとめと今後の課題
    •

Cell Broadband Engine

pipeline
  • 1 個の PPE と 8 個の SPE がリングバスで構成されている
    • Linux 側から使える SPE は 6 個
  • SPE は 256KB の Local Store (LS) を持つ
  • SPE からメインメモリへ直接アクセスできない
    • SPE が持つ MFC (Memory Flow Controller) へ DMA 命令を送ることで行う
  • SPE は 128 ビットレジスタを 128 個持っている

Cell の基本機能

  • DMA (Direct Memory Access)

    • DMA とは CPU を介さずにデータ転送を行う機能。

    • SPE は LS(256KB) にしかアクセスできない。

    • メインメモリにアクセスするには、
      MFC を通して DMA 転送命令を送る

    • LS にデータが転送されているあいだ、
      SPE のプログラムは停止させたくない

    • SPE で処理したデータは MFC を介してメインメモリへ転送される

Cell の基本機能 (Con't)

  • DMA 転送には待ち時間が存在する。
  • 待ち時間の間 SPE 有効に使わなければ、マルチコアプロセッサのパフォーマンスが極端に下がる。
    1. Task のデータを読み込む (1)
    2. 読み込んだデータの処理 (2) を行っている間に次の Task のデータを読み込む
    3. 処理したデータの転送 (3) の間に、2 で読み込んだデータの処理、次の Task のデータの読み込みを行う
      4.
    pipeline

Cerium

  • Cell アーキテクチャの概要
  • Cerium
  • Rendering 部分の高速化
  • 比較
  • まとめと今後の課題
    •

Cerium

PS3 ゲーム開発用フレームワーク
Cerium
  • Scene Graph
    • ゲームに登場するオブジェクトやルールなど、ゲームを構成する要素をもつ木構造
  • Rendering Engine
    • Cerium 独自
  • Task Manager
    • Task と呼ばれる分割された各プログラムを管理するライブラリ

Scene Graph

sg
  • Blender [1] で生成したオブジェクトを独自の XML 形式で出力
  • XML が持つ情報 (頂点座標、テクスチャ座標、イメージ) などから SceneGraphNode を生成
  • ポリゴン情報の他に、オブジェクトの操作 (move、
    collision) を持つ

　　　　[1]オープンソースの3Dモデリングツール

Rendering Engine


rendering
  • SG2PP
    • SceneGraph を操作後、ポリゴンに変換し PolygonPack (ポリゴンの集合)を生成する
  • PP2SP
    • ポリゴンの中から、Span (ポリゴン内にあるx軸に水平な線分) を抽出し、 SpanPack (Span の集合)を生成する
  • DrawSpan
    • Span を使って 1 ラインずつ FrameBuffer に描画していく

Rendering Engine (Con't)


byouga

Task Manager

Task と呼ばれる、分割された各プログラムを管理する

  • Task の単位はサブルーチンまたは関数
  • Task 同士の依存関係を考慮する
    • /* task2 は task1、task3 の終了を待つ */
task2->wait_for(task1);
task2->wait_for(task3);
  • 実行可能になった Task を各 SPE に割り振る
    • /* SPE1で実行する */
task1->set_cpu(SPE_1);
/* SPEのどれかで実行する */
task2->set_cpu(SPE_ANY);
/* PPEで実行する  */
task3->set_cpu(PPE);
  • C++ で実装

Rendering 部分の高速化

  • Cell アーキテクチャの概要
  • Cerium
  • Rendering 部分の高速化
  • 比較
  • まとめと今後の課題
    •

Rendering 部分の高速化

  • SPE の LS は256KB しかないので、Texture 情報を一度に転送すると容量を超えてしまう可能性がある。
  • そこで、描画に必要な Texture データを分割、転送するという手法を用いる。

    • pipeline

Rendering 部分の高速化 (Con't)

  • Tile Array を用いた Rendering
    • Polygon の Span から、描画に必要な Texture A を含む Tile を計算する

    • Tile を SPE に転送し、Tile の中の pixel 情報 (RGBα値) を取得して描画を行う
    pipeline

Scale

  • Texture の縮小画像の作成

    • 描画されるオブジェクトが小さい場合、そのままの大きさの Texture は必要ない

    • Span の長さと、縮小 Texture の大きさが一致するような Scale の縮小 Texture を選択する

    • Texture は縦横ともに 1/2、1/4、1/8 と、2分の1ずつ縮小させる (最小 8x8 pixel)

pipeline

Scale の効果検証

  • １０個のオブジェクトを用いたサンプル
    • Polygon 総数 は 19860
    • Texture は合計 10 枚
      ( 8x8(3)、512x384(2)、616x123(4)、1024x768(1) )
    pipeline

実行結果（速度検証）


    Architecture Scale なし (FPS) Scale あり (FPS) 速度の向上(%)
    Mac OSX 7.0 8.5 21
    PS3Linux (SPE 1) 4.3 5.6 30
    PS3Linux (SPE 6) 10.8 13.5 25
    Scale を用いることによる実行速度の比較

  • 実行速度の比較を行った結果、20 ~ 30% の速度向上が見られる。

  • Mac OSX は SDL 経由で出力、PlayStation 3 は Frame Buffer へ直接出力している。

実行結果 (考察)

  • SPE 1 個のときの速度と SPE 6 個のとき

    の速度で台数効果が出ていない

  • 考えられる原因

    • DMA 転送待ち時間が隠されていないため遅くなっている (Amdahl則)


  • Amdahl則：例えば SPE を 6 個使えたとしても、すべ
    ての SPE に常に処理を行わせている状態を保たなけれ
    ば、実行速度は著しく低下する。

キャッシュ

  • SPE 上の Texture データのキャッシュの有効性を検証する
  • キャッシュを用いた場合と用いてない場合を SPE の数を変更して比較する (1920x1080の画像の表示をサンプルとして使用)

キャッシュ なし キャッシュ あり
SPE 1 個 0.08 FPS 0.42 FPS
SPE 6 個 0.59 FPS 2.54 FPS
キャッシュの有無による処理速度の比較
  • キャッシュ有りと無しとで処理速度の向上が見られる

他システムとの比較

  • Cell アーキテクチャの概要
  • Cerium
  • Rendering 部分の高速化
  • 比較
  • まとめの今後の課題
    •

比較 - OSMesa (Gallium)

  • 先行研究 (神里)
    • 現在 PS3Linux からは GPU にアクセスできない
    • frame buffer は使用できる ため、OSMesa を使用
    • OSMesa の機能の一部を SPE に乗せ、高速化に成功
    • ソースコードの複雑化を招いた
    • 以降のメンテナンスや機能の追加、改良が困難と判断し、独自に Rendering Engine を持つことに
  • Gallium
    • OSMesa の Cell Driver
    • OpenGL で動作
    • PS3 上のゲーム開発において、レンダリングのみを SPE に実装するのでは足りない
      • ゲームに登場するオブジェクトの計算 (衝突判定等)
      • Amdahl 則の問題
    • レンダリングだけでなく、ゲームオブジェクトも SPE で処理できるように しなければならない

比較 - Gallium (Con't)

  • 実行速度比較
    • 出力解像度は 1920x1080
    • 地球のテクスチャを貼った球体のオブジェクトを表示
com_gallium
 ポリゴン数 : 1984
Gallium (SPE 6 個) 5.4 FPS
Cerium (SPE 1 個) 2.5 FPS
Cerium (SPE 6 個) 9.5 FPS
  • Gallium には OpenGL API の機能が全て乗っているわけではない
  • Cerium とのレンダリングの機能の違い
    • 光源、アルファブレンディング、etc..

比較 - OpenGL

OpenGL
オープンソースの3Dグラフィックスプログラムインターフェース
  • 変換行列、光源、カメラなどの API を実装
  • 親子関係の表現も可能

Cerium での OpenGL の使用の問題

  • SceneGraph の OpenGL の API にあわせるオーバーヘッド
  • SceneGraph は自身の変換行列を持っている
    • SceneGraph 単体でオブジェクトの操作は可能
  • SceneGraph だけで問題ない

まとめと今後の課題

  • Cell アーキテクチャの概要
  • Cerium
  • Rendering 部分の高速化
  • 比較
  • まとめと今後の課題
    •

まとめ

  • Scale による DMA 待ち時間の有効活用と、SPE 上の Texture データのキャッシュの有 効性を証明できた

  • DMA 転送の待ち時間の無駄を十分に利用できていない可能性が出たので、さらに SPE 上で行う処理を増やし待ち時間の有効活用を目指す。

今後の課題

  • SceneGraph の SPE 上での実行

  • プログラムコードの SPE 上での
    On demand load

    • 現在は予め全てのコードを SPE 上に置いておく必要がある

    • SPE のメモリ領域 (256B) を考えると好ましくない