--- a/paper/chapter4.tex	Wed Feb 08 21:49:40 2012 +0900
+++ b/paper/chapter4.tex	Thu Feb 09 04:31:13 2012 +0900
@@ -1,21 +1,32 @@
 \chapter{Ceriumの改良}
 本章では、Cerium に行った改良について説明する。
-Cerium のレンダリングの例題として ball\_bound を使用し、それを元に改良の効果を示していく。まず、改良前の 計測結果を示す。
+Cerium のレンダリングの例題として ball\_bound と panel を使用し、それを元に改良の効果を示していく。まず、改良前の 計測結果を示す。(\tabref{ball_bound_flat}) (\tabref{panel_flat})
 
 \begin{table}[!htb]
   \begin{center}
-    \caption{Cerium 改良前 (ball bound)} \label{tab:rendering_flat}
+    \caption{Cerium 改良前 (ball bound)} \label{tab:ball_bound_flat}
     \hbox to\hsize{\hfil
       \begin{tabular}{|c|c|c|c|} \hline
          FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
-         30.2FPS & 1.8\% & 74.3\% & 23.7\% \\ \hline
+         30.2 & 1.8\% & 74.3\% & 23.7\% \\ \hline
       \end{tabular}\hfil}
   \end{center}
 \end{table}
 
-Mail の待ち時間が 約70\%あり、処理時間の大部分を占めている。この Mail の待ち時間を削減するために Task をグルーピングする TaskArray, ソフトウェアMailQueue の実装を行った。また RenderinEngine の Task 内には、明示的な DMAロードが記述されており、アーキテクチャ依存となっている。そこでアーキテクチャ依存の記述を避けるために、MemorySegment を実装した。
+\begin{table}[!htb]
+  \begin{center}
+    \caption{Cerium 改良前 (panel)} \label{tab:panel_flat}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|c|c|c|} \hline
+         FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
+         4.0 & 21.3\% & 11.1.\% & 67.6\% \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
 
 
+特に ball bound では Mail の待ち時間が 約70\%あり、処理時間の大部分を占めている。この Mail の待ち時間を削減するために Task をグルーピングする TaskArray, ソフトウェアMailQueue の実装を行った。また RenderinEngine の Task 内には、明示的な DMAロードが記述されており、アーキテクチャ依存となっている。そこでアーキテクチャ依存の記述を避けるために、MemorySegment を実装した。
+
 \section{TaskArray}
 本研究では新しい Task として Task Array を実装した。 Cerium では Task と TaskList 毎に Mail を通知し、SPE の Mail の待ち時間が発生する問題があった。PPE 側で実行される Task もあるなかで、SPE側の Task を一つ一つ Task 毎に依存関係を処理しており、SPE への TaskList 要求や、次の Mail 書き込み待ちなど、Mail 通知の対応が遅れることが考えられる。Mail 通知の対応が遅れた分 SPE はアイドル状態となってしまい、稼働率が下がってしまう。この問題を解決するために、我々は Task Array を提案、実装した。 Task Array を使用することで、複数の Task をまとめる Task のグルーピングが行える。複数の Task を ひとつの Task Array として登録すると、依存関係の処理が Task Array ひとつ分で収まる。依存関係の処理には Mail 通知を行なっていたので 依存関係の処理が減少する分、 Mail 通知の回数も少なくなる。これによって、Mail 待ちによる SPE のアイドル状態の時間を減少させることができると考える。例えば TaskArray のサイズが4、TaskList のサイズが4、処理するべき Task の数が16の場合だとする。この時に TaskArray を使用すると、4つ必要だった TaskList が1つで済み、さらに16Task分の依存関係の解決が4つのTaskArray分で済む。(\figref{taskarray}) これによって Task 毎の Mail通知と TaskList 毎のMail通知の回数が合わせて 四分の一となる。このようにTaskArrayを用い Mail 自体の回数を減らし、待ち時間を削減できると考える。
 
@@ -73,65 +84,102 @@
 \item[spawn\_task\_array: ] Task Array の中のすべての Task が書きこまれたかどうかをチェックする。TaskArray では指定された Task の数と、実際に登録された Task の数が同一か計算し、異なってた場合にはエラー文を返す。これは DMA ロードの際のサイズを合わせる為、正確に数を合わせなければならない。
 \end{description}
 
