Mercurial > hg > Papers > 2008 > akira-master

changeset 16:2d92b9d0576e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
*** empty log message ***
author akira
date Sun, 17 Feb 2008 16:06:13 +0900
parents e040b8f7b584
children 9a83db42af5c
files paper/abstract.tex paper/bunken.tex paper/cell.tex paper/cerium.tex paper/exploit_techinique.tex paper/finally.tex paper/introduciton.tex paper/memo paper/multicore.tex paper/osmesa.tex
diffstat 10 files changed, 160 insertions(+), 107 deletions(-) [+]
line wrap: on
line diff
--- a/paper/abstract.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/abstract.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -2,20 +2,23 @@
 $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$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%_%s%0%9%?%$%k$O3X@8<B83$G;HMQ$9$k$H!"7P83E*$K%"!<%-%F%/%A%c$NM}2r$K<B83$N;~4V$NLs(B2/3$B$r<h$i$l$F$7$^$&!#(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\\
+$B%`%o!<%/$rDs0F$9$k!#(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$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$?!#(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$:!"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$5$;!"9bB.2=$r?^$C$?!#$7$+$7!"(BOSMesa$B$O(BOpenGL$B$KI,MW$J5!G=$rDI2C$7$?7k2L!"M>7W$J1i;;$,A}(B
 $B$(!"%=!<%9%3!<%I$OJ#;($G<j$r2C$($k$3$H$,Fq$7$+$C$?!#(B
-$B$=$3$G2f!9$O(BOSMesa$B$r<N$F!"FH<+$N%2!<%`%U%l!<%`%o!<%/$r;}$D$3$H$K$7$?!#(B
+$B$=$3$G2f!9$OFH<+$N%l%s%@%j%s%0%(%s%8%s$r;}$D%2!<%`%U%l!<%`%o!<%/$r;}$D$3$H$K$7$?!#(B
 $B%2!<%`$NCf$N0l$D$N>lLL%7!<%s$r9=@.$9$k%*%V%8%'%/%H$d$=$N?6$kIq$$!"(B
 $B%2!<%`$N%k!<%k$+$i$J$k%7!<%s%0%i%U$H%]%j%4%s$+$iIA2h$^$G$r9T$&%l%s%@%j%s(B
 $B%0%(%s%8%s!"$5$i$K$=$l$i$NF0$-$rF0E*$K(BSPU$B$K3d$j?6$k%+!<%M%k$+$i9=@.$5$l(B
--- a/paper/bunken.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/bunken.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -4,7 +4,7 @@
 
 Continuation based CによるPS3 Cellのシミュレーション \\
 神里　晃，河野 真治， ~~
-第102回 情報処理学会 システムソフトウェアとオペレーティング・システム研究発表会, 2006.\\
+第102回 情報処理学会 システムソフトウェアとオペレーティング・システム研究発表会, 2006.  発表予定\\
 ~~\\
 ~~\\
 CからCellアーキテクチャを利用したCbCへの変換  \\
--- a/paper/cell.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/cell.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -13,17 +13,16 @@
 \\
 PPEはCell Broadband Engineのメインプロセッサで、複数のSPUをコアプロセッ
 サとして使用することができる汎用プロセッサで、オペレーティングシステムの役割であるメインメモリや外部デバイスへの入出力制御を行う。
-%Cellの内部でのデータ通信はDMAで行われCPUに負担をかけない。\\
-\subsection{spe}
+\subsection{SPE}
 SPEは
-PPEのような複雑な制御よりも計算を単純に繰り返すマルチメディア系の処理を得意とする演算系プロセッサコアである。(図\ref{fig:spe}参照)
+PPEのような複雑な制御よりも計算を単純に繰り返すマルチメディア系の処理を得意とする演算系プロセッサコアである。(図\ref{fig:SPE}参照)
 SPUはSPUとMFCから構成され、独自規格の命令セットを持っている。各々のSPUはLocal Store(LS)とよばれる256kbのメモリ量を持ち、各SPUから直接参照できる唯一のメモリとして存在する。MFCはメインメモリや他のSPEなどとデータをやり取りするためのユニットで、SPUはチャネルというインタフェースを介してMFCに対してデータ転送などを依頼し、各々のSPUが持つLSにメインメモリ上のデータなどを転送する。
 \begin{figure}[htb]
 \begin{center}
-\includegraphics[height=8cm]{./fig/spe.eps}
+\includegraphics[height=8cm]{./fig/SPE.eps}
 \end{center}
-\caption{spe}
-\label{fig:spe}
+\caption{SPE}
+\label{fig:SPE}
 \end{figure}
 
 % ここでPPEとSPEの詳細必要？
@@ -58,8 +57,8 @@
 	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に基本プログラムは次のようになる。
+\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に基本プログラムは次のようになる。
 
 \begin{enumerate}
 \item create N SPE context
@@ -81,27 +80,30 @@
 \end{table}
 このようにCell特有の関数やアセンブラ命令を学ぶことが必要となる。
 \section{SPURS}
-ここでは現在発表されているCellの開発環境SPURS\cite{spurs}について説明する。
-SPURSとは閉じた並列分散と考えることができるCellの環境でいかに効率よく動作させるかということを考たシステムである。Cellの性能を存分に生かすためにはSPEを効率よく使い切ることとあらゆるレベルで並列処理を行うことである。SPEを効率よく使い切るにはSPUの動作を止めることなく、同期を最小限に行う必要がある。\\
-そこでSPURSではSPUを効率よく利用するために、PPUに依存せずにSPUコードを選択し、実行することと機能は効率重視で割り切ることを挙げている。そのためにSPUにカーネルを組み込んでいる。\\
+ここでは現在発表されているCellの開発環境SPURS\cite{SPURS}について説明する。
+SPURSとは閉じた並列分散と考えることができるCellの環境でいかに効率よく動作させるかということを考たシステムである。Cellの性能を存分に生かすためにはSPEを効率よく使い切ることとあらゆるレベルで並列処理を行うことである。SPEを効率よく使い切るにはSPUの動作を止めることなく、同期を最小限に行う必要がある。
+
+そこでSPURSではSPUを効率よく利用するために、PPUに依存せずにSPUコードを選択し、実行することと機能は効率重視で割り切ることを挙げている。そのためにSPUにカーネルを組み込んでいる。
+
 アプリケーションを複数SPUで実行するとき、アプリケーションプログラムをできるだけ小さなタスクに分割し、通信ライブラリを用いてタスク間を依存関係で結合する。LS常駐のカーネルは実行可能なタスクを選んで実行する。(図\ref{fig:task})\\
 \begin{figure}[htb]
 \begin{center}
-\includegraphics[width=15cm]{./fig/spurs_task.eps}
+\includegraphics[width=15cm]{./fig/SPURS_task.eps}
 \end{center}
-\caption{spurs\_task}
+\caption{SPURS\_task}
 \label{fig:task}
 \end{figure}
 また、アプリケーションを分割するとき、プログラムがデータを伴うとき、ジョブに分割し、並べ替えた上で、LS常駐のカーネルはジョブリストからジョブをとってき実行する。
 (図\ref{fig:task2})\\
 \begin{figure}[htb]
 \begin{center}
-\includegraphics[width=15cm]{./fig/spurs_task2.eps}
+\includegraphics[width=15cm]{./fig/SPURS_task2.eps}
 \end{center}
-\caption{spurs\_task2}
+\caption{SPURS\_task2}
 \label{fig:task2}
 \end{figure}
-またこれらはデータを扱うため、SPURSはパイプライン実行を行う。(図\ref{fig:pipeline2})\\
+またこれらはデータを扱うため、SPURSはパイプライン実行を行う。(図\ref{fig:pipeline2})
+
 \begin{figure}
 \begin{center}
 \includegraphics{./fig/pipeline2.eps}
--- a/paper/cerium.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/cerium.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -1,6 +1,7 @@
 \chapter{レンダリングエンジンの提案}
 \section{Cerium}
-我々はMesaのソフトウェアレンダリングエンジンであるOSMesaが分割しにくいこと、コピーが多いことなどの理由から独自のレンダリングエンジンを持つことにした。そのレンダリングエンジンをCeriumとする。Ceriumは次の3つから構成される。\\
+我々はMesaのソフトウェアレンダリングエンジンであるOSMesaが分割しにくいこと、コピーが多いことなどの理由から独自のレンダリングエンジンを持つことにした。そのレンダリングエンジンをCeriumとする。Ceriumは次の3つから構成される。
+
 \begin{itemize}
 \item シーングラフ
 \item レンダリングエンジン
@@ -11,18 +12,24 @@
 ゲームの中の一つの場面(Scene)を構成するオブジェクトやその振る舞い、ゲームのルールの集合をSceneGraphとする。SceneGraphの各ノードがゲームの一部であるオブジェクトの振る舞いやゲームのルールとなり、ノードをたどり実行することでゲームの中の一つの場面となる。SceneGraphはゲームプログラムとしての条件を満たす物なので、一つのScene Graphで小さなゲームといえる。
 \subsection{レンダリングエンジン}
 レンダリングエンジンはOSMesaの機能を簡素化し、よりシンプルに使いやすく設計されたフレームワークである。
-OSMesaではいろいろな機能を付加し続けた結果、様々計算の部分でコピーがたくさん行われていた。それはCPUに多大な負荷を与えるとともに動作が遅くなる大きな要因となっていた。\\
-そこで我々が提案するレンダリングエンジンはシーングラフから、ポリンゴンの各頂点をうけとり、頂点からspanを生成し、spanに対応するテクスチャを生成するシンプルな物を目指す。
+OSMesaではいろいろな機能を付加し続けた結果、様々計算の部分でコピーがたくさん行われていた。それはCPUに多大な負荷を与えるとともに動作が遅くなる大きな要因となっていた。
+
+そこで我々が提案するレンダリングエンジンはシーングラフから、ポリンゴンの各頂点をうけとり、頂点からSPANを生成し、SPANに対応するテクスチャを生成するシンプルな物を目指す。
 \subsection{タスクマネージャ}
-タスクマネージャとはその名の通り、タスクを管理する物である。SPUは256kbという小さなデータ量しかもてない。そのため、なんどもSPUで違う動作をさせるためにはSPUのプログラムをロードしなければならない。プログラムのロードを逐次的に行うことも可能だがSPUのプログラムは必要なときに必要な実行プログラムがSPUにロードされていることが望ましい。そこで我々はSPURSの考えを基にタスクマネージャを作成した。\\
+タスクマネージャとはその名の通り、タスクを管理する物である。SPUは256kbという小さなデータ量しかもてない。そのため、なんどもSPUで違う動作をさせるためにはSPUのプログラムをロードしなければならない。プログラムのロードを逐次的に行うことも可能だがSPUのプログラムは必要なときに必要な実行プログラムがSPUにロードされていることが望ましい。そこで我々はSPURSの考えを基にタスクマネージャを作成した。
+
 \section{Ceriumの実装}
 \subsection{シーングラフ}
-シーングラフはゲームのシーンを構成するオブジェクトやその振る舞いの記述である。シーングラフはxmlをパースするところか始まる。blenderから生成されるxmlは以下のような構造を持っている。\\
+シーングラフはゲームのシーンを構成するオブジェクトやその振る舞いの記述である。シーングラフはxmlをパースするところか始まる。blenderから生成されるxmlは以下のような構造を持っている。
+
 \small{
 \input{src/cube-p.xml}
 }
-このxmlにはblenderで記述されたすべてのオブジェクトの情報が記述されている。一つのオブジェクトに対し、サーフェイスの名前とサイズ、親のポリゴンの名前、それに対してcoordinate(ポリゴン情報)とtexture(ポリゴンに対応するテクスチャ座標)、テクスチャの$RGB\alpha$情報があり、シーングラフではそのxml情報をパースしてすべての情報をレンダリングエンジンに必要な構造体に直す。その上で、親子関係を考慮した回転や拡大縮小などを行う。\\
-親子関係とは自転と公転のようなもので、例えば地球が自転すると、それに伴って月が公転するようなことである。それは子に対して親への変換行列がかけられている。それをスタック上に積んで計算する必要がある。(図\ref{fig:stack})\\
+\normalsize
+このxmlにはblenderで記述されたすべてのオブジェクトの情報が記述されている。一つのオブジェクトに対し、サーフェイスの名前とサイズ、親のポリゴンの名前、それに対してcoordinate(ポリゴン情報)とtexture(ポリゴンに対応するテクスチャ座標)、テクスチャの$RGB\alpha$情報があり、シーングラフではそのxml情報をパースしてすべての情報をレンダリングエンジンに必要な構造体に直す。その上で、親子関係を考慮した回転や拡大縮小などを行う。
+
+親子関係とは自転と公転のようなもので、例えば地球が自転すると、それに伴って月が公転するようなことである。それは子に対して親への変換行列がかけられている。それをスタック上に積んで計算する必要がある。(図\ref{fig:stack})
+
 \begin{figure}[htb]
 \begin{center}
 \includegraphics{./fig/stack.eps}
@@ -30,57 +37,62 @@
 \caption{親子関係のstack}
 \label{fig:stack}
 \end{figure}
-\\
 親子関係などで計算されたポリゴンがレンダリングエンジンに渡される。しかし、それだけではなく、回転などの状態を残したアップデートされたポリゴンパックを保持して置く必要がある。
 \subsection{レンダリングエンジン}
-レンダリングエンジンは2つに分けることができる。spanを生成する部分と与えられたspanからテクスチャの生成する部分である。
-\subsubsection{spanを生成する部分}
-spanを生成するとき、シーングラフから必要な情報(polygonpack)が渡される。\\
+レンダリングエンジンは2つに分けることができる。SPANを生成する部分と与えられたSPANからテクスチャの生成する部分である。
+\subsubsection{SPANを生成する部分}
+SPANを生成するとき、シーングラフから必要な情報(polygonpack)が渡される。
+
 \small{
 \input{src/polygonpack.h}
 }
+\normalsize
 polygonpackは光源の情報とテクスチャの情報と頂点の情報から構成される。TRIANGLEPACKというものがポリゴンに相当する物で、3つの頂点とそのポリゴンに対応するテクスチャの情報が格納されているアドレス、テクスチャの高さと幅が与えられている。３つの頂点にはx座標、y座標、z座標、テクスチャのx相対比、テクスチャのy相対比が与えられる。
-この与えられたpolygonpackの情報からspanの情報を出力する。spanを生成するコードはつぎのようになっている。\\
+この与えられたpolygonpackの情報からSPANの情報を出力する。SPANを生成するコードはつぎのようになっている。
+
 \begin{figure}[htb]
 \begin{center}
 \includegraphics{./fig/half_triangle.eps}
 \end{center}
-\caption{span生成時のポリゴン分割}
+\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は次のようなメモリ空間を持つことになる。\\
+\normalsize
+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]
 \begin{center}
-\includegraphics[width=15cm]{./fig/ppu_memory_span.eps}
+\includegraphics[width=15cm]{./fig/ppu_memory_SPAN.eps}
 \end{center}
-\caption{ppuにできるspanのメモリ空間}
+\caption{PPUにできるSPANのメモリ空間}
 \label{fig:ppu_memory}
 \end{figure}
 \\
 縦に並んだ空間がPPUによってリストにされる。
-\subsubsection{spanからテクスチャを計算する部分}
-spanは次のような情報(spanpack)からテクスチャを計算し描画する。
-\input{src/spanpack.h}
-spanはテクスチャ情報のアドレスと高さと幅、それに加えてポリゴンのあるy座標に対するx、y、start\_z、tex\_x1、tex\_y1（左端のピクセル情報）とlength(spanの長さ)とend\_z、tex\_x2、tex\_y2（右端のピクセル情報)を持つ。(図\ref{fig:span})\\
+\subsubsection{SPANからテクスチャを計算する部分}
+SPANは次のような情報(SPANpack)からテクスチャを計算し描画する。
+\input{src/SPANpack.h}
+SPANはテクスチャ情報のアドレスと高さと幅、それに加えてポリゴンのあるy座標に対するx、y、start\_z、tex\_x1、tex\_y1（左端のピクセル情報）とlength(SPANの長さ)とend\_z、tex\_x2、tex\_y2（右端のピクセル情報)を持つ。(図\ref{fig:SPAN})\\
 \begin{figure}[htb]
 \begin{center}
-\includegraphics{./fig/span.eps}
+\includegraphics{./fig/SPAN.eps}
 \end{center}
-\caption{span情報}
-\label{fig:span}
+\caption{SPAN情報}
+\label{fig:SPAN}
 \end{figure}
 その情報からテクスチャを計算して、ピクセル毎のRGB$\alpha$情報を取得する。しかし、SPUはメモリが256kbしかないため、すべてのテクスチャを送ることが不可能となる場合がある。それらを考慮し、テクスチャを分割する必要がある。
-テクスチャは8x8の大きさに分割される。(図\ref{fig:div_texture})\\
-spanはそれぞれのテクスチャに沿ってspanを生成される。つまり、span一つにつき、分割したテクスチャ一つがDMAされる。
+テクスチャは8x8の大きさに分割される。(図\ref{fig:div_texture})
+
+SPANはそれぞれのテクスチャに沿ってSPANを生成される。つまり、SPAN一つにつき、分割したテクスチャ一つがDMAされる。
 \subsection{タスクマネージャ}
 タスクマネージャはSPUで実行される関数をタスクとしてQueueに登録し、タスクマネージャに実行命令が下ると、Queueに登録されたタスクが依存関係をみながら、実行されていくライブラリである。
 以下にタスクマネージャを使った実装例を記述する。
 \input{src/manager.cpp}
-タスクマネージャはPPUで実行するかSPUで実行するかを明示的に書くことができる。またSPUを使う場合はSPUコアをいくつ使うかということも指定することができる。そうすると、以下のようなことができる可能性もある。\\
+タスクマネージャはPPUで実行するかSPUで実行するかを明示的に書くことができる。またSPUを使う場合はSPUコアをいくつ使うかということも指定することができる。そうすると、以下のようなことができる可能性もある。
+
 \begin{figure}[htb]
 \begin{center}
 \includegraphics[width=15cm]{./fig/pipeline3.eps}
@@ -88,6 +100,6 @@
 \caption{タスクマネージャが行うパイプライン}
 \label{fig:pipeline3}
 \end{figure}
-これはシーングラフからポリゴンを生成するSGU2PGCとポリゴンからspanを生成するPGP2SPPとspanからテクスチャを生成しレンダリングするSPP2RENの関係を表す図である。これら一連の流れは順に1、２、３というふうになる。一番左端にあるb2はポリゴンの構造体を表す。そのポリゴン構造体はSGU2PGCに使われるという図である。つまり、タスクマネージャを用いて、ダブルバッファとパイプラインを用いても、ポリゴンのPPUはポリゴンの構造体二つとspanの構造体二つでレンダリングができることを示している。\\
+これはシーングラフからポリゴンを生成するSGU2PGCとポリゴンからSPANを生成するPGP2SPPとSPANからテクスチャを生成しレンダリングするSPP2RENの関係を表す図である。これら一連の流れは順に1、２、３というふうになる。一番左端にあるb2はポリゴンの構造体を表す。そのポリゴン構造体はSGU2PGCに使われるという図である。つまり、タスクマネージャを用いて、ダブルバッファとパイプラインを用いても、ポリゴンのPPUはポリゴンの構造体二つとSPANの構造体二つでレンダリングができることを示している。
 \section{評価}
 今回我々はCell上で動作するゲームフレームワークを作成した。今回のフレームワークの作成により、ゲーム班はシーングラフの一部を作り直し、親子関係を考慮したオブジェクトを生成するだけである程度のゲームが作れるようになる。それだけでなく、そのフレームワークを使うことはCellアーキテクチャの勉強をすることにもつながる。
--- a/paper/exploit_techinique.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/exploit_techinique.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -1,6 +1,7 @@
 \chapter{開発段階}
 \section{過去の移植行程}
-我々はこれまでPlayStationで動作するプログラムのPlayStation2へ移植を行ってきた。移植はアーキテクチャーに依存するレイヤーとアーキテクチャーに依存しないレイヤーに分割し、依存レイヤーの部分のコードを書き換えてきた。（図\ref{fig:porting})しかし、それではアーキテクチャー依存間の差はとることは容易ではない。そこで我々がリファクタリングを用いて開発を行った。\\
+我々はこれまでPlayStationで動作するプログラムのPlayStation2へ移植を行ってきた。移植はアーキテクチャーに依存するレイヤーとアーキテクチャーに依存しないレイヤーに分割し、依存レイヤーの部分のコードを書き換えてきた。（図\ref{fig:porting})しかし、それではアーキテクチャー依存間の差はとることは容易ではない。そこで我々がリファクタリングを用いて開発を行った。
+
 ソフトウェアは一気に構成される訳ではなく、いくつかの変更を得て作られていく。新しい環境で使われるように変更すれば、再利用しやすくするために同じ動作をするプログラムを異なる構成に変更することもある。これらをリファクタリングと読んでいる。
 \begin{figure}[htb]
 \begin{center}
@@ -13,9 +14,10 @@
 今回我々はOSMesaの高速化を実装したときにデバッグ環境がほとんどなく、とても苦労した。そこで我々は一度シーケンシャルなアルゴリズムで実装し、それをCellに移植するようにした。
 シーケンシャルなアルゴリズムの実装では以下のようになる。
 \input{src/overview-gameprogram.c}
-これはSDLとSDL\_imageがインストールされている環境だとどこででも動作することができる。これらをいったん動作させ、正しく動かすことを確認する。その際、シーングラフの更新とSpanPackの生成、テクスチャーの生成などはSPUで動作することを前提としてプログラムを記述しなければならない。つまり、シーングラフの出力とSpanPackの生成の入力が同じになるように設計を行う。同様にSpanPackの生成の出力とテクスチャの生成の入力が同じにならなければならない。そうすることにより、よりCell上への移行がよりスムーズになる。\\
+これはSDLとSDL\_imageがインストールされている環境だとどこででも動作することができる。これらをいったん動作させ、正しく動かすことを確認する。その際、シーングラフの更新とSpanPackの生成、テクスチャーの生成などはSPUで動作することを前提としてプログラムを記述しなければならない。つまり、シーングラフの出力とSpanPackの生成の入力が同じになるように設計を行う。同様にSpanPackの生成の出力とテクスチャの生成の入力が同じにならなければならない。そうすることにより、よりCell上への移行がよりスムーズになる。
 \subsection{デバッグ}
-シーケンシャルな環境と並列分散の環境でのデバッグは難しさがだいぶ異なる。\\
+シーケンシャルな環境と並列分散の環境でのデバッグは難しさがだいぶ異なる。
+
 シーケンシャルなアルゴリズムでいったん実装した後、Cellの環境に容易に移すことが可能ならば、Cellの並列環境の上でデバッグを行う必要がなくなる。シーケンシャルな環境で実装する際にもスレッドを使わないようなデバッグが容易にできるようなプログラム記述が求められる。
 \section{まとめ}
 我々は開発段階としてシーケンシャルなアルゴリズムでの実装、SPUにマッピングするデータ構造を用いたシーケンシャルアルゴリズムでの実装、Cellへのマッピングという風に開発を行った。そうすることで新たなゲーム開発環境ができたときもシーケンシャルなアルゴリズムから開発できるというメリットがある。段階的な開発行程にMindMapを利用し、かなり複雑な仕様を策定しCeriumを開発した。(図\ref{fig:mm1}、図\ref{fig:mm2})またデバッグを行うことが難しい並列環境に置いても、それをより容易にデバッグすることを可能にした。
--- a/paper/finally.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/finally.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -1,14 +1,17 @@
 \chapter{まとめと今後の課題}
 \section{まとめ}
-本稿ではCell Broadband Engineを用いて、新たなゲームフレームワークの提案を行った。PlayStation3ではGDPを使うことができないので、PlayStation3に搭載されているハードウェアを100\%活用できないという欠点がある。しかし、ps3fbという従来のLinuxに搭載されているフレームバッファがあるので、PlayStation3以外でテストを行うことが可能となるのは利点でもある。\\
-まず例題としてOSMesaのSpanを描画するルーチンをSPUを使って並列処理するように実装した。その結果、それなりの結果を得ることができた。このOSMesaで実験を行ったことにより、zバッファの並列化を行うことが大きな成果と言える。その上で、よりゲーム班が使いやすいフレームワークを提案し実装している。\\
+本稿ではCell Broadband Engineを用いて、新たなゲームフレームワークの提案を行った。PlayStation3ではGDPを使うことができないので、PlayStation3に搭載されているハードウェアを100\%活用できないという欠点がある。しかし、ps3fbという従来のLinuxに搭載されているフレームバッファがあるので、PlayStation3以外でテストを行うことが可能となるのは利点でもある。
+
+まず例題としてOSMesaのSpanを描画するルーチンをSPUを使って並列処理するように実装した。その結果、それなりの結果を得ることができた。このOSMesaで実験を行ったことにより、zバッファの並列化を行うことが大きな成果と言える。その上で、よりゲーム班が使いやすいフレームワークを提案し実装している。
+
 このフレームワークのプロジェクトはまだ始まったばかりである。実装されていない部分や直す余地があるところがたくさんある。今後に残された課題を示す。
 \section{今後の課題}
 \subsection{CbCの導入}
-今回ゲームプログラムを行った上で、改めてゲームプログラミングは状態遷移で記述すべきものの一つであることを感じた。そこで本研究室で開発されている言語Continuation based C(CbC)がゲームプログラミングに向いている。\cite{scenario}\\
+今回ゲームプログラムを行った上で、改めてゲームプログラミングは状態遷移で記述すべきものの一つであることを感じた。そこで本研究室で開発されている言語Continuation based C(CbC)がゲームプログラミングに向いている。\cite{scenario}
+
 シーングラフとレンダリングエンジンをCbCで記述すれば、時最適化されたgccのコードに比べれば実行速度は落ちるが、それでもより信頼性の高いプログラミングで実装することが可能となる。
 \subsection{より精度の高い演算}
-ポリゴンからspanを生成するときにある程度の誤差は修正するように実装したが、それでも誤差は残る。この誤差をより小さくする計算方法があることはわかっている。それらを実装し、より鮮明な画像を表示することが必要である。
+ポリゴンからSPANを生成するときにある程度の誤差は修正するように実装したが、それでも誤差は残る。この誤差をより小さくする計算方法があることはわかっている。それらを実装し、より鮮明な画像を表示することが必要である。
 \subsection{SIMDによる実装}
 SPUには、SIMDによる並列演算が可能となっている。今現在SIMDによる実装は行われていないが、実際は単純に並列実行するよりもSIMDの方が効果が大きいと期待している。
 \subsection{動的なゲームの作成}
@@ -17,7 +20,7 @@
 シェーディングとは光源を基にモデルに対して陰影をつけるこである。光源を想定した構造体の定義は済んでいるが、それはまだ実装されていないため、実装する必要がある。と
 \subsection{Alpha blending}
 アルファブレンディングはアルファという値を使い、透明具合を判断する物である。モデルが重なり合ったとき、普通は上にある方が描画される。しかし、透明の設定をしていると、下の物が見える可能性を残している。その透明もしくは半透明をアルファ値から読み取り実装する必要がある。
-\subsection{z sort}
-OSMesaではどちらが手前にあるのかという判断をzバッファを用いて判断していた。しかし、それはSPUに画面全体のzバッファを保持することができずy座標ごとにspanをソートし送り出す工夫を施さなければならない。しかし、zソートはzバッファと違い、面に対してどちらが手前にあるかというのを判断し、おくにある面から描画していく手法である。そうすることにより、後に描画される方が必ず手前にくる。そうすることでSPUはzバッファがいらなくなる。
+\subsection{Z sort}
+OSMesaではどちらが手前にあるのかという判断をzバッファを用いて判断していた。しかし、それはSPUに画面全体のzバッファを保持することができずy座標ごとにSPANをソートし送り出す工夫を施さなければならない。しかし、zソートはzバッファと違い、面に対してどちらが手前にあるかというのを判断し、おくにある面から描画していく手法である。そうすることにより、後に描画される方が必ず手前にくる。そうすることでSPUはzバッファがいらなくなる。
 \subsection{評価}
 今回我々が実装しているCeriumはまだ途中段階までしか実装できていない。よって評価を下すことができない。完成させた上で評価することも課題の一つと言える。
--- a/paper/introduciton.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/introduciton.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -1,13 +1,15 @@
 \chapter{序論}
 \pagenumbering{arabic}
 家庭用ゲーム機の多くは特殊なアーキテクチャを基盤としており、特にPS3でのCellシステムを用いたゲーム開発時にはSPUを駆使した並列設計が求められる。しかし、学生実験に置いてCellアーキテクチャを理解した上でゲームを実装することは困難である。また
-他のゲーム機に移植する際には、アーキテクチャ間の差を埋めるためプログラムを大幅に書き換える必要がある。つまり、従来のCellアーキテクチャ上でのプログラム手法では、開発基盤を理解してプログラムを書くことには時間が必要であるということと、他アーキテクチャーとの汎用性が失われるという問題があった。\\
+他のゲーム機に移植する際には、アーキテクチャ間の差を埋めるためプログラムを大幅に書き換える必要がある。つまり、従来のCellアーキテクチャ上でのプログラム手法では、開発基盤を理解してプログラムを書くことには時間が必要であるということと、他アーキテクチャーとの汎用性が失われるという問題があった。
+
 Linux上のレンダリングエンジンとしてOSMesaがある。これはOS やハードウェアに依存しないオフスクリーンレンダリングライブラリである。しかしながらPlayStation3のPowerPCシングルプロセッサ上ではCellの性能はいかせない。そこでOSMesaに手を加えて、一部の機能をSPUに演算させることにより、高速化させた。
-しかし、OSMesaは機能を増やした結果、余計な演算が増
-え、ソースコードは複雑で手を加えることが難しかった。\\
+しかし、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というPowerPC ArchitectureのプロセッサコアPower Processor Elementと6個のデータ処理プロセッサコアSynergistic Processor Element(SPE)からなる非対称なマルチコアプロセッサを用いて、OSMesaの高速化とレンダリングエンジンの開発を行った。それにより、組み込みシステムにおける信頼性の高いプログラミングスタイルの提案する。
 第２章でマルチコアプログラミングの要素と難しさをのべ、第３章ではCellの詳細な仕様と用意された基本的な機能の説明を述べ、第4章では実装したOSMesaの高速化、第5章でソフトウェアレンダリングの詳細を述べ、我々の開発手法が信頼性の高いプログラミングを行うのに有用であることを示す。
 
 %それと同時に我々は家庭用ゲーム機で動作するゲームプログラムのオープンな開発フレームワークに関する研究を行ってきた。
--- a/paper/memo	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/memo	Sun Feb 17 16:06:13 2008 +0900
@@ -73,3 +73,12 @@
 
 絲s-dandy綺牙蚊若違....違吾鴻鐚libspe2茯違ｃ腆冴
 鴻罨鴻菴違鴻
+
+紊ф絖ゃ
+1茵違筝
+OSMes筝欠
+GDPс泣若違ｃ泣罩腱篏帥
+s-dandy篏ｃ
+潟潟違潟吾Cerium
+
+肴；篋絎
--- a/paper/multicore.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/multicore.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -6,13 +6,16 @@
 %\section{マルチコアプログラミングとは}
 
 \section{マルチコアプログラミングの難しさ}
-マルチコアプロセッサでは、各プロセッサコアは基本的に独立しているため、それぞれのプロセッサコアは他のプロセッサコアに影響されることなく動作することができ、原理は複数のプロセッサコアで処理を分担し、性能をあげることである。\\
-しかし、単純にコアの数に性能が比例することはない。それは各プロセッサコアで行う処理の依存関係が存在し、複数のプロセッサを活用するアルゴリズムが非常に難しい現状があるからである。\\
-実際、多くのアプリケーションはシングルコアだけを使用し、マルチコアコンピュータで実行しても処理の向上はみられない。このため、独自のプログラムを新しい方法で作成する必要がある。\\
+マルチコアプロセッサでは、各プロセッサコアは基本的に独立しているため、それぞれのプロセッサコアは他のプロセッサコアに影響されることなく動作することができ、原理は複数のプロセッサコアで処理を分担し、性能をあげることである。
+
+しかし、単純にコアの数に性能が比例することはない。それは各プロセッサコアで行う処理の依存関係が存在し、複数のプロセッサを活用するアルゴリズムが非常に難しい現状があるからである。
+
+実際、多くのアプリケーションはシングルコアだけを使用し、マルチコアコンピュータで実行しても処理の向上はみられない。このため、独自のプログラムを新しい方法で作成する必要がある。
+
 また、一概にマルチコアといってもさまざまなマルチコアがある。簡単に分別するとホモジニアスマルチコア(図\ref{fig:homogeneous})とヘテロジニアスマルチコア(図\ref{fig:heterogeneous})がある。ホモジニアスマルチコアとはすべてのコアが同じコアで構成され、プログラマ側はCPUコアや命令セットの違いを意識する必要がないが、汎用的なコアですべての処理をこなすため、処理効率が悪いという特徴がある。それに対して、ヘテロジニアスマルチコアには二種類の構造があり、単一命令セットで構成されたマルチコアと異種命令セットで構成されたマルチコアがある。単一命令セットで構成されたマルチコアはCPUコアをタスクに合わせて、最適化することで、効率の高いCPUを作ることができる。しかし、異種命令セットのヘテロジニアスマルチコアはそれだけでなく、命令セットアーキテクチャーレベルからタスクを最適化する必要がある。
-\\
-それだけではなくCellのような特殊な拡張が施されたマルチコアも存在する。\\
-必然的にシングルコアでは限られていたアルゴリズムがマルチコアの種類や並列化を考慮しアルゴリズムを考え直さなければならない。\\
+
+それだけではなくCellのような特殊な拡張が施されたマルチコアも存在する。
+必然的にシングルコアでは限られていたアルゴリズムがマルチコアの種類や並列化を考慮しアルゴリズムを考え直さなければならない。
 \begin{figure}[htb]
 \begin{center}
 \includegraphics[height=6cm]{./fig/homogeneous.eps}
@@ -34,15 +37,16 @@
 %\item 流れ作業で振り分ける方法による並列化
 %\end{itemize}
 \section{Tukwila}
-TuksilaとはIntelが開発している次世代CPUである。(図\ref{fig:tuksila})\\
+TuksilaとはIntelが開発している次世代CPUである。(図\ref{fig:tuksila})
 \begin{figure}
 \begin{center}
 \includegraphics{./fig/tuksila.eps}
 \end{center}
-\caption{tukwila}
+\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はヘテロジニアスマルチコアを採用すると言われている。
 \subsection{これからのマルチコアプログラミング}
-前述した通り、後藤弘茂氏にこれからのマルチコアはヘテロジニアスマルチコアがくると言われている。そこで汎用のヘテロジニアスマルチコアプロセッサであるcellを基にどこが難しいのかを述べる。\\
+前述した通り、後藤弘茂氏にこれからのマルチコアはヘテロジニアスマルチコアがくると言われている。そこで汎用のヘテロジニアスマルチコアプロセッサであるcellを基にどこが難しいのかを述べる。
+
 cellでは一つの制御コアPPCと6つの演算用コアSPUで構成されている。SPUにはそれぞれLocal Store(LS)と呼ばれるメモリを保持している。そのため、一種の閉じた分散プログラミングが要求されているといえる。しかもそれぞれのコアに付属しているメモリがとても小さい。その小さなメモリ環境の中でいかにプログラムとデータを収束させながら、それぞれのコアを同時に動作させるかというのが肝となる。それと同時にアーキテクチャの進化にテスト環境やデバッグ環境が追いついていない実態がある。
--- a/paper/osmesa.tex	Sun Feb 17 14:21:38 2008 +0900
+++ b/paper/osmesa.tex	Sun Feb 17 16:06:13 2008 +0900
@@ -1,18 +1,19 @@
 \chapter{OSMesa}
-PlayStaiton3では以前我々が扱っていたPlay Station2と違ってGDPに直接アクセスすることができない。しかし、ps3fbは扱うことができる。そこで我々は描画にSDLおよびOpenGLを用いて開発を行うことにした。SDLのfbcon driverにはOpenGLがないため、CPUはそれなりに早いが、グラフィックス性能はフレームバッファしかないという環境でよく用いられるOSMesaを使用し、移植開発を行った。
-PPUのみで動作するOSMesaとSDLを用いて作ったSuper Dandy(s-dandy)はある程度のスピードでうごくが、そのスピードでは不十分である。そこでOSMesaを今回の実験材料として用い、OSMesaの一部の機能をSPUを使用して高速化を行った。
+PlayStaiton3では以前我々が扱っていたPlay Station2と違ってGDPに直接アクセスすることができない。しかし、ps3fbは扱うことができる。そこで我々は描画にSDLおよびOpenGLを用いて開発を行うことにした。SDLのfbcon driverにはOpenGLがないため、グラフィックス性能はフレームバッファしかないという環境でよく用いられるOSMesaを使用し、移植開発を行った。
+
+PPUのみで動作するOSMesaとSDLを用いて我々が独自に作ったSuper Dandy(s-dandy)はある程度のスピードでうごくが、そのスピードでは不十分である。そこでOSMesaを今回の実験材料として用い、OSMesaの一部の機能をSPUを使用して高速化を行った。
 \section{OSMesaの機能}
 \subsection{ポリゴンの回転・拡大・縮小}
 まず最初にOSMesaはポリゴンと呼ばれる三角形の各頂点座標を入力値として利用している。図\ref{fig:texture}の左の図がポリゴンに相当する物となる。ポリゴンの頂点座標から次の動作の命令を汲み取った上で、動作に伴う行列演算を行う。
-\subsection{spanの生成}
-動作に伴う演算から得られたポリゴン情報はいったんspanという構造体に変換される。
-図\ref{fig:texture}で線が引かれている部分がspanである。ポリゴン情報からy座標別に情報を分割し、図\ref{fig:texture}ではy=15のところのspanを示している。左端の点のx、y、z座標とRGB$\alpha$、右端のx、zとRGB$\alpha$から構成される。
+\subsection{SPANの生成}
+動作に伴う演算から得られたポリゴン情報はいったんSPANという構造体に変換される。
+図\ref{fig:texture}で線が引かれている部分がSPANである。ポリゴン情報からy座標別に情報を分割し、図\ref{fig:texture}ではy=15のところのSPANを示している。左端の点のx、y、z座標とRGB$\alpha$、右端のx、zとRGB$\alpha$から構成される。
 \subsection{テクスチャの生成とマッピング}
 テクスチャの読み込みはSDL\_imageを利用して行う。IMG\_Loadという関数でテクスチャの情報をメモリに格納し、そのテクスチャのx、yをO~1で扱う。図\ref{fig:texture}ではy=15のラインで、左端がテクスチャの値を(0.3,0.5)、右端が(0.5,0.7)という値で保持している。それは右のテクスチャの線が引かれた部分に相当する。つまり、y=15のラインはテクスチャの線の部分がマッピングされることになる。
 \subsection{zバッファ}
 OSMesaは描画を行う際、zバッファというメモリ領域を確保している。zバッファは描画する画面の大きさのメモリ空間を持ち、それぞれのx、y座標に対応するzの値を保持している。そのx、y座標が描画する際、zバッファにzの値を書き込んでおく。そうすると、今度同じx、y座標に描画する際、zの値をみてカメラに向かって、今書き込むもうとしているものがもとあるものより、手前にあるのか、おくにあるのかを判断する。手前にある場合はzバッファを更新するとともにそのx、y座標のRGB$\alpha$も更新し、おくにある場合はなにもしない。そうすることにより3Dをうまく表示している。
 
-%OSMesaはポリゴンと呼ばれる三角形の各頂点座標からy座標ごとにspanと呼ばれる構造体を生成し、そのspanのZの値をみながらいったんメモリに書き出し、それをまとめてframe bufferに書き出す。\\
+%OSMesaはポリゴンと呼ばれる三角形の各頂点座標からy座標ごとにSPANと呼ばれる構造体を生成し、そのSPANのZの値をみながらいったんメモリに書き出し、それをまとめてframe bufferに書き出す。\\
 %テクスチャを使用する場合は、各頂点に対応したテクスチャ座標を持っており、その値からテクスチャのどのxy座標のRGBがその点に対応するかを計算してRGBを書き込むようなシステムになっている。図\ref{fig:texture}では左にポリゴンが書かれており、各頂点にはxyz座標とテクスチャに対応する相対比がある。その相対比からテクスチャのどの部分がポリゴンに対応しているかがわかる。それによりテクスチャの黒い線が左のポリゴン上の1行の線にマッピングされる。
 \begin{figure}[htb]
 \begin{center}
@@ -24,47 +25,53 @@
 %\subsection{ダブルバッファリング}
 %ダブルバッファリングとは1画面が描画している間に次に描画する画像を裏でいったん生成しておき、描画する画像を切り替える手法である。画面を一気に切り替えるため、ちらつきがなくなる。
 \section{高速化する部分}
-OSMesaの機能を分割し、SPUにTaskとして割り振る方法はいくつか考えることができる。我々は最初テクスチャのついてないオブジェクトを対象とし、spanをzバッファでみながら描画していく方法を高速化した。高速化する部分のコードは以下のようになっている。\\
-\small{
-\input{src/render_span_macro.c}
-}
-最初の３行が実際のコードに記述された物になる。しかし、OSMesaはマクロを多用して実装されている。このマクロを展開したコードをいかに示す。
+OSMesaの機能を分割し、SPUにTaskとして割り振る方法はいくつか考えることができる。我々は最初テクスチャのついてないオブジェクトを対象とし、SPANをZバッファでみながら描画していく方法を高速化した。高速化する部分のコードは以下のようになっている。
+
 \small{
 \input{src/render_span.c}
 }
-コードを説明する前にコードで用いられているspanについて先に説明しておく。spanとは次のような構成からなっている。\\
+\normalsize {
+最初の３行が実際のコードに記述された物になる。しかし、OSMesaはマクロを多用して実装されている。このマクロを展開したコードをいかに示す。
+}
+\small{
+\input{src/render_span.c}
+}
+\normalsize
+コードを説明する前にコードで用いられているSPANについて先に説明しておく。SPANとは次のような構成からなっている。
+
 \begin{table}[htb]
 \begin{center}
 \begin{tabular}{|c|l|}
 \hline
-x、y、z & 生成されるspanの左端のx、y、z座標 \\ \hline
-red、green、blue、alpha & 生成されるspanの左端のRGB$\alpha$情報 \\ \hline
-end & 生成されるspanの長さ \\
+x、y、z & 生成されるSPANの左端のx、y、z座標 \\ \hline
+red、green、blue、alpha & 生成されるSPANの左端のRGB$\alpha$情報 \\ \hline
+end & 生成されるSPANの長さ \\
 & (x、y)からこの長さの分だけ描画される\\ \hline
-zStep  & 生成されるspanのxが1増加したときの\\
+zStep  & 生成されるSPANのxが1増加したときの\\
 &zの増加量 \\ \hline
-redStep,greenStep,blueStep,alphaStep & 生成されるspanのxが1増加したときの\\
+redStep,greenStep,blueStep,alphaStep & 生成されるSPANのxが1増加したときの\\
 &RGB$\alpha$の増加量 \\ \hline
 \end{tabular}
 \caption{SPANの情報}
-\label{table:span}
+\label{table:SPAN}
 \end{center}
 \end{table}
 
 \begin{figure}[htb]
 \begin{center}
-\includegraphics{./fig/span_data.eps}
+\includegraphics{./fig/SPAN_data.eps}
 \end{center}
-\caption{span data}
-\label{fig:span_data}
+\caption{SPAN data}
+\label{fig:SPAN_data}
 \end{figure}
-図\ref{fig:span_data}で、spanの構造体を表している。同じy座標に対しての描画する一番左端のx、y、z座標とその位置に対するRGB$\alpha$が与えられ、その位置から描画される長さ(end)、xが1増加したときの各情報の増加量がこのコードに達するまでに計算されてきた。\\
-つまりこのコードでは、まず与えられたspanのx、y座標からzバッファのアドレ
+図\ref{fig:SPAN_data}で、SPANの構造体を表している。同じy座標に対しての描画する一番左端のx、y、z座標とその位置に対するRGB$\alpha$が与えられ、その位置から描画される長さ(end)、xが1増加したときの各情報の増加量がこのコードに達するまでに計算されてきた。
+
+つまりこのコードでは、まず与えられたSPANのx、y座標からzバッファのアドレ
 スを計算する。次にそのx、y座標からzが計算され今まで計算されてきたzとの比
 較を行う。この比較によって今まで与えられたポリゴン情報と今与えられたポリ
 ゴン情報のどちらがカメラからみて手前にあるかを計算する。もし、対応する
-spanが手前にある場合はそのx、y座標にRGB$\alpha$を更新し、zバッファを更新
-しておく。こうすることにより、今までのspanからどれが一番手前の情報化を保
+SPANが手前にある場合はそのx、y座標にRGB$\alpha$を更新し、zバッファを更新
+しておく。こうすることにより、今までのSPANからどれが一番手前の情報化を保
 持しておく。その後で、x座標を1ずらす際にRGB$\alpha$とzの更新が行われる。
 それをend(長さ）分繰り返しておく。それが1画面分終了したら、描画にうつる。
 
@@ -73,23 +80,29 @@
 \section{実装}
 zバッファは1ピクセルのx座標、y座標に対してのz情報である。それを各SPUで大
 量(現在の日本のテレビ規格だと1920×1080)に持つと、
-$1920\times1080\times4=8294400$byteのメモリ量が必要となりモリが不足する。また、同じx座標、y座標のzバッファに対し、別のSPUで処理すると、同じ1ピクセルを別のSPUが描画することになるため、単純に分割することはできない。\\
-そこで我々はspanを生成し、描画するルーチンからy座標ごとにspanをソートして持っておく。各SPUには、y座標が一致しているspanが送信される。y座標が一致しているspanが複数のSPUに対して送信されることはない。\\
-例えば、同じy座標のspanが複数のポリゴンから生成されたとする。そのspanはすべて同じリストに追加される。y座標毎にspanのリストを一定数とり、そのリストを更にDMA量にあわせてリスト化する。ここではy座標ごとのspanのリストをspanlistとする。\\
+$1920\times1080\times4=8294400$byteのメモリ量が必要となりモリが不足する。また、同じx座標、y座標のzバッファに対し、別のSPUで処理すると、同じ1ピクセルを別のSPUが描画することになるため、単純に分割することはできない。
+
+そこで我々はSPANを生成し、描画するルーチンからy座標ごとにSPANをソートして持っておく。各SPUには、y座標が一致しているSPANが送信される。y座標が一致しているSPANが複数のSPUに対して送信されることはない。
+
+例えば、同じy座標のSPANが複数のポリゴンから生成されたとする。そのSPANはすべて同じリストに追加される。y座標毎にSPANのリストを一定数とり、そのリストを更にDMA量にあわせてリスト化する。ここではy座標ごとのSPANのリストをSPANLISTとする。
+
 そうすることにより、各SPUは1ライン分のフレームバッファだけを持つだけでよ
 く、メモリの問題も解決する。まず最初に高速化するルーチンのところにきた
-span情報をy座標ごとに生成する。(図\ref{fig:y_list})\\
+SPAN情報をy座標ごとに生成する。(図\ref{fig:y_list})
+
 \begin{figure}[htb]
 \begin{center}
 \includegraphics[height=7cm]{./fig/spanlist.eps}
 \end{center}
-\caption{spanpacklist}
+\caption{SPANPACKLIST}
 \label{fig:y_list}
 \end{figure}
-しかし、y座標ごとに生成されたspanを使用するSPUの数に単純に分割するだけではあまり効率が良くない。そこで、y座標ごとに生成されたspanのリストを更にまとめたうえで、リスト化する。ここでは64個のy座標ごとのspanのリストをまとめている。それをSPUの数分つくり、リストにする。図で示された四角形はまとめられたリストを表す。ここではSPUが受け取る最初のリストをspanpacklistと呼ぶことにする。ここで64個のy座標ごとのリストを作るのはアドレスの転送回数を減らすことにある。\\
-そこからy座標ごとのspanのリストをDMAでとってくる。SPUが実際に持つspanは同じy座標のみで、zバッファは1行分だけでよい。
+しかし、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})\\
+SPANを生成して、描画している間にもPPUは動くことができる。今回の実装ではダブルバッファを用いている。つまり、PPUではSPUが描画している間、次のSpanを生成し、SPUに送るSpanのリストを作っている。SPUも同時にSPANを読み込むときにダブルバッファで読み込んでいる。(図\ref{fig:parallel})
+
 \begin{figure}[htb]
 \begin{center}
 \includegraphics[height=8cm]{./fig/parallel.eps}
@@ -100,7 +113,8 @@
 そうすることにより、PPUとSPUが効率よく使われ更なる高速化が得られている。
 \subsection{パイプライン}
 CellはDMAの機能を持っているので、パイプライン的な処理が可能となる。基本的な要素
-としてRead、Exec、Writeから構成できる。(図\ref{fig:pipeline})\\
+としてRead、Exec、Writeから構成できる。(図\ref{fig:pipeline})
+
 \begin{figure}[htb]
 \begin{center}
 \includegraphics[width=15cm,height=3cm]{./fig/pipeline.eps}
@@ -109,15 +123,17 @@
 \label{fig:pipeline}
 \end{figure}
 \subsection{SPUプログラム}
-spanpacklistとダブルバッファを用いてSPUのプログラムを記述すると以下のようになる。
+SPANPACKLISTとダブルバッファを用いてSPUのプログラムを記述すると以下のようになる。
 \small{
 \input{src/spe_main.c}
 }
 
+\normalsize
 ほとんどの部分がダブルバッファのDMA制御を行っている。計算を行っている部分はPPUのみで行われていたコードにDMAのダブルバッファを考慮したものである。
 \small{
 \input{src/calc.c}
 }
+\normalsize
 ダブルバッファは入力用の構造体を二つ、出力用の構造体二つで構成されている。
 \section{評価}
 \subsection{実行速度比較}