|
0
|
1 \section{Cerium の評価と考察}
|
|
|
2 Cerium Rendering Engine を用いて、
|
|
|
3 テクスチャを貼った一つの立方体を回転させるというプログラムを実行した。
|
|
|
4
|
|
|
5 今回、\figref{fig:cerium} で示した Task に対する CPU の割り振りは
|
|
|
6 \tabref{tab:hyoka1} とする。
|
|
|
7
|
|
|
8 \begin{table}[htbp]
|
|
|
9 \caption{Task の実行 CPU} \label{tab:hyoka1}
|
|
|
10 \hbox to\hsize{\hfil
|
|
|
11 \begin{tabular}{c|l} \hline \hline
|
|
|
12 Task & CPU \\ \hline
|
|
|
13 SceneGraph to PolygonPack & PPE \\
|
|
|
14 Polygonpack to SpanPack & PPE \\
|
|
|
15 Rendering & SPE \\ \hline
|
|
|
16 \end{tabular}\hfil}
|
|
|
17 \end{table}
|
|
|
18
|
|
|
19
|
|
|
20 描画領域の大きさは 720x480 とし、
|
|
|
21 使用する SPE の数を変えて実行速度の比較を行った。
|
|
|
22
|
|
|
23 \begin{table}[htbp]
|
|
|
24 \caption{実行速度 (720x480)} \label{tab:hyoka3}
|
|
|
25 \hbox to\hsize{\hfil
|
|
|
26 \begin{tabular}{l|r} \hline \hline
|
|
|
27 実行環境 & 実行速度\\ \hline
|
|
|
28 PPE のみ & 74 FPS \\
|
|
|
29 PPE + SPE 1台 & 190 FPS \\
|
|
|
30 PPE + SPE 2台 & 245 FPS \\
|
|
|
31 PPE + SPE 3台 & 270 FPS \\
|
|
|
32 PPE + SPE 6台 & 293 FPS \\ \hline
|
|
|
33 \end{tabular}\hfil}
|
|
|
34 \end{table}
|
|
|
35
|
|
|
36 \tabref{tab:hyoka3} より、SPE の台数を増やす事によって、
|
|
|
37 実行速度が向上しているのがわかる。
|
|
|
38 しかし、正しく台数効果が出ているとは言えない。
|
|
2
|
39
|
|
3
|
40 %%原因として
|
|
|
41 %%
|
|
|
42 %%\begin{enumerate}
|
|
|
43 %%\item アルゴリズムのミス
|
|
|
44 %%\item 効率的なデータ及びコード分割がされていない
|
|
|
45 %%\item 全てのタスクを SPE 上で実行していない \label{list:d3}
|
|
|
46 %%\end{enumerate}
|
|
|
47 %%
|
|
|
48 %%等といった事が考えられる。
|
|
|
49 %%ここでは、原因(\ref{list:d3})について考察する。
|
|
2
|
50
|
|
3
|
51 今回の実験環境で、SPE 上で実行している Rendering タスクの処理は、
|
|
|
52 PPE から取得した Span から、実際に描画する RGB 値を計算して FrameBuffer に
|
|
|
53 書き込む事である。将来的にシェーディングやアルファブレンディングを
|
|
|
54 実装する事になるが、現在はそこまで多くの計算をしているわけではない。
|
|
|
55 主に PPE からの大量の Span データの取得、
|
|
|
56 そして FrameBuffer へのメモリコピーとなる。
|
|
|
57 従って、今回の実験結果は、Rendering タスク内のメモリネックが
|
|
|
58 影響しているものと考えられる。
|
|
|
59 この事に関し、描画領域を広げ、メモリコピーの量を増やす事で
|
|
|
60 検証していく必要がある。
|
|
2
|
61
|
|
|
62
|
|
|
63 %その原因として、TaskManager の実装の不備があげられる。
|
|
|
64
|
|
|
65 %現在、Cerium TaskManager には DMA でメインメモリから SPE 上にプログラムを
|
|
|
66 %ロードする機能を実装していないため、
|
|
|
67 %必要な時に必要なプログラムだけを SPE 上に置く事が出来ない。
|
|
|
68 %SPE の容量では、Cerium の全てのタスクを SPE 上に乗せる事は出来ないため、
|
|
|
69 %現在は Rendering のタスクだけを SPE 上にマッピングしてある。
|
|
|
70
|
|
|
71 %全てのタスクを SPE 上で実行できるようになれば、
|
|
|
72 %実行速度はさらに向上すると考えられる。
|
|
0
|
73
|
|
6
|
74 \subsection{Cerium の今後の課題}
|
|
|
75 Rendering のタスクだけを SPE 上で実行しているのは、
|
|
2
|
76 SPE の 256KB という容量では、現在の Cerium の全てのタスクを
|
|
3
|
77 SPE 上に乗せる事が出来ないからである。
|
|
2
|
78 これを回避するために、SPE プログラムの on-demand load の実装が必要となる。
|
|
|
79 実装の方法として、以下のような手段が考えられる。
|
|
|
80
|
|
|
81 \begin{enumerate}
|
|
|
82 \item メインメモリにマッピングした SPE プログラムを DMA で SPE 上にロードする
|
|
|
83 \label{list:com1}
|
|
|
84 \item SPE をタスクの数に対応するように起動し、それぞれにタスクを attach する
|
|
|
85 \label{list:com2}
|
|
|
86 \end{enumerate}
|
|
|
87
|
|
|
88 OS のカーネルレベルでは、SPE 毎に spufs と呼ぶ
|
|
|
89 仮想ファイルシステム(VFS) が与えられており、
|
|
|
90 仮想的なファイルとして SPE のリソース にアクセス可能な
|
|
|
91 インターフェース が設けられている \cite{spufs}。
|
|
|
92 そのため、6台以上の SPE を仮想的に起動する事が可能である。
|
|
|
93 (\ref{list:com2}) の手法では、実行するタスクが attach されている
|
|
|
94 SPE を切り替えながら実行していく。
|
|
|
95
|
|
0
|
96 全てのタスクを SPE 上で実行できるようになれば、
|
|
2
|
97 タスク単体の実行速度は向上すると考えられる。
|
|
|
98 しかし、SPE プログラムもしくは仮想 SPE の入れ替えのコストが発生するため、
|
|
|
99 プログラム全体として向上するかは検証する必要があり、
|
|
|
100 on-demand load の実装と共に、今後の課題として挙げられる。
|