-この TaskArray をRenderingEngine の DrawSpanTask に適応させた。レンダリングの例題は ball bound を用いた。その効果を示す。wor(\tabref{taskarray_ballbound})。
+この TaskArray を RenderingEngine の DrawSpanTask に適応させた。レンダリングの例題は ball bound と panel を用いた。TaskArray の大きさは 8 である。その効果を示す。(\tabref{taskarray_ballbound}) (\tabref{taskarray_panel})
 
 \begin{table}[!htb]
   \begin{center}
-    \caption{Task Arrayの効果(ball bound)} \label{tab:taskarray_ballbound}
+    \caption{Effect of Task Array(ball bound)} \label{tab:taskarray_ballbound}
     \hbox to\hsize{\hfil
       \begin{tabular}{|c|c|c|c|c|} \hline
         TaskArray & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
-        未使用 & 30FPS & 1.8\% & 76.2\% & 22.0\% \\ \hline
-        使用 & 32.2FPS & 2.5\% & 66.7\% & 30.8\% \\ \hline
+        未使用 & 30.0 & 1.8\% & 76.2\% & 22.0\% \\ \hline
+        使用 & 32.2 & 2.5\% & 66.7\% & 30.8\% \\ \hline
       \end{tabular}\hfil}
   \end{center}
 \end{table}
 
 mail の待ち時間が 約10\% 削減され、FPSの向上があり、TaskArray による効果が見られた。
 
-\section{MailQueue}
-Task の完了通知や、アイドル状態の SPE に Task のリストの情報を通知するために Mail を使用している。Cell の設計では、その通知に使われる SPE からの書き出しMailのQueueのサイズは1である。ハードウェアの設計として、Mailを書き出す場合、前回のMailがPPE側から読み込まれていない場合に、PPE側の読み出しでMailboxが空き状態になるまで、SPEはアイドル状態となる。するとPPE側のMail読み出し処理が追いつかない場合には、SPE側に余計な待ち時間が入ってしまう。そこで、ソフトウェアMailQueue を実装した。ハードウェアのMailboxへの書き込みができない場合には、ソフトウェアMailQueueへ書き出し、Mail の書き出し待ちをなくす。代わりに割り当てられたTaskListをすべて処理したあとに、MailQueueに残っているMailをすべて書き出す処理を行う。
-
-MailQueueの大きさはメモリ容量の限り自動で拡張される。以下にball bound の例題での MailQueue の有無における測定結果を示す(\tabref{mailqueue})。
-
 \begin{table}[!htb]
   \begin{center}
-    \caption{MailQueue の効果(ball bound)} \label{tab:mailqueue}
+    \caption{Effect of Task Array(panel)} \label{tab:taskarray_panel}
     \hbox to\hsize{\hfil
       \begin{tabular}{|c|c|c|c|c|} \hline
-        MailQueue & FPS & DMA転送待ち時間 &  mailの待ち時間 & SPE稼働率\\ \hline
-        なし & 32.2FPS & 2.5\% & 66.7\% & 30.8\% \\ \hline
-        あり & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline
+        TaskArray & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
+        未使用 & 4.0 & 21.3\% & 11.1\% & 67.6\% \\ \hline
+        使用 & 4.2 & 22.5\% & 5.7\% & 71.8\% \\ \hline
       \end{tabular}\hfil}
   \end{center}
 \end{table}
 
