Mercurial > hg > Papers > 2011 > yutaka-sigos
changeset 2:68e53d04ce7c
add file
| author | Yutaka_Kinjyo |
|---|---|
| date | Sun, 13 Mar 2011 03:02:01 +0900 |
| parents | 3d64a1fa8207 |
| children | 9d45d91eb5b1 |
| files | paper/ARC195OS117-32.tex paper/images/rendering3.bb paper/images/rendering3.pdf |
| diffstat | 3 files changed, 110 insertions(+), 21 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/ARC195OS117-32.tex Sat Mar 12 21:56:38 2011 +0900 +++ b/paper/ARC195OS117-32.tex Sun Mar 13 03:02:01 2011 +0900 @@ -85,7 +85,7 @@ %学生実験用にゲームフレームワーク Cerium を開発した。Cerium の TaskManager は 我々は並列プログラミング用のフレームーク Cerium TaskManager を開発している。Cerium は PS3/Cell, MacOSX, Linux -上で 動作する。 それぞれのプラットフォームで同じプログラムで動作できる。 +上で開発できる。それぞれのプラットフォームで同じプログラムで動作する。その中でも特にCellに特化しているといえる。 Cerium TaskManager では、関数やサブルーチンを Task として扱う。Task は Task 同士の依存関係 に従って、実行される。 Cell 上の場合、各SPEに Task が割り当てられ、並列に実行される。 @@ -138,24 +138,14 @@ 直接アクセスすることができず、PPE が利用するメインメモリ上のデータに アクセスするには DMA (Direct Memory Access) を用いる。 DMA 転送とは、CPU を介さずに周辺装置とメモリとの間でデータ転送ことで、 -Cell の場合はメインメモリと LS 間でデータの転送を行う。手順としては以下の様になる。 - -\begin{enumerate} - \item SPE プログラムが MFC (Memory Flow Controller) に対して - DMA 転送命令を発行 - \item MFC が DMA Controller を介して DMA 転送を開始。 - この間、SPE プログラムは停止しない。 - \item DMA 転送の終了を待つ場合、SPE プログラム内で転送の完了を待つ -\end{enumerate} - -この時、DMA 転送するデータとアドレスにはいくつか制限がある。 +Cell の場合はメインメモリと LS 間でデータの転送を行う。 +DMA 転送するデータとアドレスにはいくつか制限がある。 転送データが 16 バイト以上の場合、データサイズは 16 バイトの倍数で、 転送元と転送先のアドレスが 16 バイト境界に揃えられている必要がある。 転送データが 16 バイト未満の場合、データサイズは 1,2,4,8 バイトで、 転送サイズに応じた自然なアライメントである (転送サイズのバイト境界に 揃えられている) ことが条件となる。 - % }{ \section{Cerium の改良}\label{sec:Enum}\label{sec:item} @@ -173,7 +163,6 @@ SPEスケジューラは Task が処理完了になる毎に、Mailを Outbound Mailbox に書きこむので、PPE側でMailの読み込みが間に合わないと、待ちが入り、SPEの処理が 止まってしまう。 -%数字(mail time あたり？ちゃんと見れるといいけど) これを解消するためにMailQueueを導入した。MailQueueは、SPEから書き込みきれないMailを一時的に退避させるものである。 TaskListを書きだす時に溜まったQueueの中身をすべて書き出す。 @@ -188,15 +177,64 @@ PPE では mail をチェックするAPIを用いて、mail の有無を確認し、 \subsection{PipeLine化} -RenderinEngine... + +Cerium では RenderinEngine を実装している。RenderinEngine は大きく分けて、 +CreatePolygon, CreateSpan, DrawSpan, の +3つのTaskから構成されている。（\figref{fig:rendering-flow}） + +\begin{figure}[tb] + \begin{center} + \includegraphics[scale=0.4]{./images/rendering3.pdf} + \end{center} + \caption{レンダリングエンジンの流れ} + \label{fig:rendering-flow} +\end{figure} +Span とは、ポリゴンに対するある特定Y座に関するデータを抜き出したものである。 +この3つのTaskはそれぞれバリア同期を行いながら、順に実行される。 +Cerium において、バリア同期を行う場合には二つの待ち時間がある。 +\begin{itemize} +\item SPEが他のSPEを待つ時間 +\item バリア同期が完了し、PPE側で次のTaskが作られる時間 +\end{itemize} + +この二つの時間の間SPEの処理が止まり、処理性能の低下につながる。 +この待ち時間を回避するには、Taskの粒度を下げる、他のSPEの処理完了を待っているSPEに、別のTaskを割り当てる、等の方法がある。 +別のTaskを割り当てるにはTaskの実行をパイプライン化する方法がある。 + +そこで、特に処理の重いDrawSpanTask と、CreatePolygon,CreateSpan のTask でパイプライン化を行った。 +速度比較の対象として、SuperDandy と呼ばれる、学生実験で制作されたシューティングゲームを用いた。 + +\begin{table}[!htb] + \begin{center} + \caption{SPE の稼働率(busy\_ratio)} \label{tab:busy_ratio} + \ecaption{busy ration of spe} + \hbox to\hsize{\hfil + \begin{tabular}{|c|l|l|c|} \hline + & 改良前 & 改良後 & 性能\\ \hline + dandy & 47.2\% & 78.1\% & 向上 \\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} -DrawSpan... +\begin{table}[!htb] + \begin{center} + \caption{１秒辺りの Rendering Engine 全体の処理回数(Frame Per Second)} + \ecaption {hogehoge} \label{tab:FPS} + \hbox to\hsize{\hfil + \begin{tabular}{|c|l|l|c|} \hline + & 改良前 & 改良後 & 性能\\ \hline + dandy & 29.4 FPS & 49.5 FPS & 68\%向上 \\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} -数字 - -ほらね？ +パイプライン化した結果、SPEの稼働率が向上し、FPSも向上した。 +処理性能を維持するには、SPEはなるべく稼働させ続けなければならない。 +その為には処理をTaskに分割し、並列実行するだけでなく、バリア同期などで、 +SPEの待ち時間が発生することへ対処しないといけない。 +その対処の一つとしてそれにパイプライン化は有効である。 \subsection{Memory Access} @@ -204,13 +242,59 @@ ちゃんとデータ配分しないとまずい +\subsection{TaskArray} + +Task の依存関係を解決するために、SPEから Mail によってPPEへと処理が完了したTaskの情報が通知される。 +その際に、同じ種類のTaskは一つのMailでよい場合がある。 +そこで、我々は Task Array を提案、実装した。 +Task Array は、複数の Task をまとめて扱うことが出来る。Task Array に登録した順番で +依存関係を設定しているので、PPE で解決する Task の数が減り、 SPE からの TaskList 要求に応答しやすくなる。 +また、一度に多くの Task を TaskList に登録できるため、 SPE 側からの TaskList 要求の回数が減り、待ち時間が +生じる可能性が減る。 + +Rendering Engine の中で、最も数が多く生成される DrawSpanTask を Task Array 化した。 +地球と月を表示する例題を対象に効果を測った。 FPS(Frame Per Second) は、一秒間に +表示できる Frame 数のことである。 + +\begin{table}[htb] + \begin{center} + \caption{Rendering Engine の Task Array 化による比較} + \label{tab:rendering-taskarray-compare} + \begin{tabular}{|c|c|c|c|} + \hline + & Task & Task Array & 向上率\\ + \hline + FPS & 16.4 & 18.5 \% & 34\%\\ + \hline + dma wait & 3.34\% & 1.88\% & 2.34\%\\ + \hline + mail wait & 84\% & 69\% & 15\% \\ + \hline + \end{tabular} + \end{center} +\end{table} + +結果から DrawSpanTask を Task Array 化すると、FPS が上昇し、mail の wait 時間が減ったことが分かる。 +Rendering Engine では、 PPE 側でも処理をするべき Task があり、常に PPE が稼動している状態になって +いる。そのため mail を処理する時間が遅れ、SPE のmail 待ちが発生していると考えられる。 Task Array 化 +で Task をまとめることで SPE が一つの TaskList で多くの Task を実行できるようになったため、 TaskList +を要求する回数が減って、待ち時間が発生する回数も減少した。また、それは SPE からの mail の数が減った +ということなので、PPE 側の mail 処理の時間短縮になったと考えられる。 \subsection{SPEでのキャッシュ効果} -Cerium ではソフトウェアレンダリングを、Task で定義し、処理している。描画の際には、SPEのLocalstore(LS)へ必要なテクスチャの -情報を読み込む。この時に、頻繁にテクスチャを読み込む場合にはその読み込みがオーバヘッドが大きいになる。そこでキャッシュを実装した +Cerium ではソフトウェアレンダリングを、Task で定義し、処理している。描画の際には、SPEのLSへ必要なテクスチャの +情報を読み込む。SPE のメモリ領域は 256KB しかないため、テクスチャのデータを分割し転送する必要がある。 +そこで、Cerium ではテクスチャを8x8のブロックに分割し、必要な時に沿って、ブロックを転送する方法を取った。 +さらに、 + + +この時に、頻繁にテクスチャを読み込む場合にはその読み込みがオーバヘッドが大きいになる。そこでキャッシュを実装した ところ、読み込み回数を抑え、ボトルネックを解消することができた。 + + + 数字\\ はやーくなったね。