--- a/paper/cell.tex	Sun Jan 30 03:25:41 2011 +0900
+++ b/paper/cell.tex	Sun Jan 30 06:22:21 2011 +0900
@@ -46,7 +46,7 @@
   \label{fig:ppe}
 \end{figure}
 
-\section{SPE (Synergistic Processor Element)}
+\section{SPE (Synergistic Processor Element)} \label{sec:spe}
 
 SPE には 256KB の Local Store (LS) と呼ばれる、SPE から唯一、
 直接参照できるメモリ領域があり、バスに負担をかける事無く

--- a/paper/cerium.tex	Sun Jan 30 03:25:41 2011 +0900
+++ b/paper/cerium.tex	Sun Jan 30 06:22:21 2011 +0900
@@ -181,14 +181,29 @@
 \item[spwan\_task\_array: ] Task Array の中のすべての Task が書きこまれたかどうかをチェックする。
 \end{description}
 
-また、仕様変更になった Task に引き渡すデータを管理する API (set\_inData, set\_outData, set\_param) について
-説明する。\\
+\section{Task の入出力}
+
+Task の入出力の API として、set\_inData, set\_param , set\_oudData がある。
+\begin{description}
+
+\item[set\_inData(index, addr, size)] は、 データを受け取る buffer の配列番号とデータのアドレス、そのデータのサイズを
+引数として入力する。このデータは DMA 転送されるため、addr は 16 byte alignment が取れており、size は 16 byte の
+倍数である必要がある。
+
+\item[set\_param(index, param)] は、データを受け取る buffer の配列番号と 32bit のデータを渡す。set\_inData で渡すには
+小さいデータを送るのに適している。 param はアドレスとしてではなく、値を Task オブジェクトが直接持っているので、 DMA 
+転送は行わない。
+
+\item[set\_outData(index, addr, size)] は、Task のデータの出力先を指定する。使用方法は set\_inData と同じで、alignment, 
+byte 数に気をつける必要がある。
+
+\end{description}
 
 これまで Task のデータは add\_inData, add\_outData, add\_param された順に read\/write buffer に書きこまれていた。
 しかし、これではデータ数が多くなった場合に管理するのが難しくなる恐れが出てきた。例えば、100個のデータをadd\_inData
 した場合、特定のデータを取り出す際にそのデータが何番目にadd\_inDataされたのかを知らなければならない。この問題を解決するために、
-in\/outのData と param を buffer の任意の場所に書き込めるように仕様を変更した。これは規模の大きな例題を作成するようになって
-分かった問題の一つである。
+in\/outのData と param を index を用いて buffer の任意の場所に書き込めるように仕様を変更した。
+これは規模の大きな例題を作成するようになって分かった問題の一つである。
 
 \section{Task Array}
 
@@ -202,8 +217,6 @@
 生じる可能性が減る。さらに Task Array の処理時間が長くなれば、DMA の転送時間を隠すことにも繋がる。Word Count 
 と Rendering Engine において、Task Array の効果を検証した\cite{jssst-yutaka}。
 
-\section{Task Array 化による検証}
-
 \subsection{Word Count の Task}
 
 まずは例題の Word Count の Task について説明する。 Word Count の Task は以下の二つである。
@@ -301,32 +314,75 @@
 効果が無かった。大量のファイルをマッピングし、メモリを多く消費するのでメモリアクセスに時間がかかり、DMA 
 転送に待ち時間が発生したと考えられる。それによって、Task Array を用いても DMA 転送時間を覆い隠すことが
 できなかった。dma 転送をスケジューリングによってうまく隠す、またはメモリ領域を節約することができれば、
-今回の Word Count のような大量のデータを用いる場合の速度向上が期待できる。
+今回の Word Count のような大量のデータを用いる場合の速度向上が期待できる。\\
+
+Task を実行している Scheduler に関する詳しい説明は \ref{implement} で行う。
+
+\section{SceneGraph} \label{sec:cerium_scenegraph}
+
+本研究では、ゲーム中の一つの場面 (Scene) を構成するオブジェクトやその振る舞い、ゲームのルールの集合を SceneGraph 
+とする \cite{chiaki}。SceneGraph のノードは親子関係を持つ tree で構成される(\figref{scenegraph})。親子関係とは、親オブジェクトの
+回転や平行移動などの行列計算による頂点座標の変更が、子オブジェクトにも反映する関係のことである。これは子に対して
+スタックに積まれた親の変換行列を掛けることで実現できる。SceneGraph ノードは以下のようなデータと動作を持つ。
+
+\begin{description}
+\item[Vertex:] ポリゴンオブジェクトの頂点座標
+\item[Texture:] ポリゴンオブジェクトのテクスチャ座標
+\item[TextureImage:] テクスチャイメージ
+\item[TransMatrix:] ポリゴンオブジェクトの変換行列
+\item[Coordinates:] オブジェクトの座標
+\item[Angle:] オブジェクトの角度
+\item[Move:] 自律的なオブジェクトの動き
+\item[Collision:] 他のノードと衝突したときの動き
+\end{description}
+
+\begin{figure}[htb]
+  \begin{center}
+    \includegraphics[scale=0.61]{./images/scenegraph.pdf}
+  \end{center}
+  \caption{SceneGraph}
+  \label{fig:scenegraph}
+\end{figure}
+
+\subsection{Scene ポリゴンの生成}
 
