--- a/paper/abstract.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/abstract.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -1,16 +1,17 @@
 \begin{abstract}
 $B2f!9$O2HDmMQ%2!<%`5!$G<B9T$9$k%*!<%W%s$J3+H/%U%l!<%`%o!<%/$K4X$9$k8&5f$r(B
 $B9T$C$F$-$?!#2HDmMQ%2!<%`5!$NB?$/$OFC<l$J%"!<%-%F%/%A%c!<$G$"$j!"%"!<%-%F(B
-$B%/%A%c!<$KD>7k$7$?%W%m%0%i%_%s%0$b;_$a$i$l$k!#$7$+$7!"$=$N$h$&$J%W%m%0%i(B
-$B%_%s%0%9%?%$%k$O3X@8<B83$G;HMQ$9$k$H!"%W%m%0%i%`$NM}2r$K;~4V$r<h$i$l!"K~(B
-$BB-$9$k%2!<%`3+H/$,9T$($J$$!#(B\\
+$B%/%A%c!<$KD>7k$7$?%W%m%0%i%_%s%0$r5a$a$i$l$k!#$7$+$7!"$=$N$h$&$J%W%m%0%i(B
+$B%_%s%0%9%?%$%k$O3X@8<B83$G;HMQ$9$k$H!"%W%m%0%i%`$NM}2r$K<B83$N;~4V$NLs(B2/3$B$r<h$i$l!"3+H/$,9T$($J$$!#(B\\
 $B$=$3$G2f!9$O(BPlay Station 3$B>e$G$N%2!<%`%W%m%0%i%_%s%0$N$?$a$K?7$?$J%U%l!<(B
 $B%`%o!<%/$rDs0F$9$k!#(B\\
-Play Station 3$B$N(BCell Broadband Engine$B%"!<%-%F%/%A%c!<(B
+PlayStation 3$B$N(BCell Broadband Engine$B%"!<%-%F%/%A%c!<(B
 $B$O#1$D$N@)8f7O%W%m%;%C%5(BPower Processor Element(PPE)$B$H(B7$B$D$N%G!<%?=hM}1i(B
 $B;;%W%m%;%C%5(BSynergistic Processor Element(SPE)$B$+$i9=@.$5$l$k!#(B
+$B$7$+$7!"(BPlayStation3$B$O(BGDP$B$r3+J|$7$F$$$J$$!#$=$N$+$o$j!"(Bps3fb$B$H$$$&%U%l!<%`%P%C%U%!$r;H$&$3$H$O$G$-$k!#$=$3$G(BMesa$B$H$$$&%0%i%U%#%C%/%9%i%$%V%i%j$N(BOSMesa$B$H$$$&%U%l!<%`%P%C%U%!%(%s%8%sMQ$N%l%s%@%j%s%0%(%s%8%s$rMQ$$$F3+H/$r9T$C$F$$$?!#(B\\
 $B:G=i2f!9$O(BPPE$B$N$_$r;HMQ$7!"(BOSMesa$B$G%2!<%`%W%m%0%i%_%s%0$r9T$C$F$$$?!#$7(B
-$B$+$7!"$=$l$G$O(BCell$B$NFCD'$G$"$kJBNs@-$J$I$,;HMQ$5$l$:!"B.EY$KK~B-$J7k2L$r(B
+$B$+$7!"$=$l$G$O(BCell$B$NFCD'$G$"$kJBNs@-$J$I$,;HMQ$5$l$:!"Ls(B18FPS
+$B$7$+(B
 $BF@$k$3$H$,$G$-$J$+$C$?!#$=$3$G(BOSMesa$B$K<j$r2C$($F!"0lIt$N5!G=$r(BSPU$B$K1i;;(B
 $B$5$;!"9bB.2=$r?^$C$?!#$7$+$7!"(BOSMesa$B$O5!G=$rA}$d$7$?7k2L!"M>7W$J1i;;$,A}(B
 $B$(!"%=!<%9%3!<%I$OJ#;($G<j$r2C$($k$3$H$,Fq$7$+$C$?!#(B

--- a/paper/bibliography.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/bibliography.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -1,5 +1,5 @@
 \begin{thebibliography}{99}
-\bibitem{cell broadband engine}
+\bibitem{Cell broadband engine}
   林 宏雄 . ``Cell Broadband Engine概要 : その設計思想と応用例(デジタル・情報家電, 放送用, ゲーム機用システムLSI, 及び一般)``.
   コンシューマエレクトロニクス研究会2007,Dec
   \bibitem{scenario}

--- a/paper/cell.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/cell.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -1,14 +1,14 @@
 \chapter{CELL BROADBAND ENGINE}
-\section{cell broandband engineの構造}
+\section{Cell broandband engineの構造}
 ここでは研究・実験題材の対象となったCellというアーキテクチャーについて説
 明する。CellはメインプロセッサであるPowerPC Processor Element(PPE)と6個
-のデータ処理プロセッサアーキテクチャーSynergistic Processor Element(SPE)からな る非対称なマルチコアプロセッサでなり、高速リングバスで構成されている。(図\ref{fig:cell})
+のデータ処理プロセッサアーキテクチャーSynergistic Processor Element(SPE)からな る非対称なマルチコアプロセッサでなり、高速リングバスで構成されている。(図\ref{fig:Cell})
 \begin{figure}[htb]
 \begin{center}
-\includegraphics[width=17cm]{./fig/cell.eps}
+\includegraphics[width=17cm]{./fig/cell3.eps}
 \end{center}
-\caption{cell}
-\label{fig:cell}
+\caption{Cell}
+\label{fig:Cell}
 \end{figure}
 \\
 PPEはCell Broadband Engineのメインプロセッサで、複数のSPUをコアプロセッ
@@ -16,13 +16,11 @@
 %Cellの内部でのデータ通信はDMAで行われCPUに負担をかけない。\\
 \subsection{spe}
 SPEは
-%128個の128ビット汎用レジスタと256kbのローカルストア(LS)と呼ばれる専用メモリを備えたSIMD構成のアーキテクチャーとなっており、
 PPEのような複雑な制御よりも計算を単純に繰り返すマルチメディア系の処理を得意とする演算系プロセッサコアである。(図\ref{fig:spe}参照)
-%メインメモリ上のプログラムとデータは直接扱えず、MFCを用いてメインメモリとLS間の転送を行う必要がある。
-SPUとMFCから構成され、SPUは独自規格の命令セットを持ち、各々のSPUはLocal Store(LS)とよばれる256kbのメモリ量を持ちます。LSは各SPUから直接参照できる唯一のメモリです。MFCはメインメモリや他のSPEなどとデータをやり取りするためのユニットで、SPUはチャネルというインタフェースを介してMFCに対してデータ転送などを依頼し、各々のSPUが持つLSにメインメモリ上のデータなどを転送します。
+SPUはSPUとMFCから構成され、独自規格の命令セットを持っている。各々のSPUはLocal Store(LS)とよばれる256kbのメモリ量を持ち、各SPUから直接参照できる唯一のメモリとして存在する。MFCはメインメモリや他のSPEなどとデータをやり取りするためのユニットで、SPUはチャネルというインタフェースを介してMFCに対してデータ転送などを依頼し、各々のSPUが持つLSにメインメモリ上のデータなどを転送する。
 \begin{figure}[htb]
 \begin{center}
-\includegraphics{./fig/spe.eps}
+\includegraphics[height=8cm]{./fig/spe.eps}
 \end{center}
 \caption{spe}
 \label{fig:spe}
@@ -34,23 +32,16 @@
 % wikipedia
 % SPE単体の図とか
 % とりあえず保留
-\section{cellの基本機能}
+\section{Cellの基本機能}
 \subsection{SIMD}
 Cellは基本的にあらゆるものを並列的に計算できるような構造になっている。SPUに実装されている128ビットレジスタもSIMDを行うために設計されている。通常は32ビットのデータを4回計算できるところを1回の計算で行うことができる反面、すべての演算を128ビットで計算するため、なるべく効果的に演算を行うように工夫する必要がある。
 \begin{verbatim}
 int a,b,c;
 a = b + c;
 \end{verbatim}
-に対しても、図\ref{fig:simd} のような演算を行う。
-\begin{figure}[htb]
-\begin{center}
-\includegraphics{./fig/simd.eps}
-\end{center}
-\caption{SIMD}
-\label{fig:simd}
-\end{figure}
+に対しても、128ビット演算を行う。
 \subsection{メールボックス}
-メールボックスは、PPEとSPE間で通信するための機構の一つです。DMA転送はメインメモリとLSとの間で最大16Kバイトの大きなデータの受け渡しを行います。それに対し、メールボックスはステータスの変化などの小さなデータ受け渡し向けで、PPEとSPEとの間で双方向のデータの受け渡しが可能で、FIFOキュー構造になっており、3つの振る舞いができるよう設計されています。(図\ref{fig:Mailbox}参照)\\
+メールボックスは、PPEとSPE間で通信するための機構の一つである。DMA転送はメインメモリとLSとの間で最大16Kバイトの大きなデータの受け渡しを行う。それに対し、メールボックスはステータスの変化などの小さなデータ受け渡し向けで、PPEとSPEとの間で双方向のデータの受け渡しが可能で、FIFOキュー構造になっており、3つの振る舞いができるよう設計されている。(図\ref{fig:Mailbox}参照)\\
 \begin{figure}[htb]
 \begin{center}
 \includegraphics[width=17cm,height=10cm]{./fig/Mailbox.eps}
@@ -60,15 +51,15 @@
 \end{figure}
 \begin{enumerate}
 \item SPU Inbound Mailbox\\
-	PPEからSPEへデータを渡すためのキューで、最大４個までのデータを蓄積できます。もし、SPEがキューを読むときにキューにデータをない場合は、キューにデータが書き込まれるまで待ち続けます。
+	PPEからSPEへデータを渡すためのキューで、最大４個までのデータを蓄積できる。もし、SPEがキューを読むときにキューにデータをない場合は、キューにデータが書き込まれるまで待ち続ける。
 \item SPU Outbound Mailbox\\
-	SPEからPPEへデータを渡すためのキューでSPU Inbound Mailboxと同様にデータがない場合はデータが書き込まれるまで待ち続けます。一番の違いはデータが１個までしかキューに格納できないことです。
+	SPEからPPEへデータを渡すためのキューでSPU Inbound Mailboxと同様にデータがない場合はデータが書き込まれるまで待ち続ける。一番の違いはデータが１個までしかキューに格納できないことである。
 \item SPU Outbound Intterupt Mailbox\\
-	SPU Outbound Mailboxとほとんど同じですが、SPU Outbound Interrupt MailboxではSPEからキューにデータが書き込まれると、PPEに対して割り込みイベントが発生しデータの読み出しタイミングを通知することができます。
+	SPU Outbound Mailboxとほとんど同じだが、SPU Outbound Interrupt MailboxではSPEからキューにデータが書き込まれると、PPEに対して割り込みイベントが発生しデータの読み出しタイミングを通知することができる。
 \end{enumerate}
 \section{開発環境}
 \subsection{libspe2}
-libspe2とはPPUがspeを扱うためのライブラリ郡である。\cite{libspe2}libspe2はSPE Context Creation、SPE Program Image Handling、SPE Run Control、SPE Event Handling、SPE MFC Problem State Facilities、Direct SPE Access for Applicationsという基本構成でできている。cellに基本プログラムは次のようになる。
+libspe2とはPPUがspeを扱うためのライブラリ郡である。\cite{libspe2}libspe2はSPE Context Creation、SPE Program Image Handling、SPE Run Control、SPE Event Handling、SPE MFC Problem State Facilities、Direct SPE Access for Applicationsという基本構成でできている。Cellに基本プログラムは次のようになる。
 
 \begin{enumerate}
 \item create N SPE context
@@ -90,7 +81,7 @@
 \end{table}
 このようにCell特有の関数やアセンブラ命令を学ぶことが必要となる。
 \section{SPURS}
-ここでは現在発表されているCellの開発環境SPURSについて説明する。\cite{spurs}
+ここでは現在発表されているCellの開発環境SPURS\cite{spurs}について説明する。
 SPURSとは閉じた並列分散と考えることができるCellの環境でいかに効率よく動作させるかということを考たシステムである。Cellの性能を存分に生かすためにはSPEを効率よく使い切ることとあらゆるレベルで並列処理を行うことである。SPEを効率よく使い切るにはSPUの動作を止めることなく、同期を最小限に行う必要がある。\\
 そこでSPURSではSPUを効率よく利用するために、PPUに依存せずにSPUコードを選択し、実行することと機能は効率重視で割り切ることを挙げている。そのためにSPUにカーネルを組み込んでいる。\\
 アプリケーションを複数SPUで実行するとき、アプリケーションプログラムをできるだけ小さなタスクに分割し、通信ライブラリを用いてタスク間を依存関係で結合する。LS常駐のカーネルは実行可能なタスクを選んで実行する。(図\ref{fig:task})\\

--- a/paper/cerium.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/cerium.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -1,6 +1,6 @@
 \chapter{レンダリングエンジンの提案}
 \section{Cerium}
-我々は独自のレンダリングエンジンを持つことにした。そのレンダリングエンジンをCeriumとする。Ceriumは次の3つから構成される。\\
+我々はMesaのソフトウェアレンダリングエンジンであるOSMesaが分割しにくいこと、コピーが多いことなどの理由から独自のレンダリングエンジンを持つことにした。そのレンダリングエンジンをCeriumとする。Ceriumは次の3つから構成される。\\
 \begin{itemize}
 \item シーングラフ
 \item レンダリングエンジン
@@ -18,9 +18,10 @@
 \section{Ceriumの実装}
 \subsection{シーングラフ}
 シーングラフはゲームのシーンを構成するオブジェクトやその振る舞いの記述である。シーングラフはxmlをパースするところか始まる。blenderから生成されるxmlは以下のような構造を持っている。\\
+\small{
 \input{src/cube-p.xml}
+}
 このxmlにはblenderで記述されたすべてのオブジェクトの情報が記述されている。一つのオブジェクトに対し、サーフェイスの名前とサイズ、親のポリゴンの名前、それに対してcoordinate(ポリゴン情報)とtexture(ポリゴンに対応するテクスチャ座標)、テクスチャの$RGB\alpha$情報があり、シーングラフではそのxml情報をパースしてすべての情報をレンダリングエンジンに必要な構造体に直す。その上で、親子関係を考慮した回転や拡大縮小などを行う。\\
-%rotateや親子関係などを実装している。
 親子関係とは自転と公転のようなもので、例えば地球が自転すると、それに伴って月が公転するようなことである。それは子に対して親への変換行列がかけられている。それをスタック上に積んで計算する必要がある。(図\ref{fig:stack})\\
 \begin{figure}[htb]
 \begin{center}
@@ -35,7 +36,9 @@
 レンダリングエンジンは2つに分けることができる。spanを生成する部分と与えられたspanからテクスチャの生成する部分である。
 \subsubsection{spanを生成する部分}
 spanを生成するとき、シーングラフから必要な情報(polygonpack)が渡される。\\
+\small{
 \input{src/polygonpack.h}
+}
 polygonpackは光源の情報とテクスチャの情報と頂点の情報から構成される。TRIANGLEPACKというものがポリゴンに相当する物で、3つの頂点とそのポリゴンに対応するテクスチャの情報が格納されているアドレス、テクスチャの高さと幅が与えられている。３つの頂点にはx座標、y座標、z座標、テクスチャのx相対比、テクスチャのy相対比が与えられる。
 この与えられたpolygonpackの情報からspanの情報を出力する。spanを生成するコードはつぎのようになっている。\\
 \begin{figure}[htb]
@@ -45,7 +48,9 @@
 \caption{span生成時のポリゴン分割}
 \label{fig:half_triangle}
 \end{figure}
+\small{
 \input{src/polygonpack.cpp}
+}
 spanを生成するコードではポリゴンを上下二つの三角形に分割して計算している。
 vMid1という関数で図\ref{fig:half_triangle}のvMid10の部分にあたる部分の座標を計算し、上の三角形の頂点座標をhalf\_triangleという関数に渡している。half\_triangleではy座標ごとに右端と左端のx、z座標、テクスチャのx、y相対値を計算した後で、spanを生成している。しかし、このspan情報を単にPPUに送り返すと、PPUでspanをソートする必要が出てくる。それはOSMesaのときと同じく、SPUのメモリ量とzバッフぁ問題があるからである。そこで、PPUにDMA転送する前にy座標を8ごとにspanのリストを生成し、PPUに送信する。y座標が８毎にとっている理由はSPUが持てるzバッファが8ぐらいだろうという見解からくるものである。それを送信すると、PPUは次のようなメモリ空間を持つことになる。\\
 \begin{figure}[htb]
@@ -70,13 +75,6 @@
 \end{figure}
 その情報からテクスチャを計算して、ピクセル毎のRGB$\alpha$情報を取得する。しかし、SPUはメモリが256kbしかないため、すべてのテクスチャを送ることが不可能となる場合がある。それらを考慮し、テクスチャを分割する必要がある。
 テクスチャは8x8の大きさに分割される。(図\ref{fig:div_texture})\\
-\begin{figure}[htb]
-\begin{center}
-\includegraphics{./fig/div_texture.eps}
-\end{center}
-\caption{分割されたテクスチャ}
-\label{fig:div_texture}
-\end{figure}
 spanはそれぞれのテクスチャに沿ってspanを生成される。つまり、span一つにつき、分割したテクスチャ一つがDMAされる。
 \subsection{タスクマネージャ}
 タスクマネージャはSPUで実行される関数をタスクとしてQueueに登録し、タスクマネージャに実行命令が下ると、Queueに登録されたタスクが依存関係をみながら、実行されていくライブラリである。

--- a/paper/exploit_techinique.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/exploit_techinique.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -20,3 +20,14 @@
 \section{まとめ}
 我々は開発段階としてシーケンシャルなアルゴリズムでの実装、SPUにマッピングするデータ構造を用いたシーケンシャルアルゴリズムでの実装、Cellへのマッピングという風に開発を行った。そうすることで新たなゲーム開発環境ができたときもシーケンシャルなアルゴリズムから開発できるというメリットがある。またデバッグを行うことが難しい並列環境に置いても、それをより容易にデバッグすることを可能にした。
 
+\begin{figure}
+\begin{center}
+\includegraphics[width=17cm,height=20cm]{./fig/mindmap1.eps}
+\end{center}
+\end{figure}
+\begin{figure}
+\begin{center}
+\includegraphics{./fig/mindmap2.eps}
+\end{center}
+\end{figure}
+

--- a/paper/introduciton.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/introduciton.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -1,13 +1,13 @@
 \chapter{序論}
 \pagenumbering{arabic}
 家庭用ゲーム機の多くは特殊なアーキテクチャを基盤としており、特にPS3でのCellシステムを用いたゲーム開発時にはSPUを駆使した並列設計が求められる。しかし、学生実験に置いてCellアーキテクチャを理解した上でゲームを実装することは困難である。また
-他のゲーム機に移植する際には、アーキテクチャ間の差を埋めるためプログラムを大幅に書き換える必要がある。つまり、従来のCellアーキテクチャ上でのプログラム手法では、開発基盤の理解が必要であるということと、他アーキテクチャーとの汎用性が失われるという問題があった。\\
+他のゲーム機に移植する際には、アーキテクチャ間の差を埋めるためプログラムを大幅に書き換える必要がある。つまり、従来のCellアーキテクチャ上でのプログラム手法では、開発基盤を理解してプログラムを書くことには時間が必要であるということと、他アーキテクチャーとの汎用性が失われるという問題があった。\\
 Linux上のレンダリングエンジンとしてOSMesaがある。これはOS やハードウェアに依存しないオフスクリーンレンダリングライブラリである。しかしながらPlayStation3のPowerPCシングルプロセッサ上ではCellの性能はいかせない。そこでOSMesaに手を加えて、一部の機能をSPUに演算させることにより、高速化させた。
 しかし、OSMesaは機能を増やした結果、余計な演算が増
 え、ソースコードは複雑で手を加えることが難しかった。\\
-そこで我々はOSMesaを捨て、独自のゲームフレームワークを持つことにした。
-我々が提案するゲームフレームワークはOpen Scene GraphやJava3Dにも実装されているオブジェクトを木構造で持ち、より動きをスムーズにみせるシーングラフとOSMesaに代表されるレンダリングエンジン、taskと呼ばれる実行単位を動的にすべてのコアが動作するように設計されたSPURSに代表されるCell上のタスクマネージャから構成される。
-\\本論文ではCellというPowerPC ArchitectureのプロセッサコアPower Processor Elementと6個のデータ処理プロセッサコアSynergistic Processor Element(SPE)からなる非対称なマルチコアプロセッサを用いて、OSMesaの高速化とレンダリングエンジンの開発を行った。それにより、組み込みシステムにおける信頼性の高いプログラミングスタイルの提案する。\\
+そこで我々はOSMesaを捨て、独自のゲームフレームワークCeriumを持つことにした。
+我々が提案するゲームフレームワークCeriumはOpen Scene GraphやJava3Dにも実装されているオブジェクトを木構造で持ち、より動きをスムーズにみせるシーングラフとOSMesaに代表されるレンダリングエンジン、taskと呼ばれる実行単位を動的にすべてのコアが動作するように設計されたSPURSに代表されるCell上のタスクマネージャから構成される。
+\\本論文ではCellというPowerPC ArchitectureのプロセッサコアPower Processor Elementと6個のデータ処理プロセッサコアSynergistic Processor Element(SPE)からなる非対称なマルチコアプロセッサを用いて、OSMesaの高速化とレンダリングエンジンの開発を行った。それにより、組み込みシステムにおける信頼性の高いプログラミングスタイルの提案する。
 第２章でマルチコアプログラミングの要素と難しさをのべ、第３章ではCellの詳細な仕様と用意された基本的な機能の説明を述べ、第4章では実装したOSMesaの高速化、第5章でソフトウェアレンダリングの詳細を述べ、我々の開発手法が信頼性の高いプログラミングを行うのに有用であることを示す。
 
 %それと同時に我々は家庭用ゲーム機で動作するゲームプログラムのオープンな開発フレームワークに関する研究を行ってきた。

--- a/paper/master_paper.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/master_paper.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -57,6 +57,7 @@
 \input{cerium.tex}
 \input{exploit_techinique.tex}
 %\input{consideration.tex}
+\input{comparison.tex}
 \input{finally.tex}
 
 %謝辞

--- a/paper/multicore.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/multicore.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -11,7 +11,7 @@
 実際、多くのアプリケーションはシングルコアだけを使用し、マルチコアコンピュータで実行しても処理の向上はみられない。このため、独自のプログラムを新しい方法で作成する必要がある。\\
 また、一概にマルチコアといってもさまざまなマルチコアがある。簡単に分別するとホモジニアスマルチコア(図\ref{fig:homogeneous})とヘテロジニアスマルチコア(図\ref{fig:heterogeneous})がある。ホモジニアスマルチコアとはすべてのコアが同じコアで構成され、プログラマ側はCPUコアや命令セットの違いを意識する必要がないが、汎用的なコアですべての処理をこなすため、処理効率が悪いという特徴がある。それに対して、ヘテロジニアスマルチコアには二種類の構造があり、単一命令セットで構成されたマルチコアと異種命令セットで構成されたマルチコアがある。単一命令セットで構成されたマルチコアはCPUコアをタスクに合わせて、最適化することで、効率の高いCPUを作ることができる。しかし、異種命令セットのヘテロジニアスマルチコアはそれだけでなく、命令セットアーキテクチャーレベルからタスクを最適化する必要がある。
 \\
-それだけではなくcellのような特殊な拡張が施されたマルチコアも存在する。\\
+それだけではなくCellのような特殊な拡張が施されたマルチコアも存在する。\\
 必然的にシングルコアでは限られていたアルゴリズムがマルチコアの種類や並列化を考慮しアルゴリズムを考え直さなければならない。\\
 \begin{figure}[htb]
 \begin{center}
@@ -42,7 +42,7 @@
 \caption{tukwila}
 \label{fig:tuksila}
 \end{figure}
-Tuksilaプロセッサはクアットコアデザインを採用し、クロック周波数は最大2Ghzで、統合メモリコントローラ付きのQuickPath Interconncectシステムアーキテクチャになっている。フルインターフェースのQPIがCPU間の接続に、ハーフ幅のQPIをI/Oチップなどとの接続に使われ、それぞれのQPIが4.8Gtpsで1リンクのピーク帯域は19.2GB/secで、4+2リンクで96GB/secの帯域となる。しかし、これはホモジニアスマルチコアとなりへテロジニアスマルチコアほど複雑ではない。しかし、これからIntelはヘテロジニアスマルチコアを採用すると言われている。
+Tuksilaプロセッサはクアットコアデザインを採用し、クロック周波数は最大2Ghzで、統合メモリコントローラ付きのQuickPath Interconncectシステムアーキテクチャになっている。フルインターフェースのQPIがCPU間の接続に、ハーフ幅のQPIをI/Oチップなどとの接続に使われ、それぞれのQPIが4.8Gtpsで1リンクのピーク帯域は19.2GB/secで、4+2リンクで96GB/secの帯域となる。しかし、これはホモジニアスマルチコアとなりへテロジニアスマルチコアほど複雑ではない。しかし、後藤弘茂氏によるとこれからIntelはヘテロジニアスマルチコアを採用すると言われている。
 \subsection{これからのマルチコアプログラミング}
-前述した通り、これからのマルチコアはヘテロジニアスマルチコアがくると言われている。そこで汎用のヘテロジニアスマルチコアプロセッサであるcellを基にどこが難しいのかを述べる。\\
-cellでは各コアにそれぞれメモリを保持している。そのため、一種の閉じた分散プログラミングが要求されているといえる。しかもそれぞれのコアに付属しているメモリがとても小さい。その小さなメモリ環境の中でいかにプログラムとデータを収束させながら、それぞれのコアを同時に動作させるかというのが肝となる。それと同時にアーキテクチャの進化にテスト環境やデバッグ環境が追いついていない実態がある。
+前述した通り、後藤弘茂氏にこれからのマルチコアはヘテロジニアスマルチコアがくると言われている。そこで汎用のヘテロジニアスマルチコアプロセッサであるcellを基にどこが難しいのかを述べる。\\
+cellでは一つの制御コアPPCと6つの演算用コアSPUで構成されている。SPUにはそれぞれLocal Store(LS)と呼ばれるメモリを保持している。そのため、一種の閉じた分散プログラミングが要求されているといえる。しかもそれぞれのコアに付属しているメモリがとても小さい。その小さなメモリ環境の中でいかにプログラムとデータを収束させながら、それぞれのコアを同時に動作させるかというのが肝となる。それと同時にアーキテクチャの進化にテスト環境やデバッグ環境が追いついていない実態がある。

--- a/paper/osmesa.tex	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/osmesa.tex	Sun Feb 17 00:14:30 2008 +0900
@@ -1,5 +1,5 @@
 \chapter{OSMesa}
-PlayStaiton3では以前我々が扱っていたPlay Station2と違ってGPUに直接アクセスすることができない。しかし、ps3fbは扱うことができる。そこで我々は描画にSDLおよびOpenGLを用いて開発を行うことにした。SDLのfbcon driverにはOpenGLがないため、CPUはそれなりに早いが、グラフィックス性能はフレームバッファしかないという環境でよく用いられるOSMesaを使用し、移植開発を行った。
+PlayStaiton3では以前我々が扱っていたPlay Station2と違ってGDPに直接アクセスすることができない。しかし、ps3fbは扱うことができる。そこで我々は描画にSDLおよびOpenGLを用いて開発を行うことにした。SDLのfbcon driverにはOpenGLがないため、CPUはそれなりに早いが、グラフィックス性能はフレームバッファしかないという環境でよく用いられるOSMesaを使用し、移植開発を行った。
 PPUのみで動作するOSMesaとSDLを用いて作ったSuper Dandy(s-dandy)はある程度のスピードでうごくが、そのスピードでは不十分である。そこでOSMesaを今回の実験材料として用い、OSMesaの一部の機能をSPUを使用して高速化を行った。
 \section{OSMesaの機能}
 \subsection{ポリゴンの回転・拡大・縮小}
@@ -16,7 +16,7 @@
 %テクスチャを使用する場合は、各頂点に対応したテクスチャ座標を持っており、その値からテクスチャのどのxy座標のRGBがその点に対応するかを計算してRGBを書き込むようなシステムになっている。図\ref{fig:texture}では左にポリゴンが書かれており、各頂点にはxyz座標とテクスチャに対応する相対比がある。その相対比からテクスチャのどの部分がポリゴンに対応しているかがわかる。それによりテクスチャの黒い線が左のポリゴン上の1行の線にマッピングされる。
 \begin{figure}[htb]
 \begin{center}
-\includegraphics[width=17cm]{./fig/texture2.eps}
+\includegraphics[width=17cm,height=6cm]{./fig/texture2.eps}
 \end{center}
 \caption{ポリゴンとテクスチャ}
 \label{fig:texture}
@@ -25,9 +25,13 @@
 %ダブルバッファリングとは1画面が描画している間に次に描画する画像を裏でいったん生成しておき、描画する画像を切り替える手法である。画面を一気に切り替えるため、ちらつきがなくなる。
 \section{高速化する部分}
 OSMesaの機能を分割し、SPUにTaskとして割り振る方法はいくつか考えることができる。我々は最初テクスチャのついてないオブジェクトを対象とし、spanをzバッファでみながら描画していく方法を高速化した。高速化する部分のコードは以下のようになっている。\\
+\small{
 \input{src/render_span_macro.c}
+}
 最初の３行が実際のコードに記述された物になる。しかし、OSMesaはマクロを多用して実装されている。このマクロを展開したコードをいかに示す。
+\small{
 \input{src/render_span.c}
+}
 コードを説明する前にコードで用いられているspanについて先に説明しておく。spanとは次のような構成からなっている。\\
 \begin{table}[htb]
 \begin{center}
@@ -77,25 +81,18 @@
 span情報をy座標ごとに生成する。(図\ref{fig:y_list})\\
 \begin{figure}[htb]
 \begin{center}
-\includegraphics[height=5cm]{./fig/y_list.eps}
+\includegraphics[height=7cm]{./fig/spanlist.eps}
 \end{center}
-\caption{spanlist}
+\caption{spanpacklist}
 \label{fig:y_list}
 \end{figure}
-しかし、y座標ごとに生成されたspanを使用するSPUの数に単純に分割するだけではあまり効率が良くない。そこで、y座標ごとに生成されたspanのリストを更にまとめたうえで、リスト化する。ここでは64個のy座標ごとのspanのリストをまとめている。それをSPUの数分つくり、図\ref{fig:span_list}のようなリストにする。ここではSPUが受け取る最初のリストをspanpacklistと呼ぶことにする。ここで64個のy座標ごとのリストを作るのはアドレスの転送回数を減らすことにある。\\
-\begin{figure}[htb]
-\begin{center}
-\includegraphics[height=7cm]{./fig/span_list.eps}
-\end{center}
-\caption{spanpacklist}
-\label{fig:span_list}
-\end{figure}
+しかし、y座標ごとに生成されたspanを使用するSPUの数に単純に分割するだけではあまり効率が良くない。そこで、y座標ごとに生成されたspanのリストを更にまとめたうえで、リスト化する。ここでは64個のy座標ごとのspanのリストをまとめている。それをSPUの数分つくり、リストにする。図で示された四角形はまとめられたリストを表す。ここではSPUが受け取る最初のリストをspanpacklistと呼ぶことにする。ここで64個のy座標ごとのリストを作るのはアドレスの転送回数を減らすことにある。\\
 そこからy座標ごとのspanのリストをDMAでとってくる。SPUが実際に持つspanは同じy座標のみで、zバッファは1行分だけでよい。
 \subsection{ダブルバッファリング}
 spanを生成して、描画している間にもPPUは動くことができる。今回の実装ではダブルバッファを用いている。つまり、PPUではSPUが描画している間、次のSpanを生成し、SPUに送るSpanのリストを作っている。SPUも同時にspanを読み込むときにダブルバッファで読み込んでいる。(図\ref{fig:parallel})\\
 \begin{figure}[htb]
 \begin{center}
-\includegraphics[height=10cm]{./fig/parallel.eps}
+\includegraphics[height=8cm]{./fig/parallel.eps}
 \end{center}
 \caption{parallel}
 \label{fig:parallel}
@@ -106,28 +103,32 @@
 としてRead、Exec、Writeから構成できる。(図\ref{fig:pipeline})\\
 \begin{figure}[htb]
 \begin{center}
-\includegraphics{./fig/pipeline.eps}
+\includegraphics[width=15cm,height=3cm]{./fig/pipeline.eps}
 \end{center}
 \caption{pipeline実行}
 \label{fig:pipeline}
 \end{figure}
 \subsection{SPUプログラム}
 spanpacklistとダブルバッファを用いてSPUのプログラムを記述すると以下のようになる。
+\small{
 \input{src/spe_main.c}
+}
 
 ほとんどの部分がダブルバッファのDMA制御を行っている。計算を行っている部分はPPUのみで行われていたコードにDMAのダブルバッファを考慮したものである。
+\small{
 \input{src/calc.c}
+}
 ダブルバッファは入力用の構造体を二つ、出力用の構造体二つで構成されている。
 \section{評価}
 \subsection{実行速度比較}
 単純にSDLとOSMesaを用いたものとSPUを使ったOSMesaを使用したものとを比較した。例題としてはSDLに付属しているtestglというCubeが回転しているテクスチャがはられていないものを利用した。実行時間はSDLに標準で出ろくされるFPSを用いる。FPSは１秒間に何枚の画像が表示されているかを表す物である。計測結果は以下のようになる(表\ref{table:exectime})。これはCellの上ではやはりSPUをなるべく使った方が実行速度ははやくなるということを示していると同時によりOSMesaを細分化し、できるだけSPUをつかうよな設計をすると、よりはやくなる可能性を示す物であった。OSMesaがメジャーアップデートされると、それにOSMesaの最適化が加わり、更に1.8倍早くなった。
 \begin{table}[htb]
 \begin{center}
-\begin{tabular}{|l|c|}
+\begin{tabular}{|l|c|c|c|c|}
 \hline
-SDL(1.2)+OSMesa(6.5.2) & 18FPS \\ \hline
-SDL(1.2)+OSMesa(6.5.2) with SPU & 24FPS \\ \hline
-SDL(1.2.13)+OSMesa(7.0.2) with SPU & 43FPS \\ \hline
+SDL(1.2)+OSMesa(6.5.2) &  & -O2 & -O2 &18FPS \\ \hline
+SDL(1.2)+OSMesa(6.5.2) with SPU & & -O2 & -O2 & 24FPS \\ \hline
+SDL(1.2.13)+OSMesa(7.0.2) with SPU &  & -O2 & -O2 & 43FPS \\ \hline
 \end{tabular}
 \end{center}
 \caption{OSMesaの実行時間比較}

--- a/paper/src/cube-p.xml	Sat Feb 16 17:03:18 2008 +0900
+++ b/paper/src/cube-p.xml	Sun Feb 17 00:14:30 2008 +0900
@@ -12,8 +12,8 @@
             ........ ........
         </texture>
         <image name="icon.bmp">
-            Qk0cwAAAAAAAABoAAAAMAAAAgACAAAEAGAAAAJYAAJYAAJYAAJYAAJYAAJYAAJYAAJYAAJYAAJYA
-            ...............................................................................
+            Qk0cwAAAAAAAABo...........
+            ..........................
         </image>
     </surface>
     <surface name="Plane.001" size="6" prim="Triangle" parent="Cube">