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