-Mail の待ち時間の割合が減少し、8FPSの向上がみられた。ソフトウェア MailQueue によって Mail の書き出しタイミングを変更することで、Mail の待ち時間を削減することができた。PPE 側では、SPEからの Mail の確認は一度の ループ文で行なっている。Mail を確認しおえ、そのループ文を抜けてしまうと、次に Mail を確認するまでに PPE 側の Task 処理が挟まれる。よって、SPE 側の Mail 通知は一度に多く行った方が、PPE側の Mail 確認がスムーズに行われ、結果 SPE の稼働率向上に繋がると言える。ソフトウェアMailQueue では Mail をキューイングし一度に書き出すので、この点でも効果がある。
+\section{MailQueue}
+Task の完了通知や、アイドル状態の SPE に Task のリストの情報を通知するために Mail を使用している。Cell の設計では、その通知に使われる SPE からの書き出しMailのQueueのサイズは1である。ハードウェアの設計として、Mailを書き出す場合、前回のMailがPPE側から読み込まれていない場合に、PPE側の読み出しでMailboxが空き状態になるまで、SPEはアイドル状態となる。するとPPE側のMail読み出し処理が追いつかない場合には、SPE側に余計な待ち時間が入ってしまう。そこで、ソフトウェアMailQueue を実装した。ハードウェアのMailboxへの書き込みができない場合には、ソフトウェアMailQueueへ書き出し、Mail の書き出し待ちをなくす。(\figref{mailqueue_flow})
+
+\begin{figure}[htb]
+  \begin{center}
+    \includegraphics[scale=0.6]{./images/mailqueue1.pdf}
+  \end{center}
+  \caption{mailqueue flow}
+  \label{fig:mailqueue_flow}
+\end{figure}
+
+MailQueueの大きさはメモリ容量の限り自動で拡張される。以下に ball bound と panelの例題での MailQueue の有無における測定結果を示す(\tabref{mailqueue})。
+
+\begin{table}[!htb]
+  \begin{center}
+    \caption{Effect of MailQueue(ball bound)} \label{tab:mailqueue}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|c|c|c|c|} \hline
+        MailQueue & FPS & DMA転送待ち時間 &  mailの待ち時間 & SPE稼働率\\ \hline
+        なし & 32.2 & 2.5\% & 66.7\% & 30.8\% \\ \hline
+        あり & 41.7 & 3.3\% & 56.8\% & 40.0\% \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
+
+Mail の待ち時間の割合が減少し、ball bound では8FPSの向上がみられた。ソフトウェア MailQueue によって Mail の書き出しタイミングを変更することで、Mail の待ち時間を削減することができた。PPE 側では、SPEからの Mail の確認は一度の ループ文で行なっている。Mail を確認しおえ、そのループ文を抜けてしまうと、次に Mail を確認するまでに PPE 側の Task 処理が挟まれる。よって、SPE 側の Mail 通知は一度に多く行った方が、PPE側の Mail 確認がスムーズに行われ、結果 SPE の稼働率向上に繋がると言える。ソフトウェアMailQueue では Mail をキューイングし一度に書き出すので、この点でも効果がある。
+
+\begin{table}[!htb]
+  \begin{center}
+    \caption{Effect of use MailQueue(panel)} \label{tab:mail_panel}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|c|c|c|c|} \hline
+        MailQueue & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
+        なし & 4.2 & 22.5\% & 5.7\% & 71.8\% \\ \hline
+        あり & 4.2 & 23.7\% & 4.1.\% & 72.3\% \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
+
+panel では描画の処理に時間がかかるので、稼働率は70\%を超えている。mail 待ちは5.7\%と全体の比率からは低い値となっているため、MailQueueの効果はあまり見られない。
 
 \section{MemorySegment}
 CreateSpanTask 内では明示的に DMA転送命令を行なっている。これは処理するデータ構造上の理由である。しかし、DMA転送は Cell のアーキテクチャに依存した機能である。また Task に登録された input data と output data は自動的に TaskManager によってパイプライン化されるが、明示的にDMA転送を行う場合には、手動でのパイプライン処理を行う必要がある。そこで、Task 内でのデータの入出力の機能を 抽象化する MemorySegment を実装した。MemorySegment によって DAM転送は隠蔽され、アーキテクチャ依存の記述を避けることができる。またメモリ操作も抽象化される。
 
