Mercurial > hg > Papers > 2012 > yutaka-master

comparison paper/chapter4.tex @ 15:3ffa20cb613d draft

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
fix
author Yutaka_Kinjyo <yutaka@cr.ie.u-ryukyu.ac.jp>
date Fri, 10 Feb 2012 18:18:27 +0900
parents cb430c965050
children 598336b53547
comparison
equal deleted inserted replaced
14:cb430c965050 15:3ffa20cb613d
1 \chapter{Ceriumの改良} 1 \chapter{Ceriumの改良}
2 本章では、Cerium に行った改良について説明する。 2 本章では、本研究で Cerium に行った改良について説明する。
3 Cerium のレンダリングの例題として ball\_bound と panel を使用し、それを元に改良の効果を示していく。まず、改良前の 計測結果を示す。(\tabref{ball_bound_flat}) (\tabref{panel_flat}) 3 Cerium のレンダリングの例題として ball\_bound と panel を使用し、それを元に改良の効果を示していく。まず、改良前の 計測結果を示す。(\tabref{ball_bound_flat}) (\tabref{panel_flat})
4 4
5 \begin{table}[!htb] 5 \begin{table}[!htb]
6 \begin{center} 6 \begin{center}
7 \caption{Cerium 改良前 (ball bound)} \label{tab:ball_bound_flat} 7 \caption{Cerium 改良前 (ball bound)} \label{tab:ball_bound_flat}
121 \end{center} 121 \end{center}
122 \caption{mailqueue flow} 122 \caption{mailqueue flow}
123 \label{fig:mailqueue_flow} 123 \label{fig:mailqueue_flow}
124 \end{figure} 124 \end{figure}
125 125
126 MailQueueの大きさはメモリ容量の限り自動で拡張される。以下に ball bound と panelの例題での MailQueue の有無における測定結果を示す(\tabref{mailqueue})。 126 MailQueueの大きさはメモリ容量の限り自動で拡張される。以下に ball bound と panelの例題での MailQueue の有無における測定結果を示す(\tabref{mail_ball})(\tabref{mail_panel})。
127 127
128 \begin{table}[!htb] 128 \begin{table}[!htb]
129 \begin{center} 129 \begin{center}
130 \caption{Effect of MailQueue(ball bound)} \label{tab:mailqueue} 130 \caption{Effect of MailQueue(ball bound)} \label{tab:mail_ball}
131 \hbox to\hsize{\hfil 131 \hbox to\hsize{\hfil
132 \begin{tabular}{|c|c|c|c|c|} \hline 132 \begin{tabular}{|c|c|c|c|c|} \hline
133 MailQueue & FPS & DMA転送待ち時間 & mailの待ち時間 & SPE稼働率\\ \hline 133 MailQueue & FPS & DMA転送待ち時間 & mailの待ち時間 & SPE稼働率\\ \hline
134 なし & 32.2 & 2.5\% & 66.7\% & 30.8\% \\ \hline 134 なし & 32.2 & 2.5\% & 66.7\% & 30.8\% \\ \hline
135 あり & 41.7 & 3.3\% & 56.8\% & 40.0\% \\ \hline 135 あり & 41.7 & 3.3\% & 56.8\% & 40.0\% \\ \hline
136 \end{tabular}\hfil} 136 \end{tabular}\hfil}
137 \end{center} 137 \end{center}
138 \end{table} 138 \end{table}
139 139
140 Mail の待ち時間の割合が減少し、ball bound では8FPSの向上がみられた。ソフトウェア MailQueue によって Mail の書き出しタイミングを変更することで、Mail の待ち時間を削減することができた。PPE 側では、SPEからの Mail の確認は一度の ループ文で行なっている。Mail を確認しおえ、そのループ文を抜けてしまうと、次に Mail を確認するまでに PPE 側の Task 処理が挟まれる。よって、SPE 側の Mail 通知は一度に多く行った方が、PPE側の Mail 確認がスムーズに行われ、結果 SPE の稼働率向上に繋がると言える。ソフトウェアMailQueue では Mail をキューイングし一度に書き出すので、この点でも効果がある。
141
142 \begin{table}[!htb] 140 \begin{table}[!htb]
143 \begin{center} 141 \begin{center}
144 \caption{Effect of use MailQueue(panel)} \label{tab:mail_panel} 142 \caption{Effect of use MailQueue(panel)} \label{tab:mail_panel}
145 \hbox to\hsize{\hfil 143 \hbox to\hsize{\hfil
146 \begin{tabular}{|c|c|c|c|c|} \hline 144 \begin{tabular}{|c|c|c|c|c|} \hline
149 あり & 4.2 & 23.7\% & 4.1.\% & 72.3\% \\ \hline 147 あり & 4.2 & 23.7\% & 4.1.\% & 72.3\% \\ \hline
150 \end{tabular}\hfil} 148 \end{tabular}\hfil}
151 \end{center} 149 \end{center}
152 \end{table} 150 \end{table}
153 151
154 panel では描画の処理に時間がかかるので、稼働率は70\%を超えている。mail 待ちは5.7\%と全体の比率からは低い値となっているため、MailQueueの効果はあまり見られない。 152
153 ball bound では Mail の待ち時間の割合が減少し、 8FPSの向上がみられた。ソフトウェア MailQueue によって Mail の書き出しタイミングを変更することで、Mail の待ち時間を削減することができた。PPE 側では、SPEからの Mail の確認は一度の ループ文で行なっている。Mail を確認しおえ、そのループ文を抜けてしまうと、次に Mail を確認するまでに PPE 側の Task 処理が挟まれる。よって、SPE 側の Mail 通知は一度に多く行った方が、PPE側の Mail 確認がスムーズに行われ、結果 SPE の稼働率向上に繋がると言える。ソフトウェアMailQueue では Mail をキューイングし一度に書き出すので、この点でも効果がある。panel では描画の処理に時間がかかるので、稼働率は70\%を超えている。mail 待ちは5.7\%と全体の比率からは低い値となっているため、MailQueueの効果はあまり見られない。
155 154
156 \section{MemorySegment} 155 \section{MemorySegment}
157 CreateSpanTask 内では明示的に DMA転送命令を行なっている。これは処理するデータ構造上の理由である。しかし、DMA転送は Cell のアーキテクチャに依存した機能である。また Task に登録された input data と output data は自動的に TaskManager によってパイプライン化されるが、明示的にDMA転送を行う場合には、手動でのパイプライン処理を行う必要がある。そこで、Task 内でのデータの入出力の機能を 抽象化する MemorySegment を実装した。MemorySegment によって DAM転送は隠蔽され、アーキテクチャ依存の記述を避けることができる。またメモリ操作も抽象化される。 156 CreateSpanTask 内では明示的に DMA転送命令を行なっている。これは処理するデータ構造上の理由である。しかし、DMA転送は Cell のアーキテクチャに依存した機能である。また Task に登録された input data と output data は自動的に TaskManager によってパイプライン化されるが、明示的にDMA転送を行う場合には、手動でのパイプライン処理を行う必要がある。そこで、Task 内でのデータの入出力の機能を 抽象化する MemorySegment を実装した。MemorySegment によって DAM転送は隠蔽され、アーキテクチャ依存の記述を避けることができる。またメモリ操作も抽象化される。
158 157
159 CreateSpanTask 内の明示的なDMA転送の例を示す。 158 CreateSpanTask 内の明示的なDMA転送の例を示す。
306 \begin{table}[!htb] 305 \begin{table}[!htb]
307 \begin{center} 306 \begin{center}
308 \caption{Cerium の開発から改良点のまとめ} \label{tab:imp_resultp} 307 \caption{Cerium の開発から改良点のまとめ} \label{tab:imp_resultp}
309 \hbox to\hsize{\hfil 308 \hbox to\hsize{\hfil
310 \begin{tabular}{|c|c|} \hline 309 \begin{tabular}{|c|c|} \hline
311 & 変更点 \\ \hline 310 改良時期　& 改良点 \\ \hline
312 & DrawSpanTask のパイプライン化 \\\hline 311 & DrawSpanTask のパイプライン化 \\\hline
313 & TASK\_DUMMY での依存関係の設定を排除 \\ \hline 312 & TASK\_DUMMY での依存関係の設定を排除 \\ \hline
314 & 依存関係の設定を Task 化で実現 \\ \hline 313 & 依存関係の設定を Task 化で実現 \\ \hline
315 & プロファイラの導入 \\ \hline 314 & プロファイラの導入 \\ \hline
316 & Texture cache の実装 \\ \hline 315 & Texture cache の実装 \\ \hline
316 & Prime Counter の実装 \\ \hline
317 本研究 & WordCount の実装 \\ \hline
317 本研究 & CreatePolygon部分のTask化 \\ \hline 318 本研究 & CreatePolygon部分のTask化 \\ \hline
318 本研究 & 光源機能の実装 \\ \hline 319 本研究 & 光源機能の実装 \\ \hline
319 本研究 & Task Array の実装 \\ \hline 320 本研究 & Task Array の実装 \\ \hline
320 本研究 & ソフトウェアMailQueue の実装 \\ \hline 321 本研究 & ソフトウェアMailQueue の実装 \\ \hline
321 本研究 & MemorySegment の実装 \\ \hline 322 本研究 & MemorySegment の実装 \\ \hline
325 326
326 \subsubsection{OpenGLとの比較} 327 \subsubsection{OpenGLとの比較}
327 328
328 OpenGL (Open Graphics Library) とは、Silicon Graphics 社が開発した、3D グラフィックス 329 OpenGL (Open Graphics Library) とは、Silicon Graphics 社が開発した、3D グラフィックス
329 処理のためのプログラミングインターフェースである。 330 処理のためのプログラミングインターフェースである。
330 学生実験で作成された SuperDandy(\figref{t_dandy}) を Task を用いない OpneGL 上で動作するバージョンを用意して、Cerium 331 学生実験で作成されたシューティングゲーム SuperDandy(\figref{t_dandy}) を Task を用いない OpneGL 上で動作するバージョンを用意して、Cerium
331 と性能を比較してみた。OpenGL は PPE だけで動作している。Cerium は今までの改良をすべて加えたもので、レンダリング部分が Task 化され並列処理される。 332 と性能を比較してみた。OpenGL は PPE だけで動作している。Cerium は今までの改良をすべて加えたもので、レンダリング部分が Task 化され並列処理される。
332 333
333 \begin{figure}[htb] 334 \begin{figure}[htb]
334 \begin{center} 335 \begin{center}
335 \includegraphics[scale=0.4]{./images/t_dandy.pdf} 336 \includegraphics[scale=0.4]{./images/t_dandy.pdf}
336 \end{center} 337 \end{center}
337 \caption{SuperDandy実行の様子} 338 \caption{SuperDandy実行の様子}
338 \label{fig:t_dandy} 339 \label{fig:t_dandy}
339 \end{figure} 340 \end{figure}
340 341
341 342 \begin{table}[!htb]
342 343 \begin{center}
343 \begin{table}[!htb] 344 \caption{シューティングゲーム「SuperDandy」の性能比較(OpenGL, Cerium))} \label{tab:dandy-compare}
344 \begin{center}
345 \caption{シューティングゲーム「dandy」の性能比較(OpenGL, Cerium))} \label{tab:dandy-compare}
346 \hbox to \hsize{\hfil 345 \hbox to \hsize{\hfil
347 \begin{tabular}{|c|l|l|c|} \hline 346 \begin{tabular}{|c|l|l|c|} \hline
348 & OpenGL & Cerium & 性能差\\ \hline 347 & OpenGL & Cerium & 性能差\\ \hline
349 dandy & 17.5 FPS & 49.5 FPS & 2.9 倍\\ \hline 348 dandy & 17.5 FPS & 49.5 FPS & 2.9 倍\\ \hline
350 \end{tabular}\hfil} 349 \end{tabular}\hfil}