-\section{}
+ゲーム中に登場するオブジェクトは、オープンソースの 3D モデリングツール
+である Blender \cite{blender} を用いる。
+Blender で記述したポリゴンオブジェクトを、座標やテクスチャイメージを
+埋め込んだ xml ファイルとして出力する。
+Blender にはPython インタプリタがあり、杉山 \cite{chiaki} が独自形式の
+xml ファイルを生成する Python スクリプトを作成している。
+
+xml には、オブジェクトの名前、ポリゴン情報、ポリゴンに対応するテクスチャ座標、
+テクスチャイメージがある。
+
+xml ファイル形式を採用している理由は、Cerium が MacOSX や PS3 Linux などの
+複数の環境で動作することを目的としており、環境に依存しないテキスト形式での
+データ構造を構築できるからである。また、Cerium は将来的にネットワークを
+使用することを考えており、その際に有効なフォーマットであると考えたからである。\\
+
+ネットワークを使用した例題として、Federated Linda \cite{futita} \cite{akamine}
+を用いた「水族館ゲーム」を赤嶺が作成した。
+
+このゲームは、複数のクライアントのディスプレイを並べて使用する。各プレイヤーは１匹
+ずつ魚のオブジェクトが与えられ、それを自由に操作することができる。また、魚は画面の
+端まで移動すると、自分の画面上からは消え、接続している他のプレイヤーの画面の端
+から出てくる。(\figref{aquarium}) このゲームは、初めに xml ファイルをすべての
+プレイヤーが共有した状態で開始される。
+
+\begin{figure}[htb]
+  \begin{center}
+    \includegraphics[scale=0.61]{./images/aquarium.pdf}
+  \end{center}
+  \caption{SceneGraph}
+  \label{fig:aquarium}
+\end{figure}
+
 
 \begin{comment}
 \\ ###########################途中############################\\
 \end{comment}
 
-
-・Task を1種類に戻したい
-
-・spu側からmailを送ったときにキューに溜まるようにした
-
-・getsegmentを入れた理由
-
-・busy rate
-
-・queue info
-
-・tasklistのdependencyが変わってる
-
-・waitlistが残ってるのはdead lock deteption
-
-
-\section{SceneGraph} \label{sec:cerium_scenegraph}
- 
 ・sgidの追加
 
 \section{Rendering Engine} \label{sec:cerium_renderingengine}

--- a/paper/implement.tex	Sun Jan 30 03:25:41 2011 +0900
+++ b/paper/implement.tex	Sun Jan 30 06:22:21 2011 +0900
@@ -1,6 +1,18 @@
 \chapter{Task を用いたパイプラインの実装} \label{chapter:implement}
 
-\section{Task}
-\section{Scheduler}
+\section{CPU スレッドの実装}
+
+各 CPU では、メインスレッドで生成された Task を受け取り、その情報を元に Task を実行する。ここでは、Task を
+扱う Scheduler の実装と、Task の本体となる部分に付いて説明する。
+
+\subsection{Scheduler}
+
+生成された Task に従って実際の Task を実行するのが Scheduler である。Scheduler は、メインスレッドで
+生成された Task List を受け取り、その中にある Task, Task Array をパイプラインに沿って、
+
+・queue info
+・spu側からmailを送ったときにキューに溜まるようにした
+
+\section{Segment}
 \section{評価}
 

--- a/paper/master_paper.tex	Sun Jan 30 03:25:41 2011 +0900
+++ b/paper/master_paper.tex	Sun Jan 30 06:22:21 2011 +0900
@@ -6,7 +6,7 @@
 
 \input{dummy.tex} %% font
 
-\jtitle{マルチコア CPU における Task を用いたパイプラインの実装と検証}
+\jtitle{Cell Task Manager Cerium における \\ Task を用いたパイプラインの実装}
 \etitle{}
 \year{平成22年度}
 \affiliation{\center%
@@ -25,7 +25,7 @@
 \end{minipage}}
 \markleftfoot{% 左下に挿入
   \begin{minipage}{.8\textwidth}
-    Cell Task Manager Cerium
+    Cell Task Manager Cerium における Task を用いたパイプラインの実装
 \end{minipage}}
 
 \newcommand\figref[1]{図 \ref{fig:#1}}