-
 CreateSpanTask 内の明示的なDMA転送の例を示す。
 
 \begin{verbatim}
 create_span() {
 
-   tmp_spack = spack;
-   spack = send_spack;
-   send_spack = tmp_spack;
+   loop() {
 
-   smanager->dma_wait(SPAN_PACK_STORE);
-   smanager->dma_store(send_spack, (memaddr)spackList[prev_index],
-                       sizeof(SpanPack), SPAN_PACK_STORE);
+     tmp_spack = spack;
+     spack = send_spack;
+     send_spack = tmp_spack;
+
+     smanager->dma_wait(SPAN_PACK_STORE);
+     smanager->dma_store(send_spack, (memaddr)spackList[prev_index],
+                         sizeof(SpanPack), SPAN_PACK_STORE);
 
-   smanager->dma_load(spack, (memaddr)spackList[index],
-                       sizeof(SpanPack), SPAN_PACK_LOAD);
+     smanager->dma_load(spack, (memaddr)spackList[index],
+                         sizeof(SpanPack), SPAN_PACK_LOAD);
 
-   prev_index = index;
-   smanager->dma_wait(SPAN_PACK_LOAD);
+     prev_index = index;
+     smanager->dma_wait(SPAN_PACK_LOAD);
 
-   span_calc(spack);
+     span_calc(spack);
+
+  }
 
 }
 
@@ -149,18 +197,22 @@
 \begin{verbatim}
 create_span() {
 
-   smanager->wait_segment(span_put_ms);
+   loop() {
 
-   span_put_ms = span_get_ms;
-   smanager->put_segment(span_put_ms);
+     smanager->wait_segment(span_put_ms);
+
+     span_put_ms = span_get_ms;
+     smanager->put_segment(span_put_ms);
 
-   span_get_ms = smanager->get_segment((memaddr)spackList[index], span_ml);
-   smanager->wait_segment(span_get_ms);
+     span_get_ms = smanager->get_segment((memaddr)spackList[index], span_ml);
+     smanager->wait_segment(span_get_ms);
 
-   prev_index = index;
-   spack = (SpanPackPtr)span_get_ms->data;
+     prev_index = index;
+     spack = (SpanPackPtr)span_get_ms->data;
 
-   span_calc(spack);
+     span_calc(spack);
+
+   }
 
 }
 \end{verbatim}
@@ -200,18 +252,20 @@
     \hbox to\hsize{\hfil
       \begin{tabular}{|c|c|c|c|c|} \hline
         & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
-        改良前 & 30.2FPS & 1.8\% & 74.3\% & 23.7\% \\ \hline
-        改良後 & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline
+        改良前 & 30.2 & 1.8\% & 74.3\% & 23.7\% \\ \hline
+        改良後 & 41.7 & 3.3\% & 56.8\% & 40.0\% \\ \hline
       \end{tabular}\hfil}
   \end{center}
 \end{table}
+
+
 Mail の待ち時間、DMA転送の待ち時間がともに削減され、稼働率とFPSの向上が見られた。
 
 本研究で行った改良の加え、Cerium 開発後からの改良である、Task のパイプライン化、Texture cache の使用の効果をまとめる(\tabref{imp_result})
 
 \begin{table}[!htb]
   \begin{center}
-    \caption{Ceriumの改良の効果(ball bound)} \label{tab:imp_result}
+    \caption{Ceriumの改良の効果(panel)} \label{tab:imp_result}
     \hbox to\hsize{\hfil
       \begin{tabular}{|c|c|c|c|c|} \hline
         & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
@@ -221,7 +275,33 @@
   \end{center}
 \end{table}
 
-Cerium 開発後からの改良の結果、FPS が17上昇し、稼働率が18\%向上した。
+ball bound では Cerium 開発後からの改良の結果、FPS が17上昇し、稼働率が18\%向上した。
+
+\begin{table}[!htb]
+  \begin{center}
+    \caption{Ceriumの改良の効果(ball bound)} \label{tab:imp_result}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|c|c|c|c|} \hline
+        & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
+        改良前 & 4.0 & 21.3\% & 11.1.\% & 67.6\% \\ \hline
+        改良後 & 4.2 & 22.5\% & 5.7\% & 71.8\% \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
+
+panel では Cerium 開発後からの改良の結果、FPS が0.2上昇し、稼働率が約4\%向上した。
+
+\begin{table}[!htb]
+  \begin{center}
+    \caption{Cerium の歴史} \label{tab:imp_result}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|c|c|c|c|} \hline
+        & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
+        改良前 & 4.0 & 21.3\% & 11.1.\% & 67.6\% \\ \hline
+        改良後 & 4.2 & 22.5\% & 5.7\% & 71.8\% \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
 
 \subsubsection{OpenGLとの比較}