Mercurial > hg > Members > kono > Cerium
annotate TaskManager/ChangeLog @ 625:60aa3f241b10
64bit mode worked on Mac OS X.
author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 16 Nov 2009 10:59:55 +0900 |
parents | 0decff4e867b |
children | 8843edf37c0e |
rev | line source |
---|---|
625
60aa3f241b10
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
1 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
60aa3f241b10
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
2 |
60aa3f241b10
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
3 やっぱり、TaskList の存在が許せない。あったとしても不定長でしょう。 |
60aa3f241b10
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
4 無駄なコピーが多すぎる。 |
60aa3f241b10
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
5 |
619 | 6 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
7 | |
8 Scheduler / TaskManger / TaskManagerImpl の区別が不明 | |
9 | |
10 Scheduler は SchedTask から直接見えないはずだが、SchedTask は、 | |
11 Scheduler は知っているが、TaskManager は知らない。これがかなりの | |
12 混乱を生んでいる。 | |
13 | |
14 SPU上では、TaskManager が存在しないのが原因らしいが、allcoate とかは、 | |
15 TaskManager が行うはず。なので、SPU上にもTaskManagerがある方が自然。 | |
16 | |
17 SchedTask が自分自身で scheduling してしまっているので、Scheduler | |
18 には、ほとんど仕事がない。なので、大半の処理を scheduler -> manager | |
19 経由で行うことになる。 | |
20 | |
614
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
21 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
22 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
23 要するに、SPE task 側から addOutData できればよい。 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
24 でも、別に、PPE側から計算してもよいはずだけどね。 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
25 そうすれば、renew task は取り外せる。 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
26 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
27 SchedDefineTask1(DrawSpanEnd,draw_span_end); |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
28 で、名前を指定させておいて、さらに、 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
29 SchedExternTask(DrawSpanEnd); |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
30 SchedRegisterTask(TASK_DRAW_SPAN_END, DrawSpanEnd); |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
31 で、新しく名前を要求するのって、なんとかならんの? 読みづらいんだよ。 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
32 DrawSpanEnd を、そのまま使ってもよさそうだけど? |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
33 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
34 せっかく、renew task を外したのに、HD crash で失ってしまいました。 |
4e44147d78ee
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
35 |
615
f7d78b3c1106
First addOutput rendering try failed.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
614
diff
changeset
|
36 add_param が順序を持っているのは見づらい。数字で指定する方が合理的。 |
f7d78b3c1106
First addOutput rendering try failed.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
614
diff
changeset
|
37 |
506 | 38 2009-10-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
39 | |
40 単純な、rbuf, wbuf + write return size の task のAPI | |
41 List DMA の API | |
42 投入 cpu 別の spawn method | |
43 Redering 時の内部からの DMA への直接アクセスへの禁止等など | |
44 | |
45 set_post で登録する関数も、task のrun関数と同じ型にした方が便利そう。 | |
46 | |
47 SPU側でも配列(TaskList)ではなく、TaskQueue で管理すれば、 | |
48 renew task は簡単に実装できる。 | |
49 | |
50 SchedTask の renew かそうでないかの区別は全部なくす。ex_init とかは、 | |
51 なくなるはず。その代わり TaskQueue で管理する。 | |
52 | |
53 TaskList に inListData/outListData が入っているのは、やはりおかしい。 | |
54 もっとコンパクトであるべき。 | |
55 | |
56 TaskList は、こまめに終了をPPE側へ知らせるのではなく、TaskListの | |
57 書き換えで知らせる方が良い。 | |
58 | |
59 SPUからPPUへ、create task 出来た方が良い。それはTaskList の書き出し | |
60 で行なう。 | |
61 | |
503 | 62 2009-10-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
63 | |
64 ようやっと直せました。inListData/outListData は別に転送しないで、 | |
65 一緒に転送してしまった方が良い。どうせ、いつも転送しているのだから。 | |
66 | |
67 word_count が fifo の方が高速なのは、どうにかしてください。 | |
68 | |
69 Renew Task の addInData は、メインメモリからDMAするので正しいらしい。 | |
70 直し方を間違えた。 | |
71 | |
72 Task をmemcpyして、TaskList に入れているが、List DMA に直すべき。 | |
73 Simple Task を常に起動して、List DMA task は、その中で、Renew Task | |
74 として起動するのが良いのでは? そうすれば、Task Load 自体を Task に | |
75 出来る。 | |
76 | |
77 Renew Task の実行順序が filo になっている。このあたり変なので、 | |
78 修正するべきでしょう。Renew用の TaskList を持てば良いんじゃないか? | |
79 task->self の ad-hoc な使い方が泣ける。ひどすぎます。 | |
80 | |
487 | 81 2009-10-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
82 | |
83 Task 内の create_task は、SchedTask に対してで、 | |
84 PPE 上では、Manager に対してだよね。だから、出来る | |
85 ことがかなり異なる。これは、まずいだろ? | |
86 | |
87 特に、PPE task に明示的に manager を渡すってのは、 | |
88 とっても変。 | |
89 | |
90 Renew Task の特別扱いが、いろいろ歪めているんだが、 | |
91 view.cc で使っているので落せない。 | |
92 | |
481
4896dffad67c
Double linked list modification done (tested on Mac OS X)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
468
diff
changeset
|
93 2009-10-05 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
4896dffad67c
Double linked list modification done (tested on Mac OS X)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
468
diff
changeset
|
94 |
4896dffad67c
Double linked list modification done (tested on Mac OS X)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
468
diff
changeset
|
95 TaskQueue のfree list の管理はシステムで一つであるべき。 |
503 | 96 TaskQueue は double linked list が当然らしい。 |
481
4896dffad67c
Double linked list modification done (tested on Mac OS X)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
468
diff
changeset
|
97 |
468
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
98 2009-10-02 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
99 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
100 DrawSpan で、~DrawSpan() で、allocate したデータを DMA_WAIT |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
101 して、free しているが、これは、抽象化違反。Task で明示的に |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
102 DMAするのは禁止。Task 内で、add_outData 出来れば良い。 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
103 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
104 renew が正しいような気がするが... |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
105 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
106 Task 内で大域変数は使えない。なので、smanager からallocateする |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
107 必要がある。Task の解放のタイミングではなくて、パイプラインの |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
108 タイミングでDMA waitとfreeを行なう必要がある。DrawSpan の場合は、 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
109 add_outData で良いが、内部で allocate/free は行なう必要がある。 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
110 put_segement がパイプライン動作するべきなのか? |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
111 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
112 固定のDMA tagが邪魔。 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
113 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
114 DrawSpan は全般的にダメだな〜 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
115 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
116 でも、その変更は大きいので、とりあえず動くようにしたい。 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
117 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
118 memset 0 は、7.7.3 SL1 Data Cache Range Set to Zero コマンド |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
119 つかうべき。SPE側でやっても良い。でも、本来は全面埋まるのが |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
120 普通なのでどうでも良いけど。 |
bd5b93d39597
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
121 |
386 | 122 2009-08-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
123 | |
390 | 124 で、MemList/MemHash が TaskManager 側に移ったので、 |
125 これで、code の management を書くことが出来る。 | |
126 そうすれば、SPEのメモリの限界をほんと気にする必要がなくなるはず。 | |
127 | |
128 その前に、get_segment の例題を直さないと。 | |
129 | |
130 DrawSpanRnew/reboot は使ってないらしい。 | |
131 | |
132 Tree は、配列にしないでlinkをSPE側からたどるようになっている。 | |
133 それは良いのだが、Task 側で dma_wait するような実装は望ましくない。 | |
134 この部分も書き直す必要がある。list 構造の SPE上の Iterator を | |
135 実装すれば良い。 | |
386 | 136 |
390 | 137 memory 関係のコードが scheduler の下にあるのは面白くない。 |
138 | |
139 Scheduler で実装(__scheduler)に移譲している部分は、headerに | |
140 移した方が良い。 | |
141 | |
142 2009-08-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> | |
143 | |
144 うーん、get_segemnt で、dma_wait のtagをなんとかする | |
145 必要があるらしい。get_tag() でなんとかなるけど、 | |
146 他のtag との関係があるかな。 | |
147 | |
148 完全に見えなくするべきでしょうけど... 今はいい。 | |
386 | 149 |
381 | 150 2009-08-01 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
151 | |
390 | 152 MemList は動いたので、今度は TileHash を TaskManager 側に移動する |
153 必要がある。 | |
381 | 154 |
390 | 155 その後、コードのLRUを書けば、Cerium は一通り出来上がり。 |
381 | 156 |
390 | 157 TaskManager と Scheduler の関係が一貫してない。複雑すぎる。 |
381 | 158 |
159 | |
363 | 160 2009-07-24 Kaito TAGANO <tkaito@cr.ie.u-ryukyu.ac.jp> |
390 | 161 |
363 | 162 長さ別の freeList と単一の HashTable で管理する |
163 TileList を廃止 | |
164 class MemorySegment { | |
165 MemorySegment *next; | |
166 MemorySegment *prev; | |
167 uint64 size; | |
168 uint64 address; | |
169 uint64 dummy; | |
170 // uint32 data[0]; | |
171 } | |
172 | |
173 class MemList { | |
174 MemorySegment* first; | |
175 MemorySegment* last; | |
176 | |
177 MemList* createMemList(uint32 size, uint32 count); | |
178 void addFirst(MemorySegment* e); | |
179 void addLast(MemorySegment* e); | |
180 MemorySegment* getFirst(); | |
181 MemorySegment* getLast(); | |
182 boolean remove(MemorySegment* e); | |
183 void moveToFirst(MemorySegment* e); // or use(); | |
184 } | |
185 | |
186 サイズ毎に freelist と activelist を持って、これを malloc free | |
187 として使う。 | |
188 これのテストルーチンを書き終わったら、Tapestry をこれで書き直す | |
189 LRU は使うたびに以下を呼び出す | |
190 | |
191 void use(MemorySegment* e, MemList* active) { | |
192 active.remove(e); | |
193 active.addFirst(e); | |
194 } | |
195 | |
196 | |
354 | 197 2009-07-15 Yusuke KOBAYASHI <koba@cr.ie.u-ryukyu.ac.jp> |
198 | |
199 PPU からMainMemory にResource を Access する API | |
200 長さ別の freeList と単一の HashTable で管理する | |
201 | |
386 | 202 読みだしAPI。set_rgb に相当。 |
203 uint32 segment_id = smanager->get_segment(memaddr addr, *MemList m) | |
354 | 204 id は hash値に相当。 |
386 | 205 addr で指定された PPU の Address が Hash にあるかどうか調べる。 |
206 無ければ dma_load する。そして指定された id を返す。 | |
207 | |
400 | 208 確保 API。set_rgb に相当。読み出さないで、hash entry だけ確保する。put しかしない部分用 |
209 uint32 segment_id = smanager->get_null_segment(memaddr addr, *MemList m) | |
210 id は hash値に相当。 | |
211 | |
386 | 212 書き出しAPI、読みだしていること前提。 |
354 | 213 smanager->put_segment(wait_id); |
386 | 214 |
215 MemorySegment* smanager->wait_segment(uint32 segment_id) | |
216 id で指定された PPU の segment の copy の Address を返す。 | |
217 必要があれば dma_wait を行う。書き出しも待ち合わせる。 | |
354 | 218 |
307 | 219 2009-06-8 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
220 | |
221 SchedTask/SchedTaskImpl の分離はあんまり意味がなかった。 | |
222 SchedTaskBase が既にあるし。 | |
223 とりあえず、__list とかは、private にしただけ。 | |
224 ScheTaskImple を作っても、継承してprivateにすると、 | |
225 warning は出るが、 User Task space の名前空間は結局汚れてしまう。 | |
226 | |
227 delegate するべきだと思うが、SchedTaskBase でないと、 | |
228 動かないらしい。それだと、indirect が増えるので、ちょっといや。 | |
229 | |
279 | 230 2009-06-4 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
231 | |
232 set_symbol は、もういらないよね? | |
233 | |
234 list dma 中心の実装にして、もっと細かく read/exec/write | |
235 した方が良いかも。 | |
236 | |
237 post で、PPE task を渡せると良い。address は parameterとして送る | |
238 | |
274 | 239 2009-02-13 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> |
240 | |
241 * kernel/ppe/Random.cc (reset): fix | |
242 urandom -> random とどれも読めなかったら | |
243 gettimeofday() での時間から seed を求めるように | |
244 | |
245 2009-02-12 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
246 | |
247 * add: kernel/ppe/Random.cc | |
248 乱数生成クラス。 | |
249 ゲームだとユーザ使うでしょうきっと。 | |
250 一応 /dev/random から seed 取る様にしてます | |
251 | |
252 2009-02-04 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
253 | |
254 * kernel/ppe/TaskManager.cc (TaskManager::allocate): rename | |
255 malloc -> allocate | |
256 | |
257 * kernel/main.cc (main): fix | |
258 cerium_main を呼ぶのではなく、TMmain という名前にしました。 | |
259 ちょっと SDLmain をパクった感じで。 | |
260 まあ TaskManager の main で cerium_* って名前は微妙に変だからね。 | |
261 | |
262 * kernel/ppe/TaskManager.cc (TaskManager::set_TMend): add | |
263 cerium_main があるんだから、cerium_end があってもいいじゃない。 | |
264 もっと言うと、TaskManager に main を隠すって流れなんだけど | |
265 終了を検知できないのはちとやりづらいかなと。 | |
266 たとえば測定とか。Task の post_func とかでもやれないことはないけどね。 | |
267 というわけで、ユーザが、プログラム終了時に呼ばれる関数を設定できるように。 | |
268 | |
269 2009-01-20 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
270 | |
271 * Cell/spe/SchedTask.cc (SchedTask::get_cpuid): add | |
272 printf デバッグ時に、どの CPU かって知りたい時があるので。 | |
273 | |
274 PPE = 0 | |
275 SPE = 0〜spu_num-1; | |
276 | |
277 PPE は 0 以外に分かりやすい数字がいいんだけどなー。SPE と被るし。 | |
278 -1 とかはエラーっぽいから好かない。まあいいんだけど。 | |
279 | |
280 User Task では以下の様に使用します | |
281 | |
282 int cpuid = smanager->get_cpuid(); | |
283 | |
284 | |
285 * Cell/SpeThreads.cc (SpeThreads::spe_thread_run): fix | |
286 SPE_EXIT が出る時は正常終了だけど、これだと | |
287 エラーでたようなメッセージに見えてしまう(俺がそう見えてしまった)ので | |
288 ここは表示しなくてもいいかな。 | |
289 | |
290 * kernel/ppe/MailManager.cc (MailManager::destroy): fix | |
291 無限ループになってた。この for() 間違ってるかな。 | |
292 なんか TaskQueueInfo.cc とかでも、結局 while() に直してるし。 | |
293 | |
294 * kernel/ppe/TaskManager.cc (TaskManager::~TaskManager): add | |
295 kernel/main.ccで | |
296 | |
297 delete manager; | |
298 | |
299 としているのに、TaskManagerImpl::~TaskManagerImpl が呼び出されず | |
300 どうしてかなと思ったら、そもそも ~TaskManager が無かった。あほか | |
301 | |
302 2009-01-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
303 | |
304 * all : fix | |
305 Scheduler::curIndex_taskList を削除し、 | |
306 SchedTask に持たせる様に変更。(SchedTask::__cur_index) | |
307 それに伴い、SchedTask::__init__() も cur_index を入れる様に変更 | |
308 | |
309 2008-12-24 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
310 | |
311 * kernel/schedule/SchedTask.cc (SchedTask::ex_init_renew) | |
312 (SchedTask::ex_init_normal): add | |
313 (SchedTask::__init__): fix | |
314 | |
315 init でも ex_init を使える様に。 | |
316 あと、コンストラクタで渡していた引数を __init__() に渡す様にした。 | |
317 コンストラクタの引数あると、継承する時にいちいち親クラスのも書かないと | |
318 いけなかった。これ省略できないんだよな。めんどくさい。 | |
319 | |
320 例. | |
321 class Hoge : public SchedTask { | |
322 Hoge(int i) : Task(i) {} | |
323 }; | |
324 | |
325 なので、今までは Scheduler.h に SchedConstructor ってマクロを書いて | |
326 クラス名入れるだけで上の様な形になるようにしていた。 | |
327 でも、例えば | |
328 | |
329 SchedTask -> Hoge -> Fuge っていうように Fuge ってタスクを | |
330 作りたいとき、上のままだと SchedTask に引数渡してしまうのでだめ。 | |
331 もうめんどくさいってことで、コンストラクタ全てデフォルトにして、 | |
332 __init__() の引数に渡す様にしました。 | |
333 | |
334 (SchedTask::__set_renewFlag): add | |
335 | |
336 ここで、PPEで生成されたか(normal)、SPE で生成されたか(renew) の | |
337 判定を行い、ex_xxx の設定もする | |
338 | |
339 (SchedTask::get_inputSize, SchedTask::get_outputSize): add | |
340 | |
341 アドレスだけじゃなく、そのサイズも取れた方がいいだろう | |
342 | |
343 | |
344 2008-12-23 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
345 | |
346 * Cell/spe/SchedTask.cc (SchedTask::get_outputAddr) | |
347 (SchedTask::get_inputAddr): add | |
348 | |
349 in/out のデータだけじゃなく、そのアドレスも取れた方がいいだろう | |
350 | |
351 2008-12-22 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
352 | |
353 * Cell/spe/SchedTask.cc (SchedTask::__init__, SchedTask::read) | |
354 (SchedTask::exec, SchedTask::write): fix | |
355 (SchedTask::ex_read_normal, SchedTask::ex_read_renew) | |
356 (SchedTask::ex_exec_normal, SchedTask::ex_exec_renew) | |
357 (SchedTask::ex_write_normal, SchedTask::ex_write_renew): add | |
358 | |
359 SPE 内で生成されたタスクは、PPE で生成されたものと違い | |
360 | |
361 - add->inData | |
362 : PPE から DMA or SPE 内のものをそのまま使う | |
363 - PPE にタスクが終了したことを知らせる | |
364 : 生成されたタスクを待つ必要があるなら、その時点では送らない | |
365 | |
366 とか、まあいろいろ処理が違うわけです。 | |
367 そして、タスク内生成タスクの判断をする | |
368 | |
369 __flag_renewTask ? 0 = PPE で生成 : 1 = SPE で生成 | |
370 | |
371 という変数がある。これでいくつか処理を分けてるんだけど、 | |
372 今までは | |
373 | |
374 if (__flag_renewTask) { | |
375 } else { | |
376 } | |
377 | |
378 ってやってた。これではいかんという事で、 | |
379 __init__() 内で、関数ポインタに、 | |
380 | |
381 ex_xxxx_normal: PPE で生成されたタスクに対する処理 | |
382 ex_xxxx_renew: SPE で生成されたタスクに対する処理 | |
383 | |
384 と入れて、if 文無しでやってみた。 | |
385 今は ex_write_xxx しか書いてないが、これからread/exec でも | |
386 出てくると思うので、作っておいた | |
387 | |
388 | |
389 2008-12-19 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
390 | |
391 * Cell/spe/CellDmaManager.cc (CellDmaManager::dma_wait) | |
392 (CellDmaManager::mail_write, CellDmaManager::mail_read): fix | |
393 writech、readch の関数を、wrap (って言い方でおk?)された関数に変更。 | |
394 最適化掛かってるっぽいし、長いよりはわかりやすいし。そのための wrap。 | |
395 | |
396 例: | |
397 - before | |
398 spu_readch(SPU_RdInMspu_readch(SPU_RdInMbox); | |
399 - after | |
400 spu_read_in_mbox(void); | |
401 | |
402 2008-11-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
403 | |
404 * add: Task 内での API | |
405 Task 外での API は、今まで通り manager->create_task とかですが | |
406 タスク内でも、「オブジェクト->関数」の呼び出しがいいんじゃないか | |
407 って話になったので、付け加えました。今のところ、SchedTask.h の | |
408 内部クラスとして | |
409 | |
410 STaskManager | |
411 | |
412 ってのを加えて、ユーザはそのインスタンスである | |
413 | |
414 smanager | |
415 | |
416 からAPIにアクセスします。 | |
417 今までは __scheduler->dma_load とかいろいろやってたんですが | |
418 これからは全て smanager にしました。 | |
419 というわけで、ここに使える API 一覧。いずれゲーム班 wikiの方にも。 | |
420 | |
421 - get_input, get_output, get_param | |
422 - create_task, wait_task | |
423 - global_alloc, global_get, global_free | |
424 - mainMem_alloc, mainMem_wait, mainMem_get | |
425 - dma_load, dma_store, dma_wait | |
426 - allocate | |
427 | |
428 使い方は追々描きますが、 | |
429 今のところ上に変更しなくてもそのままの記述で動くはずです。 | |
430 いずれは全て移行してもらうことになりますがきっと。 | |
431 | |
432 | |
433 * kernel/schedule/SchedTask.cc: | |
434 いろいろ関数が増えてますが、ラッパーです。 | |
435 | |
436 2008-11-01 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
437 | |
438 * add: kernel/main.cc | |
439 main loop をユーザに書かせるのはめんどくさいので、 | |
440 ライブラリ側で main() を書く事にしました。 | |
441 ユーザ側では main() の代わりに cerium_main() を | |
442 書かせるようにしています。引数は main() のをそのまま渡す感じで。 | |
443 | |
444 Cerium 標準のオプションとして、-cpu は付けました。 | |
445 ゲームフレームワークってことで、-width とか -height は | |
446 標準でつけてもいいかなって話なので、これは後日実装。 | |
447 標準オプションで受け取った値にアクセスする方法も考えないと。 | |
448 manager->cpu とか manager->width とかは安易か? | |
449 | |
450 * add: Cell/PpeScheduler.cc | |
451 MainScheduler をそのまま使うと、 | |
452 PPE のタスクで mainMem_alloc で確保した領域がアライメント | |
453 取れていないため、SPE で使うと余裕でバスエラー。 | |
454 | |
455 Scheduler->allocate で poxis_memalign で使えるように。 | |
456 | |
457 * move: kernel/schedule/FifoDmaManager.cc, MainScheduler.cc | |
458 kernel というよりは Fifo バージョン用なので Fifo/ に移動。 | |
459 | |
460 | |
461 2008-10-21 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
462 | |
463 * kernel/ppe/TaskManagerImpl.cc (TaskManagerImpl::systask_init): fix | |
464 下に述べてる SysTask_Finish を regist する部分 | |
465 | |
466 (TaskManagerImpl::spawn_task): | |
467 | |
468 SysTask_Finish に対して、タスクが spawn されるたびに | |
469 wait_for を掛けて、待つようにしている。 | |
470 | |
471 * add: kernel/systask/ | |
472 久々の更新乙 | |
473 | |
474 プログラム動かすとき、タスクが SPE だけで、 | |
475 PPE で待ってるタスクが無いとそのままプログラムが素通りするってことで | |
476 今まではユーザに、全てのタスクを待たせるタスクってのを書かせてた。 | |
477 まあもちろんめんどくさいので、いい加減追加した。 | |
478 | |
479 system task っつーことで、spawn された全てのタスクを待つ | |
480 SysTask_Finish を作った。これでいちいち task_finish とか作らなくておk | |
481 | |
482 2008-08-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
483 | |
484 * thinking: add_update() ? | |
485 現在、タスクは input/output があるわけですよ。 | |
486 で、例えば | |
487 | |
488 - 入力データ : PolygoPpack | |
489 - 出力データ : SpanPack | |
490 | |
491 ってなわけですが、別のタスクで | |
492 | |
493 - 入力データ : SceneGraphPack (更新前) | |
494 - 出力データ : SceneGraphPack (更新後) | |
495 | |
496 ってのがある。つまり Update なわけだ。 | |
497 今のところ、同じアドレスを add_inData, add_outData に設定して | |
498 タスク内で memcpy(wbuf, rbuf, sizeof(SceneGraphPack) とかしてる。 | |
499 まあそれはそれでいいのかわるいのか。 | |
500 | |
501 in/out だけじゃなくて update も必要? | |
502 | |
503 2008-08-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
504 | |
505 * add: ../include/TaskManager/base.h | |
506 通常の new/delete では、RTTI とか 例外処理とかで | |
507 -fno-exceptions や -fno-rtti をコンパイルオプションにしても | |
508 効かなかったんだけど、operator new/delete をオーバーライドして | |
509 中身を普通の malloc/free にすると、上の処理が無くなるので | |
510 オプションが効くようになる。結果コードサイズも減ると。 | |
511 SPE の場合、70〜80KBは減りました。使わない手は無い。 | |
512 つーことで、一応動いてる。。。といいたけど動いてないorz | |
513 最適化 (-O2 とか -O9) をかけると止まる。SPE 上でね。 | |
514 FIFO バージョンだと問題ない。SPEだとだめだ。 | |
515 今わかってる、止まる場所は Scheduler::run() 内の | |
516 | |
517 task3->write(); | |
518 | |
519 だ。task1~3までのnewは(多分)できているんだけど | |
520 そこを呼び出すと SPE 自体が終了してしまう。謎だ | |
521 | |
522 一応、俺作の new/delete は base.h に定義してあって、 | |
523 通常の API との切り替えは、base.h にある | |
524 BASE_NEW_DELETE を切り替えるだけでおk。 | |
525 全てのファイルではなく、現在は SPE で使いそうなところだけやってます。 | |
526 いずれは全部やったほうがいいかな〜 | |
527 | |
528 ライブラリ側の最適化はアウトだけど、ユーザ側では問題ないです。 | |
529 なので、今は | |
530 | |
531 ライブラリ側(libspemanager.a)は最適化無し(-O0) | |
532 ユーザ側(SchedTaskを継承したやつね)は最適化しても無問題 (-O9) | |
533 | |
534 でっす。ここらへん完璧なれば、だいぶ楽になる。 | |
535 つーかもう C++ やめ(ry | |
536 | |
537 | |
538 2008-08-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
539 | |
540 * change: mainMem_set -> mainMem_wait | |
541 allocate を待つんだから、なんとなく wait かな。 | |
542 あと、ユーザも使えるので、wait の方がわかりやすいと思ったり。 | |
543 | |
544 2008-08-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
545 | |
546 * add: mainMem_alloc, mainMem_set, mainMem_get | |
547 SPE から メインメモリの領域に対して allocate できないと | |
548 SceneGraphの生成やら、結構クリティカルな処理を | |
549 全部 PPE でやらないといけなくなるってことで実装しました。 | |
550 | |
551 流れとして | |
552 | |
553 1 タスク中に、mainMem(id,size) を実行する事で、 | |
554 メインメモリに対して allocate のコマンドを発行。 | |
555 | |
556 1.1 Scheduler から PPE に対して | |
557 - commmand (MY_SPE_COMMAND_MALLOC) | |
558 - id (PPEから戻ってくるコマンドに必要) | |
559 - size | |
560 を mailbox で送る | |
561 | |
562 1.2 確保した領域はそのタスク内では取得できない(NULL が来ます) | |
563 正確には、返事の mail をここでは read してないから | |
564 | |
565 2. PPE では、受信した mail が MY_SPE_COMMAND_MALLOC だったら | |
566 次に来る mail が id と size であるとして read を行い、 | |
567 size を元に allocate する。allocate が完了したら | |
568 - id | |
569 - allocate された領域のアドレス | |
570 を SPE に mail で送る | |
571 | |
572 3. SPE Scheduler では、SchedTaskList::read で、 | |
573 一つ前の TaskList 中で実行された mainMem_alloc の数だけ | |
574 PPE からのメールを待つ。mainMem_set() の処理です。 | |
575 | |
576 4. create_task されたタスク内で mainMem_get(id) とすると | |
577 allocate したメインメモリ領域のアドレスが得られる。 | |
578 | |
579 こんな感じ。結構ださい実装なので、もうちょいスマートにいきたいよね。 | |
580 例題は Game_project/student/master/gongo/MainMemMalloc にあります。 | |
581 README にもおんなじこと書いてます。 | |
582 | |
583 * memo: The number of available entries of Inbound/Outbound Mailbox | |
584 Outbound (SPE -> PPE) のmailboxデータキュー保持数は | |
585 | |
586 /* SPE プログラム中 */ | |
587 #include <spu_mfcio.h> | |
588 spu_stat_out_mbox(void); | |
589 | |
590 で調べる事が出来る。 | |
591 | |
592 --- 記述例 --- | |
593 printf("Available capacity of SPU Outbound Mailbox\n"); | |
594 printf(" %d\n", spu_stat_out_mbox()); | |
595 | |
596 --- 実行結果 -- | |
597 Available capacity of SPU Outbound Mailbox | |
598 1 | |
599 | |
600 Inbound (PPE -> SPE) の mailbox データキュー保持数は | |
601 | |
602 /* PPE プログラム中 */ | |
603 #include <libspe2.h> | |
604 spe_in_mbox_status(spe_context_ptr_t); | |
605 | |
606 で調べられます。 | |
607 | |
608 --- 記述例 --- | |
609 printf("the number of available entries = %d\n", | |
610 spe_in_mbox_status(spe_ctx)); | |
611 | |
612 --- 実行結果 --- | |
613 the number of available entries = 4 | |
614 | |
615 Outbound が少ないなー。 | |
616 In/Out 共に、キューが MAX の場合、減るまで wait 掛かるんだよな。 | |
617 それがどこまで影響あるかは実際にやらないと、ってことか。 | |
618 | |
619 * fix: ファイル名の変更 (*.cpp -> *.cc) | |
620 前々から先生に直せ言われてたので。 | |
621 | |
622 cvs のファイル名を変える方法は簡単に二つ(てかこれだけ?) | |
623 | |
624 1. cvs rm hoge.cpp; cvs add hoge.cc | |
625 2. リポジトリを直接変更 mv hoge.cpp,v hoge.cc,v | |
626 | |
627 めんどくさかったので 2 でやりました。 | |
628 Attic (削除されたファイルがあるリポジトリディレクトリ?)にも | |
629 同じ処理を行えば、tag で update かけてもちゃんと反映されました。 | |
630 | |
631 2008-07-22 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
632 | |
633 * tag: open-campus-2008 | |
634 次やる事は、Cell/spe 以下のコードサイズを減らすために | |
635 new/delete を消して malloc/free で統一する事。 | |
636 placement_new ってのを使えば、コンストラクタは呼べて | |
637 new ほどサイズ圧迫しないからこれにしようかな。 | |
638 逆の placement_delete ってのは自分で小細工しないと行けないらしい。 | |
639 まあ、これが旨く行けば 80KB ほど減るから。やるべきだろう。 | |
640 | |
641 * Cell/spe/Scheduler.cpp (Scheduler::dma_load): アホなミスその2 | |
642 自分で __scheduler->dma_store をやってもデータが送れない。 | |
643 そんな馬鹿な。つーことでいろいろ調べてもわからない。 | |
644 アドレスやサイズが違うのかと調べても違う。 | |
645 こうなったらっつーことでライブラリに printf 加えてみたら表示されない | |
646 あれ、おかしいな。たしかに Connector::dma_store に加えたはz・・ | |
647 | |
648 Scheduler::dma_store(void *buf, uint32 addr, uint32 size, uint32 mask) | |
649 { | |
650 <<< | |
651 connector->dma_load(buf, addr, size, mask); | |
652 ======== | |
653 connector->dma_store(buf, addr, size, mask); | |
654 >>> | |
655 } | |
656 | |
657 なぜ store から load を呼んでるのか不思議だった。 | |
658 Scheduler::dma_load をコピペして dma_store にした後、 | |
659 中の connector->dma_load を変えなかったってオチだな。 | |
660 下のミスと合わせて5,6時間費やしたよHAHAHA | |
661 | |
662 * Cell/spe/SchedTask.cpp (SchedTask::exec): アホなミスその1 | |
663 Test/test_render で、 | |
664 SpanPack のデータが時々壊れてる感じがする。 | |
665 送る前までは正常だから生成に問題は無いはず。 | |
666 つーことでいろいろ調べたがわからず。 | |
667 printf デバッグすると動く不思議 | |
668 なんだ、printf で遅くなったらできるってことは | |
669 DMA が完了する前に SchedTask::run にきてんのか? | |
670 いやいや、そんなばかな。だってちゃんと wait し・・・ | |
671 | |
672 <<< | |
673 ============ | |
674 __scheduler->dma_wait(DMA_READ); | |
675 >>> | |
676 | |
677 はいはい wait し忘れ wait し忘れ | |
678 | |
679 2008-07-16 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
680 | |
681 * memo: if 文消した成果2 & memcpy するかしないかか | |
682 Renew Task では、inListData,outListData は新たに allocate して | |
683 使っているので、SchedTask にそって実行する場合、 | |
684 | |
685 __scheduler->dma_load(__inListData, (uint32)__task->inData, | |
686 sizeof(ListData), DMA_READ_IN_LIST); | |
687 __scheduler->dma_load(__outListData, (uint32)__task->outData, | |
688 sizeof(ListData), DMA_READ_OUT_LIST); | |
689 | |
690 の代わりに | |
691 | |
692 memcpy(__inListData, __task->inData, sizeof(ListData)); | |
693 memcpy(__outListData, __task->outData, sizeof(ListData)); | |
694 free(__task->inData); | |
695 free(__task->outData); | |
696 | |
697 もしくは | |
698 | |
699 __inListData = __task->inData; | |
700 __outListData = __task->outData; | |
701 (__task->inData と __task->outData は Destructor で free する) | |
702 | |
703 とやっています。 | |
704 memcpy が重いのはわかるんですが、下の方法では | |
705 Destructor で if 文使って free() しているわけです(このタスクが Renew か否か)。 | |
706 ですので、どっちが早いか試してみた。 | |
707 | |
708 /** | |
709 * memcpy() して、すぐ free() する version | |
710 */ | |
711 void | |
712 test_cpy(int flag, int *src) | |
713 { | |
714 if (flag) { | |
715 memcpy(data, src, sizeof(int)*length); | |
716 free(src); | |
717 } | |
718 } | |
719 | |
720 /** | |
721 * 参照で扱って、最後に free() する version | |
722 */ | |
723 void | |
724 test_nocpy(int flag, int *src) | |
725 { | |
726 if (flag) { | |
727 data = src; | |
728 } | |
729 | |
730 // この部分を SchedTask::~SchedTask() と | |
731 // 思ってください | |
732 if (flag) { | |
733 free(data); | |
734 } | |
735 } | |
736 | |
737 | |
738 これらの関数を10000回ループしました。 | |
739 src の allocate は関数の外でやっており、その部分は実行時間に含まれてません | |
740 flag は 1 or 0 の繰り返しです。 | |
741 | |
742 - 実行結果 (1) | |
743 :no copy | |
744 SPE time by SPU Decrementer: 0.035500 | |
745 :copy | |
746 SPE time by SPU Decrementer: 0.057500 | |
747 | |
748 memcpy しないほうが速いらしいです。 | |
749 ためしに、flag を ずっと 1 にしてみました。 | |
750 | |
751 - 実行結果 (2) | |
752 :no copy | |
753 SPE time by SPU Decrementer: 0.055250 | |
754 :copy | |
755 SPE time by SPU Decrementer: 0.053389 | |
756 | |
757 今度は copy するほうが早いという不思議。 | |
758 でもまあ、ずっと 1 ってことはないと思いますし、 | |
759 むしろ flag == 1 になるほうが少ないと思うので、 | |
760 no_copy version でやったほうがいいかな。 | |
761 | |
762 おまけで、実行結果 (1) の環境で、test_nocpy を変えてみた | |
763 | |
764 void | |
765 test_nocpy(int flag, int *src) | |
766 { | |
767 if (flag) { | |
768 data = src; | |
769 } | |
770 | |
771 free((void*)(flag*(int)data)); | |
772 } | |
773 | |
774 キャストしまくりですが、単純に free(flag*data) だと | |
775 「invalid operands of types 'int' and 'int*' to binary 'operator*'」って | |
776 出るので、キャストで逃げました。 | |
777 で、実行結果なんですが | |
778 | |
779 - 実行結果 (3) | |
780 :no copy | |
781 SPE time by SPU Decrementer: 0.040375 | |
782 :copy | |
783 SPE time by SPU Decrementer: 0.059500 | |
784 | |
785 遅くなってーら。キャストが悪いのか。乗算が重いのか。 | |
786 branch が無い? spe の if 文と対決しても遅いのかー。 | |
787 例題が間違ってる可能性もあるが・・・ if 文は使っていくかなー | |
788 | |
789 | |
790 2008-07-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
791 | |
792 * fix: TaskGroup->group | |
793 今まで slist っていう、ライブラリの単方向リスト構造体?を | |
794 使ってたんだけど、まあいろいろあって、TaskQueue を使うようにしました。 | |
795 最初からこれにするつもりではあったけどね。 | |
796 RenewTask や static_alloc とかの実装を優先したので | |
797 ライブラリを使いました。といっても、書いてみると | |
798 それほと記述量無いので最初から行っても良かったかなーと思ったり。 | |
799 | |
800 そんなわけで動いてます。つーか、やめてよかったよ slist。 | |
801 slist を使ったやつと使ってない奴のファイルサイズがやばい | |
802 | |
803 -rwxr-xr-x 1 gongo gongo 120672 2008-07-10 14:29 spe-main* | |
804 -rwxr-xr-x 1 gongo gongo 180368 2008-07-10 13:40 spe-main.bak* | |
805 | |
806 .bak が slist を使ってる、上のやつが使ってないversionです。 | |
807 まさか 60k も違ってくるとは思わなかった。 | |
808 SPE LS の容量が 256k と考えると、かなりの痛手だったよ。アブねえ。 | |
809 インラインとか最適化掛けまくってて、コード量が増えてるからかなー。 | |
810 | |
811 「SPU C/C++ 言語拡張」とかで、C++ のライブラリがSPUでも使えるよ〜 | |
812 って書いてたから入れてみたんだけど。罠だったか。 | |
813 おそらく SPU に移植した側の人も「サイズが増えるのを覚悟で使え」って | |
814 ことだったんだろう。なかったら文句言う人も居そうだし。 | |
815 | |
816 2008-07-09 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
817 | |
818 * fix: TaskGroup での task の扱い | |
819 下にもかいているけど (直したいところ (1)) | |
820 TaskGroup->group が持つ要素は int で持ってて、 | |
821 それらは、同じく TaskGroup が持つ cur_id をインクリメントしていって、 | |
822 それを要素としていました。つまり、TaskGroup->group は、厳密にいえば | |
823 「どの Task があるか」ではなく、「いくつのタスクがあるか」を | |
824 あらわしているだけでした。slist を使う意味もなかったわけです。 | |
825 | |
826 そこで、SchedTask が持つ、RenewTaskList の解放のタイミングを | |
827 RenewTaskList の一番最後のタスクが delete されるときにしました。 | |
828 これによって、アドレスが被ることがなくなったので | |
829 TaskGroup->group の要素を TaskPtr にできました。 | |
830 この方が、TaskGroup の意味的にもしっくりくるのでよかばってん。 | |
831 | |
832 * memo: if 文消した成果 | |
833 | |
834 #ifdef FREE_TEST | |
835 free((ListDataPtr)(__flag_renewTask*(int)(__inListData))); | |
836 free((ListDataPtr)(__flag_renewTask*(int)(__outListData))); | |
837 free((TaskListPtr)(__flag_renewTask*(int)(__list))); | |
838 #else | |
839 if (__flag_renewTask) { | |
840 free(__inListData); | |
841 free(__outListData); | |
842 free(__list); | |
843 } | |
844 #endif | |
845 | |
846 こんな感じで、いくつかか if 文を消してみた。 | |
847 そして、PPE側の main.cc で gettimeofday で計測してみた (各10回) | |
848 | |
849 | |
850 - if 文消した場合 | |
851 time: 1.222000 | |
852 time: 1.230000 | |
853 time: 1.241000 | |
854 time: 1.230000 | |
855 time: 1.223000 | |
856 time: 1.257000 | |
857 time: 1.219000 | |
858 time: 1.228000 | |
859 time: 1.220000 | |
860 time: 1.229000 | |
861 avarage: 1.2299 | |
862 | |
863 - if 文消してない場合 | |
864 time: 1.225000 | |
865 time: 1.215000 | |
866 time: 1.229000 | |
867 time: 1.218000 | |
868 time: 1.223000 | |
869 time: 1.214000 | |
870 time: 1.225000 | |
871 time: 1.215000 | |
872 time: 1.224000 | |
873 time: 1.219000 | |
874 avarage: 1.2207 | |
875 | |
876 あまり変わらな(ryむしr(ry | |
877 使い方がまずいのか、もっとと回数を増やせば変わってくるのかね。。。 | |
878 PPE でなく、 SPE のほうで計測すべきなのかなーとか思ったり思わなかったり。 | |
879 | |
880 | |
881 2008-07-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
882 | |
883 * add: Renew Task の wait | |
884 Renew Task は今まで「生成されたやつ全部待つ」だったのを | |
885 | |
886 void SchedTask::wait_task(TaskPtr task); | |
887 | |
888 ってのを作って、任意のタスクに wait 掛けれるようにしました。 | |
889 名前が思いつかなかったお。。。 | |
890 動作確認済み・・・だと思います。例題・・・誰か例題を!(俺が | |
891 | |
892 | |
893 * fix: SchedTask の変数名 | |
894 ユーザが継承して使う SchedTask クラスなんですが、 | |
895 今まで変数は list, task などを使ってました。 | |
896 が、これは一般に使われやすい変数名です。 | |
897 その証拠に、俺も例題書いている時に task って名前が被ってました。 | |
898 | |
899 run(r, w) | |
900 { | |
901 ... | |
902 | |
903 //TaskPtr task; <= 宣言してないのにエラーにならない | |
904 task = create_task(TASK_EXEC); | |
905 } | |
906 | |
907 ってコードを書いてたせいで、Scheduler が使用する task を | |
908 上書きしたせいでバグってました。ってことがありました。 | |
909 上のように、宣言してないのに普通に通ってるのを気づきませんでした。 | |
910 今のところ変数名は __task とか __list にしてあります。 | |
911 private にしてもいいんだけどさ。 | |
912 | |
913 | |
914 2008-07-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
915 | |
916 * fix: if 文を無くしてみた | |
917 下の方に 「if () が多い」って書きましたが、いろいろ小細工を。 | |
918 SchedTask をやってみました。例えば | |
919 | |
920 if (cmd != 0) { | |
921 delete taskGroup; | |
922 scheduler->mail_write(cmd); | |
923 } | |
924 | |
925 ってのがありました。cmd ってのは taskGroup->status で | |
926 もし cmd が 0 でなければ、taskGroup はすでに空っぽで | |
927 待つべきタスクはすべて終了したので、taskGroup を delete し、 | |
928 mailbox で cmd を PPE に送ります(cmd にはすでに送るべきコマンドがある) | |
929 でまあ、これくらいなら | |
930 | |
931 delete (int*)((cmd != 0)*(int)(taskGroup)); | |
932 scheduler->mail_write(cmd); | |
933 | |
934 ぐらいに直せました。 | |
935 delete や free では NULL を渡しても何もしない(?)って動作なので | |
936 これでも問題ない。つまり、cmd == 0 なら、taskGroup を | |
937 解放する必要は無いので NULL が delete に渡されるわけです | |
938 int* でキャストしてるのは、そのまま 0 を渡すと、 | |
939 「int型を delete するのはできない」的なエラーがでるからです。 | |
940 。。。だったら int* じゃなくて TaskGroupPtr じゃね?とか思った今。 | |
941 | |
942 あと、PPE 側で 「mail == 0 なら NOP」 的な処理を入れました。 | |
943 これによって、cmd が 0 かその他で if を書く必要がなくなりました。 | |
944 問題があるとすれば、 SPE -> PPE の mailbox の queue の長さ。 | |
945 NOP コマンドを送って、queue の制限に引っかかって | |
946 mail_write が止まるんじゃないかなーとか少し心配です。 | |
947 ここらへんは optimize の時間に考える事かな。 | |
948 どうせ PPE では mail しか読んでないし、 | |
949 そこまで queue が埋まる事は無いと思いたい。 | |
950 | |
951 | |
952 | |
953 あとはこんな感じかな | |
954 | |
955 #if 1 // fix | |
956 free((void*)(flag_renewTask*(int)(list))); | |
957 #else | |
958 if (flag_renewTask) { | |
959 free(list); | |
960 } | |
961 #endif | |
962 | |
963 動いてるのは確認したし、gdb で x/20i とかしたら | |
964 branch 命令が減ってるのは確認した。 | |
965 まあ -O9 とかで最適化掛けるとどっちも同じになるけどな。 | |
966 | |
967 | |
968 * add (API): static_alloc, static_get, static_free | |
969 SchedTask 自身だけが持つ領域ではなく、 | |
970 SPE 上に複数のタスクが共有したい領域を作る | |
971 これは task::run() 内で使用する。 | |
972 | |
973 - void* static_alloc(int id, int size); | |
974 @param [id] 領域ID。現在は 0〜31 まで使用可能 (Scheduler.h で定義) | |
975 @param [size] 領域のサイズ | |
976 @return allocate した領域のポインタ。下の static_get の返り値と同じ | |
977 | |
978 - void* static_get(int id); | |
979 @param [id] static_alloc で作った領域 ID。 | |
980 @return 領域のポインタ | |
981 | |
982 - void static_free(int id); | |
983 @param [id] 解放したい領域の ID | |
984 | |
985 こんな感じかなー。 | |
986 static_free はさすがにユーザに任せるだろう。 | |
987 static_free し忘れると SPE には致命的なので、ここはよく伝える必要有 | |
988 | |
989 例題は | |
990 cvs: firefly:Game_project/student/master/gongo/Static | |
991 | |
992 まあ Renew と大体同じですけどね。 | |
993 int 型配列 data を共有にして、各タスクでインクリメントしてる | |
994 | |
995 * TODO: TaskGroup の扱い | |
996 通常の Task では、task->self には | |
997 自分が終了した時に PPE に送るコマンド(自分自身)になりますが、 | |
998 タスク中に生成されたタスク(もう何度も書くのめんどいんで Renew で)では | |
999 task->self は、task を待っている TaskGroup を表します。 | |
1000 | |
1001 self という名前で意味が違うのでこういうことはやめたいんだが。。。 | |
1002 といいながらやめないのが(ry | |
1003 | |
1004 * memo: | |
1005 下の 直したいところ (1) ってやつがよくわからんので、 | |
1006 現在の状況だけ | |
1007 | |
1008 scheduler->add_groupTask() をするたびに | |
1009 | |
1010 group.insert_front(cur_id++); | |
1011 | |
1012 されます。 | |
1013 そして、scheduler->remove_groupTask() されると | |
1014 | |
1015 group.remove(--cur_id); | |
1016 | |
1017 されます。要するに、どのタスクでも | |
1018 cur_id だけが insert/remove されます。 | |
1019 「どのタスクがあるか」ではなく「どれだけのタスクがあるか」ですね。 | |
1020 実際にはしっかりと TaskPtr で管理したかったんですが、 | |
1021 下にも書いたアドレスが被る云々の問題でそれもできず。 | |
1022 やり方はあると思うんですが。 | |
1023 | |
1024 うーん、うまく説明できないな。 | |
1025 | |
1026 * tag: v20080707 | |
1027 タスク内タスク生成を作りました。 | |
1028 | |
1029 [TODO] | |
1030 SPE 上で領域を共有する API の | |
1031 | |
1032 - static_alloc | |
1033 - static_get | |
1034 - static_free | |
1035 | |
1036 を速攻で実装しよう。。 | |
1037 | |
1038 * add: タスク内タスク生成 | |
1039 一応できたんですが、直したい。。。 | |
1040 仕様としては | |
1041 | |
1042 - 現在のタスク(T1) の中でタスクを生成したとする (Tc = T2, T3, ...) | |
1043 - 本来、T1 が終了次第、T1 が終わった事を PPE に伝えるが、 | |
1044 ここでは、Tc が全て終わってから、T1 の終了を PPE に伝える | |
1045 - Tc 内で再びタスクが生成されても(Tcc)、Tcc が終わってから T1 を(ry | |
1046 | |
1047 現在は、生成したタスクすべてに対して wait_for をかけてる感じ。 | |
1048 しかし、例えば Frame Buffer に書き込む時は待つ必要ない(はず)なので | |
1049 タスク毎に wait_for を選べるようにした方がいいだろう。 | |
1050 | |
1051 __ 例題 | |
1052 cvs firefly:Game_project/student/master/gongo/Renew | |
1053 | |
1054 にあります。 | |
1055 もうちょいちゃんとした例題が欲しいところです。 | |
1056 | |
1057 | |
1058 __ 直したいところ (1) | |
1059 | |
1060 現在、Tc を管理する構造体として、TaskGroup を使ってます | |
1061 | |
1062 class TaskGroup { | |
1063 unsigned int command; // T1 が PPE に送るコマンド | |
1064 __gnu_cxx::slist<int> group; // Tc がある Linked List | |
1065 | |
1066 // function は省略 | |
1067 }; | |
1068 | |
1069 slist じゃなくて、TaskQueue みたいに自分で作っても良かったんだけど。 | |
1070 group.empty() == true になったら、command を PPE に送るって感じです。 | |
1071 | |
1072 で、slist が持つデータが TaskPtr じゃなくて int の理由。 | |
1073 まあいろいろあるんだけど(何)、アドレスが重複してしまうことです。 | |
1074 最初は、create_task で得られた TaskPtr をキーとして使うつもりだったけど | |
1075 その TaskPtr は TaskList から取った物で (&list->takss[index] みたいな) | |
1076 なんでそれじゃだめなのか。buff_taskList[2] (Scheduler.cpp 参照) を | |
1077 使うと、交互に使用するのでアドレスは被る。 | |
1078 新たに allocate すれば問題は無いが (t1とする)、SPE の LS の問題で | |
1079 使わなくなった TaskList は free していかないといけない。 | |
1080 で、free -> 再び allocate したとき (t2とする)、t1 と t2 の | |
1081 アドレスが被ることがあった。当然 TaskPtr も被ると。 | |
1082 だから、アドレスではなく、TaskGorup が持つ | |
1083 unsigned int cur_id を使う事にしました。 | |
1084 | |
1085 なんかここまで自分で書いてて、 | |
1086 なんで出来ないのかまだわからんくなってきた。 | |
1087 | |
1088 ので試しに戻してみたら * で * き * ま * し * た * | |
1089 わけわからん。まあ勘違いだったのか、いろいろ別のところを直してるうちに | |
1090 知らず知らずミスってたところも治ってたのか。まあいいか。 | |
1091 | |
1092 と思っていろいろ試したらまた動かなくなった。。もうだめぽ | |
1093 とりあえず、また unsigned int に戻しました。 | |
1094 今のところ、0 <= cur_id <= 0xffff (65535) の範囲のキーを使うように。 | |
1095 | |
1096 | |
1097 __ 直したいところ (2) | |
1098 if 文が多い。 | |
1099 今は、「通常の Task」「タスク内で生成されたタスク」で挙動が違います。 | |
1100 例えば | |
1101 | |
1102 - SPE で allocate されたデータを使うので、通常 DMA を使うところは | |
1103 アドレス参照や memcpy を使う | |
1104 - TaskGroup を、上記の Tc や Tcc へ引き継がせるところ | |
1105 | |
1106 なので、flag_renewTask とかいう変数で、ほぼ if 文 で書いてます。 | |
1107 SPE でこの書き方はかなりまずい気がします。良い書き方はないものか。。。 | |
1108 「通常の(ry」「タスク内(ry」で新たにインスタンスを作るってのも | |
1109 考えはしましたが (SchedTask = 通常、SchedRenewTask = タスク内(ry とか) | |
1110 これだと ユーザー側も この二つを選んでやることになります。 | |
1111 「このタスクは SchedRenewTask 、このタスクは通常」とかやるのは | |
1112 かなりめんどくさいと思う。だからライブラリ側で分けるべきか。。。 | |
1113 多重継承とかってこんなとき役に立つん? | |
1114 | |
1115 | |
1116 2008-07-03 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1117 | |
1118 * TODO: | |
1119 - add_param で渡せるパラメータの数を増やす。15もあればいいんじゃね? | |
1120 - 今の実装では、 | |
1121 | |
1122 1. PPE でタスク(T1)が生成される | |
1123 2. SPE で T1 が実行される | |
1124 3. T1 が終わった事を PPE に mailbox で送る | |
1125 送る情報は T1 自身。(PPE で生成された時のアドレス) | |
1126 | |
1127 なわけです。しかし、もし T1 から新たにタスクが生成された時はどうするか | |
1128 仮に T1 から T2, T3, T4 が作られたとする。 | |
1129 このとき、 | |
1130 | |
1131 1. T1 が終わった時点で、T1 から終了コマンドを送る | |
1132 2. T1 だけでなく、T1 内で作られた T2, T3, T4 が終わってから | |
1133 終了コマンドを送る | |
1134 | |
1135 の二つが考えられる。 | |
1136 PPE 側では T1 しか認識していないため、この判定は SPE 内でやることになる | |
1137 必要な処理かと言われると微妙だが、欲しくなるのは間違いない。 | |
1138 つーことで今これを実装中です。 | |
1139 | |
1140 | |
1141 * tag: v20080703 | |
1142 - タスクに 32 bits パラメータを渡す add_param を実装(現在は3個まで) | |
1143 - SPE 内部でタスク生成ができるようになった | |
1144 | |
1145 * add (API): SPE内部での create_task | |
1146 今まで、SPE ではタスクを生成する事は出来ず、 | |
1147 PPE から送られてくるタスクを実行するだけでした。 | |
1148 それだと不便だってことで SPE 内部でもできるようにしました。 | |
1149 方法はPPEでやるのと同じく | |
1150 | |
1151 task = create_task(TASK_EXEC); | |
1152 task->add_inData(buff, sizeof(Buff)); | |
1153 task->add_param(data); | |
1154 | |
1155 みたいな感じでいいです。 | |
1156 spawn() や wait_for() は実装していません。 | |
1157 SPE 内部で生成するタスク同士で依存関係作るのが | |
1158 結構めんどくさいからです。spawn() も、しなくても勝手に実行します。 | |
1159 PPE とそろえる意味で作ってもいいんだけどね。 | |
1160 そのためには SPE にも TaskManager が必要になってくるなー。 | |
1161 | |
1162 | |
1163 2008-06-24 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1164 | |
1165 * add (API): add_param, get_param | |
1166 DMA で送れないけど、必要になってくる 4 バイトの情報があるとして | |
1167 それは今までは | |
1168 | |
1169 add_inData(param, 0); | |
1170 | |
1171 とかして、「サイズ == 0 なら 32 bit のデータ」としていたけど | |
1172 それは余りにも変なので(関数の意味的にもおかしい)ので、 | |
1173 | |
1174 add_param(parameter); | |
1175 | |
1176 ってのを追加しました。タスク側では | |
1177 | |
1178 get_param(index); | |
1179 | |
1180 とかします。index は、add_param を呼び出した順番で決まります | |
1181 | |
1182 add_param(x); | |
1183 add_param(y); | |
1184 add_param(z); | |
1185 | |
1186 とあるとき、タスク側では | |
1187 | |
1188 int x = get_param(0); | |
1189 int z = get_param(2); | |
1190 | |
1191 とします。 | |
1192 今のところ parameter は 3つしか送れないことになってますが | |
1193 後ほど、上限をあげます。15くらいあれば余裕だと思うんだがどうだい? | |
1194 今は、SPE でのタスクの生成のルーチンを書くために、最低限な部分だけ | |
1195 ってことで 3 つにしてます。それが出来次第、これもやります。 | |
1196 | |
1197 | |
1198 2008-06-12 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1199 | |
1200 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_runTaskList): | |
1201 アホなミス(ry | |
1202 | |
1203 「list が持つ TASK_MAX_SIZE を超えると、次の list へ next を」っていう | |
1204 前回直したところがまたミスっててだな。 | |
1205 簡単に言うと | |
1206 | |
1207 TaskPtr task = &list[list->length++]; | |
1208 [task の初期化] | |
1209 | |
1210 if (list->length > TASK_MAX_SIZE) { | |
1211 [newList 生成] | |
1212 newList = append(newList, topList[speid]); | |
1213 topList[speid] = newList; | |
1214 } | |
1215 | |
1216 ってやってたわけ。これだと、toplist[speid] に | |
1217 length = 0 の list が来る可能性があると。 | |
1218 で、spe に TaskList を送る条件は | |
1219 | |
1220 1. taskList[speid]->length >= 1 | |
1221 2. speid が次の TaskList を待っている状態 | |
1222 | |
1223 で、1 の条件に触れてしまい、TaskList が送られなくなって | |
1224 プログラムが終了しないと。アホですね〜 | |
1225 上の if 文を &list[list->length++]; の前に持って行くだけでおk。 | |
1226 | |
1227 2008-06-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1228 | |
1229 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_runTaskList): | |
1230 アホなミスしてました。 | |
1231 list が持つ TASK_MAX_SIZE を超えると、次の list へ | |
1232 next を繋げるはずなんだけど、speTaskList_bg[speid] とか読む時に | |
1233 ちゃんと繋げられてなかったというかなんというか。 | |
1234 簡単に言うと、タスク多くなると落ち(ry | |
1235 | |
1236 * add (API): set_post | |
1237 | |
1238 create_task(id, 0); | |
1239 | |
1240 とかわざわざ 0 付けるのもアレなので、もうそれように | |
1241 | |
1242 task->set_post(func) | |
1243 | |
1244 を追加しました。func は void (*func)(void) です。 | |
1245 せっかくだから、引数に void* とか付けてもいいんじゃないかと。 | |
1246 | |
1247 | |
1248 * fix (API): ListDMA API | |
1249 タスク側で、ListDMA で指定したデータの取り方 | |
1250 | |
1251 run(rbuf, wbuf) として | |
1252 | |
1253 // index は add_inData や add_outData で指定した(順番-1) | |
1254 get_input(rbuf, index); | |
1255 get_input(wbuf, index); | |
1256 | |
1257 返り値は void* なので、malloc っぽくキャストしてください。 | |
1258 あと、4バイト以下のデータを送りたい場合、main で | |
1259 | |
1260 add_inData(data, 0) | |
1261 | |
1262 と、アドレスは送りたいデータを則値で、サイズは 0 で指定するとおk。 | |
1263 get_input で int なりなんなりでキャストすればいいじゃない! | |
1264 例題は | |
1265 | |
1266 Game_project/student/master/gongo/arr_cal | |
1267 | |
1268 で複数データ扱ってたり4バイト送ってたりしてます。 | |
1269 | |
1270 | |
1271 * tag: v20080610 | |
1272 前回との違いは | |
1273 | |
1274 - ListDMA の導入 | |
1275 - 凡ミスfix | |
1276 | |
1277 とかかな。何気にここには ListDMA の API 書いてなかったな。 | |
1278 | |
1279 - task->add_inData(addr, size); // input | |
1280 - task->add_outData(addr, size); // output | |
1281 | |
1282 これで Input/Output のデータ領域を指定可能。複数できます。 | |
1283 詳しくはいずれドキュメントに書く予定だが、 | |
1284 | |
1285 - addr は 16 バイトアライメントに取れてないと行けない | |
1286 - size は 16 バイト倍数 | |
1287 | |
1288 ってのが最低条件。 | |
1289 16 バイト未満のデータを送りたいとき(整数を2,3個とか)は考え中。 | |
1290 addr に直接渡すって手法はできるとわかってるので、それでもいいかな。 | |
1291 まあいろいろ問題はありますが、少しはできたんじゃないかな。 | |
1292 | |
1293 次からは SPE 内でのタスク生成(再起動?)を書く予定 | |
1294 | |
1295 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_runTaskList): | |
1296 if (speid > machineNum) { | |
1297 speid %= MAX_USE_SPE_NUM; | |
1298 } | |
1299 | |
1300 から | |
1301 | |
1302 if (speid >= machineNum) { | |
1303 speid %= machineNum; | |
1304 } | |
1305 | |
1306 に。なんという凡ミス | |
1307 | |
1308 * Cell/spe/CellDmaManager.cpp (CellDmaManager::dma_loadList): fix | |
1309 ListData が持つ ListElement は | |
1310 | |
1311 class ListElement { | |
1312 public: | |
1313 int size; | |
1314 unsigned int addr; | |
1315 }; | |
1316 | |
1317 というデータ構造なわけだが、これは、spu_mfcio.h が持っていて | |
1318 且つ List DMA で使用される | |
1319 | |
1320 typedef struct mfc_list_element { | |
1321 uint64_t notify : 1; /** Stall-and-notify bit */ | |
1322 uint64_t reserved : 16; | |
1323 uint64_t size : 15; /** Transfer size */ | |
1324 uint64_t eal : 32; /** Lower word of effective address */ | |
1325 } mfc_list_element_t; | |
1326 | |
1327 と同じである。notify と reserved は 0 となる (ストールは今は | |
1328 考えていない)ので、結局は uint が 2 つの 8 バイト のデータ構造であれば | |
1329 そのまま mfc_getl とか mfc_putl に遅れるわけである。 | |
1330 今までは mfc_list_element_t 構造体に for 文でいちいち代入してたが | |
1331 まあそれはなくなったっつーことで。dma_storeList もね。 | |
1332 | |
1333 | |
1334 2008-05-30 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1335 | |
1336 * change (API): TaskManager Memory Allocate | |
1337 manager->cerium_malloc(&buff, DEFAULT_ALIGNMENT, sizeof(Data)) | |
1338 | |
1339 から | |
1340 | |
1341 buff = (Data*)manager->malloc(sizeof(Data)); | |
1342 | |
1343 に変更しました。 | |
1344 alignment の指定は全て TaskManager に埋め込んであります。 | |
1345 記述は TaskManager.h に書いてあります。 | |
1346 | |
1347 void* TaskManager::malloc(int size) { | |
1348 return m_impl->allocate(DEFAULT_ALIGNMENT, size); | |
1349 } | |
1350 | |
1351 2008-05-29 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1352 | |
1353 * thinking: List DMA (4) | |
1354 Cell 版でも動いたのを確認。今、Cell 版で List DMA が動く条件は | |
1355 | |
1356 1. List の各要素の転送サイズが 16 バイト倍数でなければならない | |
1357 2. List の各要素の転送するデータのアドレスのアライメントを保証(16or128 | |
1358 | |
1359 2に関しては Cell の仕様なんでまあいいんだけど、 | |
1360 1は、ドキュメント見る分には | |
1361 | |
1362 - Cell Broadband Engine アーキテクチャ version 1.01 より | |
1363 - 7.5.3 get list | |
1364 > リスト・サイズ・パラメータは、このDMAコマンドの場合は | |
1365 > 8バイトの倍数でなければならず、また、リスト・アドレス・パラメータは、 | |
1366 > ローカルストレージの8バイト境界にアラインされなければなりません。 | |
1367 | |
1368 って書いてるんだよな。int が 10 個の配列(40バイト) を送っても | |
1369 見事に弾かれたんだよな。おのれバスエラーめ! | |
1370 とりあえず、上の条件を満たせば行けました。 | |
1371 送るデータのアロケートは | |
1372 | |
1373 TaskManager::cerium_allocate(void **buff, int align, int size); | |
1374 | |
1375 ってのを作りました。使い方は別項目で。だいたい posix_memalign 準拠。 | |
1376 | |
1377 動くのはいいんだけど、これだとユーザに全部任せる事になります。 | |
1378 特に、配列をアロケートした後、その途中の部分をリストに入れたい時。 | |
1379 その配列の要素のサイズが16倍数じゃないとそこでエラーがでると。 | |
1380 それをユーザに全部任せるのは、まあいけないこともないけどさ。。。 | |
1381 | |
1382 | |
1383 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::mail_check): fix | |
1384 CellTaskManager は FifoTaskManager のオブジェクトを | |
1385 ppeManager という変数で持っていて、作業を別々に行っているわけで。 | |
1386 だけど両方のオブジェクトがもつ waitTaskQueue は同じじゃないと | |
1387 ならないので、最初は TaskQueuePtr * とかで渡して | |
1388 共有してたわけだけど、よくよく考えると、 | |
1389 | |
1390 - waitTaskQueue に task が append される時 | |
1391 CellTaskManager->append_waitTask() | |
1392 | |
1393 - waitTaskQueue から task が remove されるとき(依存満たした時とか) | |
1394 FifoTaskManagerImpl->mail_check() 及び | |
1395 CellTaskManagerImpl->mail_check() です。 | |
1396 | |
1397 つまり、waitTaskQueue が共有されるのは mail_check だけなので、 | |
1398 CellTaskManagerImpl の mail_check で | |
1399 | |
1400 ppeManager->mail_check(mail_list, &waitTaskQueue) | |
1401 | |
1402 として、ここで waitTaskQueue を参照渡ししてます。 | |
1403 ppeManager->mail_check で waitTaskQueue の整理が終わって | |
1404 戻ってくる事には waitTaskQueue が更新されていると。 | |
1405 | |
1406 なんか文章がおかしいですね。気になる人は俺に直でお願いします。 | |
1407 要するに、ppe と spe のそれぞれの TaskManagerImpl で | |
1408 waitTaskQueue の共有が上手くいったというわけです。 | |
1409 | |
1410 | |
1411 2008-05-24 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1412 | |
1413 * thinking: List DMA (3) | |
1414 現在実装中。Fifo 版では動いている模様。 | |
1415 問題は Cell だよなー。考えないと行けない事がいくつか | |
1416 | |
1417 - Input/Output データはアライメントされている? | |
1418 アライメントされていなくても、こっちでアドレスずらして | |
1419 DMAしてずらして run() に渡して〜とかもできるんだけど | |
1420 かなりめんどくさい。それに、In ならともかく、 | |
1421 Out は変な領域に書き込みそうなので無理そう。 | |
1422 これはもうユーザが、送るデータはすべて | |
1423 Cerium_malloc 的なものを通したものだけ、っていう | |
1424 制約にした方がいいかもしれない。てかそうなんだっけ。 | |
1425 | |
1426 - 配列中のデータの指定 | |
1427 上の項目と少し関連があるんだが、例えば | |
1428 | |
1429 int data[100]; // アライメントは取れてるとする | |
1430 | |
1431 ってのがあって、そのなかの data[0]〜data[49]、 | |
1432 data[50] 〜 最後まで送りたいとする。 | |
1433 最初のやつは &data[0] のアドレスは 16 bytes アライメントだけど、 | |
1434 &data[50] では、sizeof(int)*50 = おそらく 200 ずれて | |
1435 16 bytes アライメントではなくなると。これだと DMA できない。 | |
1436 ユーザがそこまで考えて、例えば data[32] から送る、とかでもいいけど。 | |
1437 ライブラリ側で、少しは融通効くようにすべきかな。 | |
1438 やるなら、アドレスずらして取って来て、ユーザが見るデータは | |
1439 そのずらした分戻してから見せるって感じ。変な説明だが。 | |
1440 | |
1441 うーん。今はとりあえず全てアライメント大丈夫な方向でやってみるか。 | |
1442 | |
1443 | |
1444 2008-05-23 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1445 | |
1446 * Cell/SpeThreads.cpp (SpeThreads::init): スレッドの生成 | |
1447 今まで作られてたスレッドは | |
1448 | |
1449 - spe_context_run を実行するだけのスレッド (spe_thread_run) | |
1450 - 上のスレッドを呼び出し、終了を待つスレッド (frontend_thread_run) | |
1451 | |
1452 2番目に何の意味があるのかということだが、 | |
1453 SPE 毎にスレッドを立ち上げておいて、 | |
1454 それぞれのSPEからのメールは、その担当するスレッドが見る、 | |
1455 って構想で作っていました。だけど、今は mailbox の扱いは | |
1456 Cell/CellTaskManagerImpl::mail_check で行っているため | |
1457 わざわざ2番目のスレッドを作る必要がなくなりました。 | |
1458 つーことで、frontend_thread_run ではなく、 | |
1459 最初から spe_thread_run を起動すればおkとなりました。 | |
1460 | |
1461 * Cell/SpeThreads.cpp (SpeThreads::get_mail): if 文排除 | |
1462 今までは | |
1463 | |
1464 if (spe_out_mbox_read(spe_ctx[speid], &ret, 1) < 0) { | |
1465 return ret; | |
1466 else | |
1467 return -1; | |
1468 | |
1469 とやっていた。これは | |
1470 | |
1471 - データを読めたらそれ(ret)を返す | |
1472 - データが無かったら -1 を返す | |
1473 | |
1474 ってことだったんだが、よくよく考えると、spe_out_mbox_read() は | |
1475 データがなかった場合 ret の値を変えないので、最初に | |
1476 | |
1477 unsigned int ret = (unsigned int)-1; | |
1478 | |
1479 としておけば、最終的に if 文無しの | |
1480 | |
1481 spe_out_mbox_read(spe_ctx[speid], &ret, 1); | |
1482 return ret; | |
1483 | |
1484 だけで済むわけだ。 | |
1485 | |
1486 2008-05-22 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1487 | |
1488 * thinking: List DMA (2) | |
1489 MFC List DMA read の場合は(少なくともPPEでcreate_taskする時は) | |
1490 read size が決まっているので無問題。 | |
1491 しかし、MFC List DMA write の場合。同じタスクでも | |
1492 違うサイズを出力するということはありえるので問題。 | |
1493 今までも、write の場合は task->run() の返す値が write size として | |
1494 使う事にしていた。List DMA write の場合は、おそらく | |
1495 | |
1496 - task->run() 内で write 用の List DMA 構造体を作って Scheduler に | |
1497 渡して、task->write() でやってもらう | |
1498 | |
1499 って感じ? でも(上の手法に限らず)、write のサイズが決まってないと | |
1500 write 用バッファを生成しておく事ができないので | |
1501 書き込めない or あらかじめ多めに取っておくってことが必要になる。 | |
1502 後者は SPE には痛手(昔は強制16KB確保とかやってたな)なので微妙。 | |
1503 前者は論外だろう。 | |
1504 | |
1505 うーん、どうすっかな。Single DMA write の頃からこれは問題であって。 | |
1506 最悪、ユーザが「write のサイズが変動しないようなタスクにする」とか? | |
1507 | |
1508 * thinking: List DMA | |
1509 | |
1510 構想としては以下のような考え。 | |
1511 | |
1512 class Task { | |
1513 int cmd; | |
1514 DataListDMA *rlist; | |
1515 DataListDMA *wlist; | |
1516 }; | |
1517 | |
1518 class DataListDMA { | |
1519 int length; // リストの数 | |
1520 unsigned int addr[128]; // アドレス | |
1521 int size[128]; // そのアドレスから取得するデータのサイズ | |
1522 }; | |
1523 | |
1524 128 という数字は、一つのタスクが持てるリストの合計サイズを | |
1525 1KB (= 1024B) にしようってことで 4*128+4*128 = 1024 としました。 | |
1526 ListDMA を使う流れとしては | |
1527 | |
1528 1. Scheduler から cmd にそった Task を生成する | |
1529 2. Task のコンストラクタ(もしくは Task を生成する implement 内 )で | |
1530 task->rlist, task->wlist を DMA read しておく (ここは通常のDMA) | |
1531 3. task->read() で MFC List DMA で List を読む | |
1532 | |
1533 DataListDMA->length に関しては、Task の中に入れるのも有りかと思う。 | |
1534 その場合は、2 の DMA read で、わざわざ 1KB 全部読む必要は無くなる。 | |
1535 | |
1536 | |
1537 * tag: v20080522 | |
1538 - PPE 側のタスクも SPE と同じく、クラスオブジェクトとして登録 | |
1539 - PPE、SPE 側の TaskManagerImpl を整理。見やすくなったと思われ | |
1540 | |
1541 こんなところかなー。 | |
1542 テストプログラムは | |
1543 | |
1544 Game_project/student/master/gongo/hello | |
1545 | |
1546 にあります。DMA の例題まだだったぜHAHAHA | |
1547 ここからは List DMA の処理を入れて行きたいと思います。 | |
1548 | |
1549 現在の simple_render のバージョンは | |
1550 PPE のタスクが関数ベースだった頃のなのでそのままでは動きません。 | |
1551 List DMA ができるか、気晴らしに描き直すと思います。 | |
1552 | |
1553 * Task 定義について | |
1554 PPE も C++ のクラスオブジェクトとしてタスクを定義するようにしました。 | |
1555 ちゃんとした API を考えたら改めて書きます。 | |
1556 | |
1557 * メールチェックから次のタスクリスト生成までの流れの変更 | |
1558 今までの FifoTaskManagerImpl の mail_check では | |
1559 | |
1560 1. mail_check | |
1561 1.1 check_task_finish | |
1562 1.1.1 notify_wait_taskQueue | |
1563 1.1.1.1 append_activeTask (依存満たしたタスクを) | |
1564 1.2 get_runTaskList | |
1565 | |
1566 と、全て mail_check の中で終わってたんですが、これを | |
1567 | |
1568 1. mail_check | |
1569 1.1 check_task_finish | |
1570 1.1.1 notify_task_finish | |
1571 2. wakeup_waitTask (つまり append_activeTask) | |
1572 3. get_runTaskList | |
1573 | |
1574 というように分割しました。 | |
1575 おかげで CellTaskManagerImpl の mail_check もすっきり。 | |
1576 | |
1577 2008-05-13 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1578 | |
1579 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_task): | |
1580 // set_task って名前やめね? | |
1581 | |
1582 どの SPE に振るかって判定を少し変更。 | |
1583 cur_anySpeid の宣言場所のコメントにもあるけど、 | |
1584 これはインクリメントじゃなくて乱数の方が | |
1585 より SPE_ANY っぽいのか。むしろ「仕事してない方に割り振る」ってのが | |
1586 SPE_ANY の役目な気がするな。ウーム。。。 | |
1587 | |
1588 2008-05-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1589 | |
1590 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::mail_check): | |
1591 PPE には実行するタスクが一つも無い時の動作がおかしかった。 | |
1592 要するに、 | |
1593 | |
1594 PPE で実行するタスクは全て SPE で実行中のタスク待ち | |
1595 | |
1596 って時。。。よけいわからなくなったな。 | |
1597 まあなんだ、今まで 必ずタスクが PPE and SPE にあったんだけど | |
1598 PPE or SPE ってか、どっちか片方でしか動いてない状況だと | |
1599 終了判定というか、それがおかしかったっぽい。 | |
1600 | |
1601 Hello World でのタスクは | |
1602 | |
1603 1. "Hello World!!" と表示するタスク (2.) を発行するタスク | |
1604 2. 表示するタスク | |
1605 3. 2 が全て終わったら実行される、最後のタスク(番兵的な | |
1606 | |
1607 この時、(2) が SPE だけで実行されてると、 | |
1608 (2) の終了を待つ (3) の判定?というか、それがおかしい | |
1609 | |
1610 | |
1611 もう眠くてわけわからん。 | |
1612 一応動いたんだけど、やはり描き直します。 | |
1613 気持ち悪いほどやっつけな書き方してるので。これはきもい。。。 | |
1614 | |
1615 2008-03-09 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1616 | |
1617 * memo: pthread_cond_wait | |
1618 この ChangeLog に書くものでもないが、まあメモ。 | |
1619 | |
1620 セマフォの P 動作は、基本的に | |
1621 | |
1622 --------------------- | |
1623 pthread_mutex_lock(&sem->mutex); | |
1624 | |
1625 while(sem->value == 0) { // 資源が無い | |
1626 // 条件付き変数に自分を登録して、ロックを解放して、他の | |
1627 // プロセスが資源を解放してくれるのを待つ | |
1628 pthread_cond_wait(&sem->cond,&sem->mutex); | |
1629 } | |
1630 // 自分の分の資源があったので、それを確保する */ | |
1631 sem->value--; | |
1632 // ロックを解放する | |
1633 pthread_mutex_unlock(&sem->mutex); | |
1634 ---------------------- | |
1635 | |
1636 こんな感じ。でコメントにもあるように、 | |
1637 pthread_cond_wait では、wait の前に unlock する。 | |
1638 これがよくわかってなくて、「while の外で lock してるのに | |
1639 「なんで他のプロセスが lock できるんだろう。」と。 | |
1640 man 見ろよと思った。てか先生のページのコメントに書いてるよ! | |
1641 | |
1642 | |
1643 2008-03-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1644 | |
1645 * memo: mailbox read の blocking/non-blocking | |
1646 spe_out_mbox_read は non-blocking API なので、 | |
1647 これをぐるぐる回すと busy-wait になるので、 | |
1648 今の所 ppe 側の Scheduler がトップに戻る?時にメール確認する。 | |
1649 で、spe_out_intr_mbox_read は blocking API 。 | |
1650 spe_out_mbox_read との記述の違いは、予め | |
1651 spe_event_handler_register で SPE_EVENT_OUT_INTR_MBOX を | |
1652 登録しておく。spe 側では、 | |
1653 | |
1654 spu_writech(SPU_WrOutMbox, data) | |
1655 | |
1656 じゃなくて | |
1657 | |
1658 spu_writech(SPU_WrOutIntrMbox, data) | |
1659 | |
1660 を使う必要がある。 | |
1661 両者の mailbox read の速度を調べてみたけど、そんなに違いは感じない。 | |
1662 まあベンチマークの取り方がへぼいせいかもしれないけど。 | |
1663 ってことで、こっちの intr の方がいいんじゃないかと思う。 | |
1664 これと セマフォを組み合わせて mail の処理は簡単になると思う。 | |
1665 セマフォの処理が重いって話もあるが、どうなんだろうね。 | |
1666 | |
1667 * Test/simple_render/task/create_span.cpp (half_triangle): fix | |
1668 画面外の span を描画しようとして落ちるので、それの修正。 | |
1669 polygon->span の時点で外してるけど、span を外すより | |
1670 Polygon の時点で修正するべきかな? | |
1671 | |
1672 * kernel/ppe/TaskManagerImpl.cpp (TaskManagerImpl::set_task): fix | |
1673 返す TaskList が、mainTaskList の最後尾になってた。 | |
1674 ってことで、TaskList のトップである bufferManager->mainTaskList を。 | |
1675 | |
1676 * kernel/ppe/BufferManager.cpp (BufferManager::clear_taskList): fix | |
1677 mainTaskList->length はクリアしてるのに、 | |
1678 mainTaskList->next をクリアし忘れてた。 | |
1679 だから空の TaskList が送られてたのか・・・ちくしょう! | |
1680 | |
1681 2008-03-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1682 | |
1683 * bug-fix (Test/simple_render): y座標の移動方向 | |
1684 (1) で、書き込む時に | |
1685 | |
1686 y = height - y | |
1687 | |
1688 としていた。千秋に聞いてみると、 | |
1689 | |
1690 「ポリゴンの y を増やす(+)と、画面上に進むようにした」 | |
1691 | |
1692 だそうです。なるほどねー。ってことで(2)でもやったら上に進んだよ。 | |
1693 | |
1694 しかし、ゲーム的には上が + の方がわかりやすいかもしれんが、 | |
1695 プログラミング的には、framebuffer ベースでやるので、 | |
1696 下にいくと y++ ってほうが作りやすいかなーと思いつつ。どっちがいいかね | |
1697 | |
1698 * bug (Test/simple_render): y座標の移動方向 | |
1699 Viewer::run_draw で、従来の、SpanPack をそのまま描画する方法(1)と、 | |
1700 SPE に渡すように、8分割したものとして描画する方法(2)で、 | |
1701 それぞれの y に +0.5 とかしたら、移動する方向が違う。 | |
1702 (1)では上、(2)では下へ行く。 | |
1703 送られてくる span には違いが見られず、 | |
1704 x 方向や 回転は問題ないので、おそらく draw 時の y の計算のバグだろう。 | |
1705 | |
1706 1: polygon.cpp Polygon::draw(SPANPACK); | |
1707 2: task/span_pack_draw.cpp run(); | |
1708 | |
1709 * Test/simple_render/spe/SpuDraw.cpp: ↓の続きの解決 | |
1710 render_y &= ~7 | |
1711 | |
1712 これでおkでした。先生ありがとうございます。 | |
1713 今はマクロとして | |
1714 | |
1715 #define YTOP(y) (y & ~7) | |
1716 | |
1717 ってやってますわ。 | |
1718 | |
1719 2008-03-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1720 | |
1721 * memo: MFC List DMA の element の最大値 | |
1722 「Cell Broadband Engine Architecture Version 1.02」 より | |
1723 | |
1724 P.55 | |
1725 The maximum number of elements is 2048. | |
1726 Each element describes a transfer of up to 16 KB. | |
1727 | |
1728 ってことらしいです。一度の転送での制限は普通のDMAと変わらず16KB。 | |
1729 mfc_list_element_t は 2048 個まで設定できるってことか。 | |
1730 テクスチャのロードで、分割しないなら MFC List DMA を使うことになるが、 | |
1731 2048 個もあれば充分? | |
1732 | |
1733 | |
1734 * Test/simple_render/spe/SpuDraw.cpp: ↓の続き | |
1735 と思ったけど、やっぱりずれるなあ。うーむ。 | |
1736 とりあえず今は | |
1737 | |
1738 if (render_y < 0) { | |
1739 int tmpy = render_y%8; | |
1740 render_y -= tmpy + (tmpy != 0)*8; | |
1741 } else { | |
1742 render_y -= (render_y%8); | |
1743 } | |
1744 render_y += 1080/2; | |
1745 | |
1746 で落ち着くことに。うーむ。 | |
1747 もっと良い計算を考えるよりは span の生成時で | |
1748 いろいろやるほうがいいのかなー | |
1749 | |
1750 2008-03-04 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1751 | |
1752 * Test/simple_render/spe/SpuDraw.cpp: ↓の続き | |
1753 よくよく考えてだな。。。マイナスが気になるなら | |
1754 | |
1755 if (render_y < 0) { | |
1756 int tmpy = render_y%8; | |
1757 render_y -= tmpy + (tmpy != 0)*8; | |
1758 } else { | |
1759 render_y -= (render_y%8); | |
1760 } | |
1761 render_y += 1080/2; | |
1762 | |
1763 じゃなくて | |
1764 | |
1765 render_y += 1080/2; | |
1766 render_y -= (render_y%8); | |
1767 | |
1768 これでよくね?ってか元々そのための 1080/2 だった気が。。。 | |
1769 | |
1770 * Test/simple_render/spe/SpuDraw.cpp: render_y の計算の修正 | |
1771 sp->span[0].y (SpanPack に格納されてる最初の Span の y 座標) から | |
1772 この SpanPack が描画する範囲の一番上の y 座標を調べる。 | |
1773 | |
1774 どういうことかっていうと、例えば SpanPack に入ってる Span が持つ | |
1775 y 座標が 1 ~ 8 の時 | |
1776 | |
1777 1 ----- | |
1778 -- | |
1779 -------- | |
1780 ---- | |
1781 --------- | |
1782 8 -- | |
1783 | |
1784 '-' は描画していると思ってください。 | |
1785 この場合は、y = 1 がこの SpanPack の一番上、基準となる 座標ってこと。 | |
1786 framebuffer に書き込むとき、y = 1 から順々に書いて行きます。 | |
1787 | |
1788 で、sp->span[0].y ってのが、その基準となる y である保証が無いので、 | |
1789 sp->span[i].y 、つまりどの y からでも、基準となる y を求める | |
1790 必要がある。その計算をミスってました。 | |
1791 | |
1792 1 ////////// | |
1793 <- なぜか書き込まれていない | |
1794 ////////// | |
1795 ////////// | |
1796 | |
1797 みたいに、歯抜けした部分があったので、いろいろ調べてみたら | |
1798 この render_y がずれてるってことが判明しました。 | |
1799 今までは | |
1800 | |
1801 render_y = sp->span[0].y; | |
1802 render_y += 1080/2; | |
1803 render_y = (render_y/8)*8; | |
1804 | |
1805 ってことしてたんだけど、これだと sp->span[0].y が マイナスのとき | |
1806 ずれることが判明。なので | |
1807 | |
1808 if (render_y < 0) { | |
1809 int tmpy = render_y%8; | |
1810 render_y -= tmpy + (tmpy != 0)*8; | |
1811 } else { | |
1812 render_y -= (render_y%8); | |
1813 } | |
1814 render_y += 1080/2; | |
1815 | |
1816 こうするとできました。。。が、直したい。 | |
1817 もう少し奇麗に描けると思うんだけどなー。if 文ぐらいは外したい | |
1818 | |
1819 2008-03-03 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1820 | |
1821 * memo: 最適化の結果 | |
1822 ppe/spe ともに最適化なしの場合 | |
1823 263.444 FPS | |
1824 | |
1825 ppe だけ -O9 で最適化 | |
1826 317.425 FPS | |
1827 | |
1828 spe だけ -O9 で最適化 | |
1829 812.539 FPS | |
1830 | |
1831 ppe/spe ともに -O9 で最適化 | |
1832 1610.58 FPS (吹いた | |
1833 | |
1834 | |
1835 最初、ダブル最適化の画像を見た時の | |
1836 あまりの早さにびびった。 | |
1837 逆に「こ、これはバグか!?」と思った | |
1838 | |
1839 | |
1840 2008-02-28 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1841 | |
1842 * kernel/ppe/BufferManager.cpp: remove_taskQueue_all() | |
1843 taskQueue の create と free が釣り合って無くて、 | |
1844 queue が足りなくなる -> extend_pool -> 足りなく(ry | |
1845 ってのを繰り返してメモリ的なセグメンテーションフォルとが出て | |
1846 なんでかなと思ったら、task->wait_me を消去してなかった。 | |
1847 task->wait_i は notify(ry で削除されるんだけど、 | |
1848 task->wait_me は、notify(ry に渡した後ほったらかしだった。 | |
1849 ってことで、wait_me を全消しする関数を作りましたとさ。 | |
1850 気持ち速度が増した気がする。気ね。 | |
1851 | |
1852 | |
1853 2008-02-17 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1854 | |
1855 * Todo: 悩んでる所 | |
1856 | |
1857 | |
1858 * fix: kernel/ppe/HTask.cpp | |
1859 今まで、manager->create_task で生成したタスクは | |
1860 | |
1861 - dependency の設定 | |
1862 manager->set_task_depend(master, slave) // slave は master を待つ | |
1863 | |
1864 - 実行キューへの追加 | |
1865 manager->spawn_task(master); | |
1866 manager->spawn_task(slave); | |
1867 | |
1868 と、manager を介してやっていました。 | |
1869 まあそれでもいいんだけど、特に dependency の所は | |
1870 どっちがどっちを待つのかってのは、API見るだけじゃわからない。 | |
1871 そこで、Task (HTask のこと) に、上二つに対応するような | |
1872 | |
1873 void set_depend(HTaskPtr) と void spawn(void) を追加しました。 | |
1874 | |
1875 - Usage | |
1876 slave->set_depend(master); // slave は master を待つ | |
1877 slave->spawn(); // slave をキューへ追加 | |
1878 | |
1879 結局は、それぞれの関数の中では、上の set_task_depend とかを | |
1880 呼んでるんだけど、ユーザ側からするとこの方がわかりやすいと思います。 | |
1881 | |
1882 2008-02-16 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1883 | |
1884 * tag: beta3 | |
1885 ダブルバッファリングを追加し、まあなんとか動いてるんじゃない?って | |
1886 ところまでですが、所詮 Fifo バージョンなので、 | |
1887 そろそろ Cell を書き上げて、並列にちゃんと動いてるか確かめないとね | |
1888 | |
1889 * add: kernel/ppe/DmaBuffer.cpp | |
1890 ダブルバッファリング用に作ったんだけど、 | |
1891 せっかくなので、DMA は、このオブジェクト(が持つ二つの領域)でしか | |
1892 行えないようにする。ってのでどうでしょう。って話を先生としました。 | |
1893 並列処理だし、ダブルバッファリングがデフォでいいでしょう。 | |
1894 というか、したくなければ swap_buffer とかしなければおk。 | |
1895 | |
1896 -Usage | |
1897 DmaBuffer *buffer = manager->allocate(sizeof(SceneGraphPack)); | |
1898 | |
1899 今までと違い、create_task の in_addr と out_addr には | |
1900 DmaBuffer をいれてください。ユーザが自分で malloc/new したやつは | |
1901 エラーを出すようにしてる(seg faultだけどね!) | |
1902 汚いソースだが、実際に使ってる様子は Test/simple_render の | |
1903 viewer.cpp で使ってます。sgp_buff と pp_buff ってやつね。 | |
1904 | |
1905 もうすこしユーザに優しいAPIを作りたい・・・ | |
1906 | |
1907 2008-02-11 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1908 | |
1909 * add: Test/simple_render | |
1910 chiaki の DataPack を使った Cube の表示プログラム。 | |
1911 簡単に DataPack を TaskManager の scheduler (SpeManager) に渡して | |
1912 処理してコピーして、を繰り返してるだけなんだけど | |
1913 まあ動いてる気がするのでいいんじゃないでしょうか。 | |
1914 | |
1915 | |
1916 2008-02-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1917 | |
1918 * tag: beta1 | |
1919 この状況だと、できることよりもできないことを書くべき?違うか。 | |
1920 | |
1921 - task (親) 中で task (子) を生成することはできない | |
1922 正確には「生成はできる」だけど、その 子task が | |
1923 親task に依存している別の task を無視して動くので | |
1924 ちゃんとした結果にならないと。 | |
1925 8日の Todo にも書いてあるけど、今の実装では | |
1926 task が task を生成することを想定してない感じなので。 | |
1927 完全に spe 用にのみ狙いを絞った実装であって | |
1928 OS って言えない実装であるからして、書き直すの? | |
1929 全ての関数を task しようとするとこうなる訳で、 | |
1930 ある部分だけやるってのはまあできるんだろうけど、うーん。 | |
1931 | |
1932 - chiaki の simple_render が動かない | |
1933 (追記) 解決しました | |
1934 単に read/write buffer のサイズが足りないだけだった。アホスwww | |
1935 まあ辱めの為の下は残しておこう | |
1936 | |
1937 まだ cvs に commit してないけど、chiaki が書いた、 | |
1938 DataPack 対応の simple_render に TasKManager を組み込んでみた。 | |
1939 といっても、OSっぽく書いたんじゃなく、今は | |
1940 update_sgp と create_pp だけを task 化してみた。 | |
1941 でまあ動いてるような気はするけど、ものすっごい malloc 系の warning が。 | |
1942 時々長く動くよねみたいな感じになってしまっている。 | |
1943 TaskManager が悪いのか、simple_render が悪いのか。 | |
1944 この TaskManager、ある部分での malloc 系の問題に敏感だなあ。 | |
1945 まあそうでなかったらバグの探しようも無いし、良いっちゃー良いんだが。 | |
1946 | |
1947 | |
1948 2008-02-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
1949 | |
1950 * add: kernel/ppe/SymTable.cpp | |
1951 今まで func[] = {add, sum, ...} | |
1952 とかやってかっこわるい言われまくってたので | |
1953 話し合いの通り Symbol Table みたいなものを作ることに | |
1954 | |
1955 // 疑似コードね | |
1956 struct sym_table { | |
1957 char *sym; // シンボル | |
1958 void *address; // シンボルが示すアドレス | |
1959 } sym_table[] = {{"Sum", &Sum} , {"Draw", &draw}}; | |
1960 | |
1961 int fd = get_fd("Sum"); | |
1962 void *addr = get_address(fd); | |
1963 | |
1964 table には "Sum" と "Draw" っていう二つのシンボルが登録されている。 | |
1965 例えば、ユーザ(カーネル?)が "Sum" ってシンボルにアクセスしたい場合、 | |
1966 まずは get_fd で "Sum" に対する、file descripter を返す。 | |
1967 ユーザは、その fd に従って get_address を取得することが出来る。 | |
1968 TaskManager 的な使い方をするなら | |
1969 | |
1970 // 俺は今、Draw 関数を使うタスクを生成したい | |
1971 int fd = manager->open("Draw"); | |
1972 manager->create_task(fd, size, in, out, func); | |
1973 manager->open では get_fd と同じ使い方です。 | |
1974 | |
1975 まだ改良の余地ありそうですが、今は動いてるってことで。 | |
1976 | |
1977 | |
1978 - 補足 | |
1979 なぜ file descripter と表すか | |
1980 | |
1981 OS の昨日として、 fopen とかと同じ使い方もできるじゃない! | |
1982 | |
1983 | |
1984 * Todo: task が task を生成する際の処理 | |
1985 今まで、 task が行う作業は、演算のみを行うような | |
1986 単純な実装に決め打ちされているわけです。 | |
1987 しかし、OS なんかだと、タスク中から別のタスクを生成するとか | |
1988 ありありだと思われる。てか今のテストプログラムでなった。 | |
1989 | |
1990 Test/Sum にあるプログラムで使われるタスク | |
1991 | |
1992 - init2 // 貧相な名前ですまない | |
1993 演算する数値とかバッファの初期化 | |
1994 | |
1995 - sum1 | |
1996 ある範囲の整数 (i から i+16 とか) の総和 | |
1997 | |
1998 - sum2 | |
1999 sum1 で求められた、複数の範囲の総和を一つにまとめる | |
2000 (ex. 複数の sum1 が 1->16, 17->32, 33->48 の総和を計算し、 | |
2001 sum2 で 上の3つの総和を計算する | |
2002 要は 1->48 の総和を分割するっていうプログラムね | |
2003 | |
2004 - finish | |
2005 sum2 で求まった値を表示 | |
2006 | |
2007 この Sum というプログラム、というか OS と言おう。SumOS ね。 | |
2008 SumOS は最初に TaskManager (所謂 kernel) を起動し、 | |
2009 init を起動する。init では、予め決められたタスクである | |
2010 init2 と finish の二つのタスクを create して登録する。 | |
2011 init2 と finish には依存関係がある (init2 が終わったら finish) | |
2012 init2 の中で、sum1 と sum2 というタスクが作られる。 | |
2013 sum1 と sum2 にも依存関係はある (sum1 が終わったら sum2) | |
2014 | |
2015 今の実装だと、タスクが終了して初めて次のタスクへ行く。 | |
2016 まあ当たり前なんだけど、例えばそのタスクの中で | |
2017 新たにタスクが作られた場合、そのタスクが終了するまでは | |
2018 実行されなくなってしまう。 | |
2019 でまあ、今は、manager->create_task される度に | |
2020 manager->run とかして、無理やり起動してる訳さ。 | |
2021 何が無理矢理かっていうと、scheduler の役目をしている | |
2022 SpeManager (これも名前変えないと) を2度呼び出してる訳。 | |
2023 つまり、タスク中でタスクを作る度に、SpeManager オブジェクトを | |
2024 new してるわけさ。いいのか?いや、動いてるけどね? | |
2025 | |
2026 ちなみに、Cell version だと spe が勝手に取っていってくれるから | |
2027 大丈夫かなと思いつつ、もし spe を1つしか使わない設定だったら微妙。 | |
2028 | |
2029 要するに、タスク中でタスクが作られる場合の処理を考えないとね。 | |
2030 | |
2031 2008-02-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
2032 | |
2033 * memo: プログラミングの姿勢 | |
2034 scheduler とか、task の管理をする部分は | |
2035 kernel programing のつもりで、 | |
2036 example とか、task に割り当てる処理を決めたりする部分は | |
2037 user programing のつもりで。 | |
2038 | |
2039 それぞれ違った視点で見る必要がある | |
2040 | |
2041 * memo: OS というもの | |
2042 OS 起動の流れ | |
2043 | |
2044 - PC の電源を入れる | |
2045 - BIOS が立ち上がる (OpenFirmWare, EFI, BIOS) | |
2046 - 起動デバイスをチェック (優先度とか種類とか) | |
2047 - 起動デバイスから Boot loader を起動 | |
2048 + BIOS によって、認識できるファイルシステムが違う(だっけ?) | |
2049 + ファイルシステムのどこに Boot Loader があるか知っている | |
2050 + grub, grub2, lilo, kboot などがある | |
2051 - Boot Loader が kernel を起動 | |
2052 + ネットワークブートの場合、TCP/IP や | |
2053 ネットワークデバイス(イーサとか?)のドライバを持ってる必要がある | |
2054 - kernel は、最初に scheduler を起動する | |
2055 - scheduler の初期化 (init を呼ぶ?) | |
2056 - init では、事前?に設定されているスクリプトとかを呼ぶ | |
2057 + linux とかだと /etc/rc にあるやつを init が呼ぶ | |
2058 - login form が起動 | |
2059 | |
2060 補足 こっからユーザ | |
2061 - login する | |
2062 - shell を呼ぶ | |
2063 + login shell かどうか確かめる | |
2064 - ユーザに設定されてる起動スクリプト?を実行 | |
2065 - 晴れてログイン | |
2066 | |
2067 2008-02-06 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
2068 | |
2069 * kernel/spe/*.cpp: new と placement new | |
2070 現在、spe kernel のタスクは、切り替わる毎に | |
2071 new/delete を繰り返しています。今はこれでいいんだけど、 | |
2072 速度的にも、いずれは直さないといけないと思うわけで。 | |
2073 で、予め allocate された領域を利用した placement new を使えば | |
2074 new よりもそれなりに早くなるっぽい。 | |
2075 例題として、与えられた回数分 new/delete を繰り返すプログラムと、 | |
2076 同じ回数分、placement new したときの速度の比較 | |
2077 | |
2078 for (int i = 0; i < num; i++) { | |
2079 | |
2080 < task = new Task; | |
2081 < task->init(i); | |
2082 < task->printID(); | |
2083 < delete task; | |
2084 --- | |
2085 > task = new(buff) Task; // buff = malloc(BUFF_SIZE); | |
2086 > task->init(id); | |
2087 > task->printID(id); | |
2088 } | |
2089 | |
2090 placement new では、delete の必要は無い。 | |
2091 その中で新たに allocate してるなら必要かもしれないが。 | |
2092 速度比較は以下。no_new が placement new で、ln_new が new/delete 。 | |
2093 | |
2094 % ./a.out 10 // 10 回 | |
2095 no_new: time: 0.012135(msec) | |
2096 ln_new: time: 0.003572(msec) | |
2097 | |
2098 % ./a.out 100 | |
2099 no_new: time: 0.022453(msec) | |
2100 ln_new: time: 0.018989(msec) | |
2101 | |
2102 % ./a.out 1000 | |
2103 no_new: time: 0.115277(msec) | |
2104 ln_new: time: 0.136335(msec) | |
2105 | |
2106 % ./a.out 10000 | |
2107 no_new: time: 1.056156(msec) | |
2108 ln_new: time: 1.322709(msec) | |
2109 | |
2110 % ./a.out 100000 | |
2111 no_new: time: 10.622221(msec) | |
2112 ln_new: time: 13.362414(msec) | |
2113 | |
2114 % ./a.out 1000000 | |
2115 no_new: time: 109.436496(msec) | |
2116 ln_new: time: 136.956872(msec) | |
2117 | |
2118 10、100 回だと負けてるが、まあ無視しよう(ぇ | |
2119 回数が多くなるにつれて、ほんの少しだが no_new が勝ってる。 | |
2120 どうなんだろうね。ちなみに printID を無くすと | |
2121 | |
2122 % ./a.out 1000000 | |
2123 no_new: time: 0.008512(msec) | |
2124 ln_new: time: 27.100296(msec) | |
2125 | |
2126 I/O に左右され過ぎ。まあそんなもんだろうけどさ。 |