Mercurial > hg > Papers > 2011 > yutaka-jssst

comparison paper/datasegment.ind @ 10:99f297cb7d34

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
hi hi
author Shinji KONO <kono@ie.u-ryukyu.ac.jp>
date Thu, 11 Aug 2011 21:26:04 +0900
parents 504aea3b42be
children 6ba51690320a
comparison
equal deleted inserted replaced
9:504aea3b42be 10:99f297cb7d34
1 -title: Cerium における DataSegment API の設計 1 -title: Cerium における DataSegment API の設計
2 2
3 --abstract: 3 --abstract:
4
5 --Cell用Task Manager Cerium
6 4
7 本研究室では、Cell 用の並列TaskManager Ceriumを作成し、Rendering Engine を含む 5 本研究室では、Cell 用の並列TaskManager Ceriumを作成し、Rendering Engine を含む
8 ゲームや並列計算の例題の作成と評価を行ってきた。TaskManager と Rendering Engine はシューティングゲーム 6 ゲームや並列計算の例題の作成と評価を行ってきた。TaskManager と Rendering Engine はシューティングゲーム
9 やレーシングゲームを記述するのに十分な性能を持っており、台数効果も満足いくものと 7 やレーシングゲームを記述するのに十分な性能を持っており、台数効果も満足いくものと
10 なっている。しかし、この開発により Ceirum の問題点も明らかになってきている。 8 なっている。しかし、この開発により Ceirum の問題点も明らかになってきている。
11 本論文では、今まので Cerium の構成と問題点を記述し、新しい TaskManager の設計 9 本論文では、今まので Cerium の構成と問題点を記述し、新しい TaskManager の設計
12 方針を述べる。 10 方針を述べる。
11
12 --Cell用Task Manager Cerium
13
14 Cerium は PS3 (Cell) 用のゲームフレームワークであり、ソフトウェアレンダリングを含む
15 並列処理を Task 単位で記述する。今は C++ で記述されており、基本的な例題や、
16 シューティングなどの例題で妥当な性能がでている。
17
18 しかし、Taskの種類などが増え、記述が繁雑であるなどの欠点も明らかになっている。この
19 論文では Many Core 向けの改良を提案する。
13 20
14 --Ceriumでの並列プログラミングの問題点 21 --Ceriumでの並列プログラミングの問題点
15 22
16 Cerium では、ゲームプログラミング及び、sort や word count などの例題を書いたが、いくつかの問題点が明らかになっている。 23 Cerium では、ゲームプログラミング及び、sort や word count などの例題を書いたが、いくつかの問題点が明らかになっている。
17 24
63 70
64 これらのデータの管理は、中心となるアルゴリズムとは別に並列実行を行うアーキテクチャに特化した処理が必要となる。例えば、分散環境で並列処理するのか、MPIなのか、Cell や Open CL なのかによって異なる。これらを、すべて Task という一括りで扱うと並列計算しない複雑なTaskができてしまう。 71 これらのデータの管理は、中心となるアルゴリズムとは別に並列実行を行うアーキテクチャに特化した処理が必要となる。例えば、分散環境で並列処理するのか、MPIなのか、Cell や Open CL なのかによって異なる。これらを、すべて Task という一括りで扱うと並列計算しない複雑なTaskができてしまう。
65 72
66 これらのデータ管理用の Task は、本質的には Data Segment に対する Iterator であり、ライブラリまたはコンパイラにより生成されるべきものだと考えられる。 73 これらのデータ管理用の Task は、本質的には Data Segment に対する Iterator であり、ライブラリまたはコンパイラにより生成されるべきものだと考えられる。
67 74
75 --Task 内部での Task 生成
76
77 Cerium では、複数の input と output を決めたパイプライン実行が通常であるが、
78 Task の途中で Main Memory を参照したいことが良くある。
79
80 描画Texture のデータ
81 SceneGraphの次のノード
82
83 これらは実行時にしか次のデータのアドレスを決定することができない。これを読み出し前のTaskと
84 読み出し後のTaskに分割して、さらにパイプライン実行してやると良いが、この記述は今までの
85 Cerium では不可能で、明示的な DMA API を使う必要があった。
86
87 Task内部でTask生成をしてやると、これを記述することが可能だが、TaskManagerの複雑度が上がってしまう
88 とう問題点があった。
89
68 --Data Segment を用いた Cerium の再設計 90 --Data Segment を用いた Cerium の再設計
69 91
70 Cell 用のTaskManager Cerium の再設計の方針としては以下のようになる。 92 Cell 用のTaskManager Cerium の再設計の方針としては以下のようになる。
71 93
72 CbCのCode segment の導入 94 CbCのCode segment の導入
73 定型的な Data 単位である Data 95 定型的な Data 単位である Data segment
96 Data segment の型の指定
97 Task Manager の Code segment による実装
98 Code segment (Task) の生成API
74 99
75 ---Data Segment の型 100 ---Data Segment の型
76 101
102 Cerium では Task の入出力は単なる memory buffer だったので型が存在しなかった。今回は Message Pack
103 を用いて、Json 的に型を指定する。
104
105 Data segment は様々なメモリ上に位置するので、それを識別する必要がある。Many Core 版の Cerium では、
106
107 Main Memory
108 SPU local memory
109 Cache
110
111 の三種類を用意する。これらは DMA や Cache 操作命令を通して移動する。移動したものは同一のものである。Cell SPUのTask や Many Core では、当然だが lcoal memory や Cache に乗らない限りアクセスできない。
112
113 Data segment は、Code Segment に input と output として接続される。
114
77 ---Data Segment のAPI 115 ---Data Segment のAPI
116
117 Data Segment は以下のAPIを持っている
118
119 create
120 read
121 update
122 delete
123
124 Create は allocate に相当する。型と位置を指定して create する。Main Memory 上の Data segment を読み書きする場合は、local memory または Cache を通してパイプライン的に実行される。
125
126 複数のCode Segment から update が起きる場合は、以下の操作を選択する。
127
128 Queuing
129 Update
130 Proority Queue
131
132 生成された Data segment は synchronized queue として使うことができる。
78 133
79 ---Task Dependendcy 134 ---Task Dependendcy
80 135
136 今までの Cerium では、\verb+task->wait_for(task1);+ という形で明示的に Task の依存性を指定していた。
137 この方法では、\verb+task+ の寿命(既に終了してしまった task を待つような場合)などの問題がある。
138
139 しかし、Code Segment は input / outpu Data Segment によって自然な依存関係を持つので、明示的な
140 \verb+wait_for+ は必要なくなる。
141
142 Code Segment と Data Segment は task を処理して行くうちに自然に消滅してしまう。Persistent な
143 データは明示的にデータベースに格納する必要がある。つまり、Data Segment に Persistentという
144 位置が存在する。
145
146 ---Pipeline Execution
147
148 Cerium では、Task のread/exec/write は三段のパイプラインで実行されていた。Data Segment は
149 Code Segment の実行の前に行われるが、他の Code Segment とオーバラップして実行して良い。
150 Data Segment には、Data Segment の位置を変更するための Code Segment が存在している。
151
152 つまり、Data Segment は複数の Code Segment ( この Data segment を待っている Code segment )
153 と、Data Segment の位置などを変える Code Segment などが付随している。
154
155 一つのCoreでは、Data Segment に付属する Code segment を順次実行することにより、パイプライン
156 を実行する。
157
158 Data Segment による依存関係を追い越さなければ並列実行は自由に行われる。これは、Task Scheduling
159 を担当する Code Segment によってアーキテクチャに合わせて実行される。
160
81 ---Data Segment Storage Type 161 ---Data Segment Storage Type
162
163 Data Segment には位置とIdentityを表す ID が付いている。Many Core 版ではメモリアドレス(64bit)
164 をIDとして使って良い。
165
166 SPUのようなlocal memoryでは、hash を使ってData Segmentの管理を行う。
167
168 Persistent な Data Segment では ID は使用する Database のtableとkeyを表す。
82 169
83 ---Data Segment の処理の記述 170 ---Data Segment の処理の記述
84 171
172 Data Segment は Message Pack でもあり、Json 的な木構造を持っている。これが Cerium の
173 SceneGraph に相当する。
174
85 --期待される効果 175 --期待される効果
86 176
177 Data Segment API は、これから実装することになるが、
178
179 Cerium の既存の例題が動くこと
180
181 が一つの基準となる。PS3 が無事ならば PS3 でも動かしたい。Core i7 系、GPGPU 系、Open CL での
182 共通のプログラミングフレームワークとして使用することができると期待している。
183
184 詳細なAPIは、これから決めることになると思うが、今のCeriumのAPI
185
186
187