Mercurial > hg > Game > Cerium
annotate TaskManager/ChangeLog @ 2047:de89da997e07 draft
add FileMapReduce
| author | Nozomi |
|---|---|
| date | Wed, 27 Jan 2016 19:09:33 +0900 |
| parents | effb5653fd5c |
| children |
| rev | line source |
|---|---|
|
1915
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
1 2014-1-20 Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp> |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
2 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
3 cuda で clEnqueueNDRangeKernel に相当するものが cuLaunchKernel |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
4 OpenCL の場合は global_work_size(0)*...*global_work_size(work_dim-1) で起動する kernel の数が決まる。 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
5 cuda の場合は gridDim * blockDim で決まる。 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
6 ただし、gridDim と blockDim には最大数がある。gridDim は 2^16, blockDim は 2^9 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
7 いまの iterate では cuda に対応できない。 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
8 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
9 cuda には OpenCL の command_queue に相当するものがない。 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
10 stream が command_queue に近い。 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
11 複数の stream は並列に走らせることができる。 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
12 実行の順序は gpu 側で制御されるとか言う記述が... |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
13 out of order で実行される？ |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
14 OpenCL も複数の command_queue を並列に走らせることができる？ |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
15 command_queue も1つの queue に全部入れるんじゃなくて、command_queue を複数作ったほうがいい？ |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
16 command_queue 同士で同期は取れるけど、べつの queue の event とか待てるのか？ |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
17 command_queue の粒度は下げれば event 使わなくても出来そうな気がする。 |
|
effb5653fd5c
update cuda, yet running
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1891
diff
changeset
|
18 |
|
1891
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
19 2014-1-4 Shinji kONO <kono@ie.u-ryukyu.ac.jp> |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
20 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
21 MY_SPE_STATUS_READY は task 終了を待ってから出しているが、あまり、望ましくない。 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
22 spe_running の意味とは異なってしまうが、もう TaskFinishMail は来ないという意味でも良い。 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
23 その代わり、本当の終了を待つというプロトコルが必要になる。 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
24 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
25 Many Core 側でも必要以上に待っている? もっとも、DMA pipeline が動いてないので |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
26 ほとんど関係ないが。SchedTaskList は SchedTask を継承しているのでT1を兼ねてる。 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
27 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
28 write T3 T2 T1@ N2 N M * MY_SPE_STATUS_READY |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
29 exec T2 T1 N2 N M T1 @ TaskFinishMail |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
30 read T1 N2* N M T1 T2 ! TL dma load |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
31 next N2 N M% TL! T2 T3 % TL mail read |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
32 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
33 MY_SPE_STATUS_READY は TaskFinishMail よりも早めに出すほうが良いのか。 |
|
e0d465efc57e
directory reogranization for Cell/Fifo/ManyCore/Gpu
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1885
diff
changeset
|
34 |
| 1885 | 35 2014-1-3 Shinji kONO <kono@ie.u-ryukyu.ac.jp> |
| 36 | |
| 37 speTaskList を cyclic queue に直しそこねてた。 | |
| 38 PPE 側は Synchornized Mail Queue を使うべきではない。(当然) | |
| 39 ParallelDmaManager とかを作るのが良いと思われる。 | |
| 40 ppe で conditional wait するのが良いとは限らないが。 | |
| 41 | |
| 42 余計なdebug message出すのは良いが switch で切れるようにして欲しい。 | |
| 43 IO thread のtestをしてない。 | |
| 44 | |
| 1879 | 45 2014-1-1 Shinji kONO <kono@ie.u-ryukyu.ac.jp> |
| 46 | |
| 47 check_task_list_finish は dim_count を見る必要があるが、taskList はcopyされているので、 | |
| 48 dim_count に関係なく削除する必要がある。 | |
| 49 | |
| 50 MY_SPE_STATUS_READY って要らないんじゃないの? Pipeline の邪魔しているだけだし。 | |
| 51 | |
| 52 taskListInfo 側にどんどん足されてしまうので、taskListInfo を早めに送信してしまうのはだめらしい。 | |
| 53 | |
| 54 dead lock の原因は? GPU でも SPU でも起きる。 | |
| 55 | |
| 1874 | 56 2013-12-27 Masataka Kohagura <kohagura@cr.ie.u-ryukyu.ac.jp> |
| 57 | |
| 58 spe側のTaskListのpipelineの間が空いているので、それを埋める必要がある | |
| 59 speTaskListを処理している間に、次のTaskを送っておく。 | |
| 60 speからTaskList終了mailがきたら、その場でspeTaskListの終了をcheckする。 | |
| 61 speTaskListがemptyならば、speがTaskListInfoを実行中でもsetTaskListしてよい。 | |
| 62 Task終了mailがきたときに、speTaskListとtasklistinfoのどちらかからTaskを取り除く必要がある。 | |
| 63 それはTaskListのアドレスがあるので、自動的に行われる。 | |
| 64 speはすでにTaskListInfo側を実行しているかも知れないが、speTaskListを調べてemptyならばそれを解放する。 | |
| 65 | |
| 66 Semaphore では排他制御されているので、atomic increment の意味はない。 | |
| 67 Synchronied Mail の方では、1対1以外の場合は、atomic incrementする必要がある。(してない) | |
| 68 | |
| 69 | |
| 1872 | 70 2013-12-27 Masataka Kohagura <kohagura@cr.ie.u-ryukyu.ac.jp> |
| 71 | |
| 72 read / write を専用に行うCPU threadを用意する | |
| 73 pthread_setschedparamを用いて、I/O thread のpriorityをあげる | |
| 74 set_cpu(IO_0); | |
| 75 | |
| 76 | |
|
1825
82c2b9eec625
remove error and warning fileread(but cannot running)
Masataka Kohagura <e085726@ie.u-ryukyu.ac.jp>
parents:
1824
diff
changeset
|
77 2013-12-14 Masataka Kohagura <kohagura@cr.ie.u-ryukyu.ac.jp> |
| 1824 | 78 |
| 79 fileを分割してmap reduce を行うAPIを作成する。 | |
| 80 mapreduce(const char *filename , long division_size, int task_blocks, | |
|
1825
82c2b9eec625
remove error and warning fileread(but cannot running)
Masataka Kohagura <e085726@ie.u-ryukyu.ac.jp>
parents:
1824
diff
changeset
|
81 int map_cmd, int reduce_cmd, long size_param); |
| 1824 | 82 |
| 1815 | 83 2013-12-12 Shohei KOKUBO <kokubo@ie.u-ryukyu.ac.jp> |
| 84 | |
| 85 現在の GpuScheduler の pipeline 実行は2並列(cur=0,1) | |
| 86 これをn個に拡張する | |
|
1870
44fa0f1320a9
run wordcount with iterate
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1825
diff
changeset
|
87 |
| 1773 | 88 2013-11-23 Shinji kONO <kono@ie.u-ryukyu.ac.jp> |
| 89 | |
| 90 Open CL の event の扱い方が良くない | |
| 91 | |
| 92 pipeline buffer は、構造体で待つ。 | |
| 93 reply | |
| 94 kernel | |
| 95 memin x n | |
| 96 memout x n | |
| 97 read_event x n | |
| 98 write_event x n | |
|
1870
44fa0f1320a9
run wordcount with iterate
Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp>
parents:
1825
diff
changeset
|
99 kernel_event |
| 1773 | 100 これらを、すべて二重に持つ。必要なら n の分 extension する。 |
| 101 | |
| 102 event は、上書きす前にすべて、release する必要がある。 | |
| 103 | |
| 104 clEnqueueWriteBuffer, clEnqueueNDRangeKernel, clEnqueueReadBuffer は、eventlist で待ち合わせる。 | |
| 105 | |
| 106 clEnqueueWriteBuffer は、前の clEnqueueWriteBuffer を待つ | |
| 107 clEnqueueNDRangeKernel は、 clEnqueueWriteBuffer を待つ | |
| 108 clEnqueueReadBuffer は、clEnqueueNDRangeKernel を待つ | |
| 109 | |
| 110 clEnqueueReadBuffer, clEnqueueWriteBuffer は、あるとは限らない | |
| 111 | |
|
1762
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
112 2013-11-22 Shinji kONO <kono@ie.u-ryukyu.ac.jp> |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
113 |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
114 Multi Dimention の実装がよろしくない。複雑過ぎる。 |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
115 |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
116 Cpu tasklist を無視して全員に送る |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
117 Cpu 側では自分以外のtaskは無視する ( tasklist 上に cpu が書いてある) |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
118 終わったら tasklist 上で count down する |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
119 count down が 0 になったら、waiting queue から削除する |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
120 それまでは、他のCPUも止まる |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
121 MD と非MDが同じ tasklist に混じってしまうと動作がおかしい |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
122 |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
123 新しい実装? |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
124 MDtask はcopy して、すべてのCpu tasklist に入れる |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
125 spawn task でのすべてのCPUへの送信は廃止 |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
126 終わったら HTask 上で count down する |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
127 count down が 0 になったら、waiting queue から削除する |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
128 |
|
b53d197ec03d
copy task list for multi dimention
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1506
diff
changeset
|
129 |
|
1506
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
130 2012-9-5 Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp> |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
131 |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
132 set_cpu(SPE_ANY) |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
133 CPUで実行するかGPUで実行するか選択可能にする |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
134 CPU_ANYとGPU_ANYを追加 |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
135 SPE_ANYを選択したときにGPUで実行できるかはコマンドラインで選択した方がよい |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
136 -cpuと-gpuで選択する |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
137 ベンチマークを取る事も考える |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
138 |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
139 sortではflipを使っている |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
140 flip:input data上で計算を行ったときにそのinput bufferをそのままoutput bufferにする機能 |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
141 これをGPUで実現するにはbufferをread writeにすればよい |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
142 そのためにはtask投入時にflipするかどうかを知っている必要がある |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
143 taskにbit fieldを使ったflagがあるので、そのAPIを足す。かなりの変更が必要 |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
144 schedTaskのflipはやめる |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
145 |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
146 将来的にはCLのソースとCeriumのソースは同じにしたい |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
147 CLに合わせるか、CLを生成するかのどちらか |
|
a7895ab4d0e3
add flip flag and NDRange flag
Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
parents:
1503
diff
changeset
|
148 |
| 1502 | 149 2012-8-22 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 150 | |
| 151 今後の課題 | |
| 152 | |
| 153 GpuScheduler の pipeline 化 | |
| 154 kernel のコードの共通化 | |
| 155 性能測定 | |
| 156 | |
| 1503 | 157 Rendering Engine の wait for の追加 |
| 158 Rendering Engine の 拡大縮小 | |
| 159 Rendering Engine の GPU 化 (できるのか?) | |
| 160 Open CL から frame buffer って、どうやって触るんだろう? いや、そのまま動くのか。 | |
| 161 | |
| 1502 | 162 2012-8-22 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 163 | |
| 164 id_offset というのが CpuThreads にあったので、それで対処しました。 | |
| 165 id_offset まで GPU みたいな感じ。GPU も複数にするのは難しくないが。 | |
| 166 | |
| 167 終了手順 | |
| 168 | |
| 169 CPU は暇になると MY_SPE_STATUS_READY を PPE に送る。暇な CPU の数を spe_running で数えておく | |
| 170 PPE が暇になって(active task queue が empty)、spe_running が 0 なら、終了。 | |
| 171 CpuThreads destory 時に、MY_SPE_COMMAND_EXIT を thread に送る。 | |
| 172 thread は MY_SPE_COMMAND_EXIT が来たら抜ける。 | |
| 173 CpuThreads destory は、thread を join で待つ。 | |
| 174 | |
| 175 | |
| 1499 | 176 2012-8-22 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 177 | |
| 178 Open CL の kernel の実行はできたが、Scheduler が終了しない。 | |
| 179 | |
| 180 cl command queue は二本用意して pipelining するべき。 | |
| 181 | |
| 1500 | 182 tasklist の配列と GPU/CPU の対応が不明。 |
| 1499 | 183 |
| 1473 | 184 2012-7-15 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 185 | |
| 186 GpuTaskManager は明らかに不要。FifoManager は CellTaskManager の簡易版に過ぎない。 | |
| 187 CellTaskManager にも Cell 依存性はないはず。(DMA/Mail にしか依存しない) なので、 | |
| 188 CellTaskManager => TaskManager で一つにすることが可能。 | |
| 189 | |
| 190 そもそも -cpu 0 で fifo にするようにしたのだった。 | |
| 191 | |
| 192 SpeTaskManager が必要なのは、SchedTask のAPIのため。ってことは、SpeTaskManager は Impl を継承してはいけない。 | |
| 193 TaskManager には interface だけ定義されるべき。 | |
| 194 | |
| 1475 | 195 inListData とかは DMA しないなら不要なんだよな。切れるようにするべきか? |
| 196 | |
| 1473 | 197 2012-7-15 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 1465 | 198 |
| 199 inData をmallocしないで、小さいものは SchedTask に入れておく方が良い。 | |
| 200 HTask には TaskList が必ず付くようになったので、create_task した時に、dependency と | |
| 201 CPU が同一なら、そのTaskList を再利用して良い。そのためには、それらを最初に定義した | |
| 202 方が良い。 | |
| 203 | |
| 1472 | 204 これだと、GPU は一つだけだし、GPU にすると、Many Core 側が動かないと思うんだけど。 |
| 205 まぁ、そうだよな。 | |
| 206 | |
| 1473 | 207 いろいろ消したので、不要なものが多い。切れない TaskLog とか -DNOT_CHECK とか。 |
| 208 | |
| 209 そもそも、GpuScheduler::run が呼ばれてないらしい。 | |
| 210 | |
| 211 2012-3-16 Shinji KONO <kono@ie.u-ryukyu.ac.jp> | |
|
1427
db5c022d871c
task array uses TaskList. (on going)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1426
diff
changeset
|
212 |
|
db5c022d871c
task array uses TaskList. (on going)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1426
diff
changeset
|
213 create_taskを sub task でやると、tasklist のallocate にlockがいる。 |
|
db5c022d871c
task array uses TaskList. (on going)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1426
diff
changeset
|
214 SchedTask->task_create でschedulr毎に tasklist を持たせてやるとlockは不要になる。 |
|
db5c022d871c
task array uses TaskList. (on going)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1426
diff
changeset
|
215 task create は GPU/SPU 側では作成しないはず。しても良いが。TaskList を作って書きだせば良い。 |
|
db5c022d871c
task array uses TaskList. (on going)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1426
diff
changeset
|
216 それは、まぁ、先のことにして。 |
|
db5c022d871c
task array uses TaskList. (on going)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
1426
diff
changeset
|
217 |
| 1426 | 218 2012-3-11 Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp> |
| 219 | |
| 220 create_task_array を、rbuf上にtaskarrayを構築している。 | |
| 221 TaskList上に直接構成する。 | |
| 222 next_task_arrayで、任意のTaskを選択できるようにする。 | |
| 223 | |
| 224 setTaskListで、作成したTaskListを直接TaskListQueueに挿入する。 | |
| 225 これを、TaskArray1として実行する。 | |
| 226 これでコピーがなくなる。 | |
| 227 | |
| 228 SimpleTaskと、TaskArray1のみになる。 | |
| 229 TaskListの大きさが可変になるので、ポインタタグで大きさを示す。 | |
| 230 | |
| 231 TaskListをロードするパイプラインを1段足す。 | |
| 232 | |
| 1402 | 233 2012-2-15 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 234 | |
| 235 create_taskを可変長にして、それをそのままspu側に転送する | |
| 236 task_listの大きさは現在固定。このままだと無駄な転送が増える。 | |
| 237 task_listのアドレスを送る際に、下位3bitがあいているのでこれを大きさに使う。 | |
| 238 | |
| 239 可変長にするが、ScedTask::nextでcur_indexを使っているがこれをnext()とlast() | |
| 240 に置き換える。これでTask_array1とTask_arrayを消すことができる。 | |
| 241 | |
| 242 create_taskがTask_listに直接書き込んでいく。wait_forはcreate_taskのみにかかる。 | |
| 243 next()で、Task_arrayを追加するAPIにする。 | |
| 244 | |
| 245 TaskManagerImpl::set_taskList()でactive_task_queueからtask_listにcopyしている。 | |
| 246 ここで、copyしないでcreate_taskで作成したlistをそのまま使う。 | |
| 247 | |
| 1165 | 248 2011-5-21 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 249 | |
| 250 spu 上の bound で、ListElement を書き換えるようにすると、 | |
| 251 ListElement を64bitにできる。 | |
| 252 | |
| 253 あとは mail の返値を EA を使って 64bit addressにすれば、Cell でも64bit で | |
| 254 動くようになるか。 | |
| 255 | |
| 256 | |
| 257 2011-2-22 Yutaka Kinjyo <yutaka@cr.ie.u-ryukyu.ac.jp> | |
| 1146 | 258 |
| 259 SPE使った場合、光源が変なバグ直したん。 | |
| 260 task/CreateSpanでは normal はしっかり扱っていたが spe/CreateSpanは、そのコードがなかった。反映ミスかな。 | |
| 261 % cp task/CreateSpan spe/CreateSpan で解決。 | |
| 262 | |
| 263 SPEのTaskがPPEで実行されるようになっていたから、発現しなかったのかも。 | |
| 264 PPE で動いた Task がSPEで動こない場合は | |
| 265 | |
| 266 ・コードが違う | |
| 267 ・データ構造が合わせきれていない(アラインメント、16バイトの倍数) | |
| 268 ・Taskの wait ができていない | |
| 269 | |
| 270 とか挙げられる。「同じコードのはず」という先入観あると手こずるのかも。 | |
| 271 spe と ppe の Task を diff とるスクリプト書けばいいかな。 | |
| 272 あとは、どのTaskがどこで実行されているかは確認できた方がいい。debugモードに入れるべきかな。 | |
| 273 | |
| 274 データ構造のチェックも、if文でチェックしてやればできるはず。 | |
| 275 Task の wait のチェックは、ガントチャートを表示してやるとわかるはず。 | |
| 276 | |
| 277 でも実はまだ、gaplant が Cell/光源ON では表示されない。が上のチェックを入れたら、もしかしたら、分かるかも知れない。 | |
| 278 | |
| 279 ------------------------------------------------------------------------------------------------------------------ | |
| 280 | |
| 281 あと、CreatePolygonFromSceneGraph をSPEで動くようにしたせいか、FPSが落ちました(ありゃりゃ。)。 | |
| 282 SPEに持っていくために、メモリアロケートを多様しているせいかも。 | |
| 283 そこは、DataSegment いれて、メモリ管理してやれば、解消されるのかな。 | |
| 284 ちなみに、CreatePolygon はSPEで動かすと、メモリ足りないそうで、SPE側のコンパイルは切って、PPEで動いてます。(ありゃりゃ) | |
| 285 | |
| 286 | |
| 287 ball_bound 25 〜 30 FPS | |
| 288 | |
| 289 だいぶ、落ちたな。ball_bound だけは、CP を SPE で動かしても、動くんだけど、FPSは同じ。 | |
| 290 きゃー。パイプライン化しないとダメってことですね。 | |
| 291 | |
| 292 ・きっちりTask化したなら、パイプライン化しないと元がとれない | |
| 293 | |
| 294 | |
| 295 いろいろバグから、チェックすべきコードがわかったりするのね。 | |
| 296 | |
| 297 | |
| 1123 | 298 2011-2-12 Yutaka Kinjyo <yutaka@cr.ie.u-ryukyu.ac.jp> |
| 299 | |
| 1472 | 300 MemHash の hash() の返り値の受け取りが int でした。そのせいで、配列のindexがマイナスを示し、値が毎回変わる結果に。 |
| 1123 | 301 キャッシュに失敗しているので、毎回テクスチャのロードが入っていた見たいです。 |
| 302 そのロード時間が busy_ratio の値に含まれていた。なぜ？ unsinged intになおし | |
| 303 その結果なんと！ | |
| 304 | |
| 305 Cell | |
| 306 | |
| 307 ball_bound 40 〜 50 FPS | |
| 308 universe 約 20 FPS | |
| 309 gaplant 40 FPS | |
| 310 panel 3 FPS | |
| 311 ieshoot 30 FPS | |
| 312 | |
| 313 です。タスクリストのメール時間も全体の速度が速くなったので、7,8%から30%になり改善の余地あり。面白くなってきました。 | |
| 314 | |
| 1052 | 315 2010-12-10 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 316 | |
| 317 task_list を PPE の main memory において、それを get_segment で取って来る。 | |
| 318 実行する object は、PPE 側の main memory 上に置く。それを get_segment で | |
| 319 copy して実行する。 | |
| 320 | |
| 321 taskのindata/outdata/get_segment を実際にはコピーしないようにすると良いのだが... | |
| 322 そうすれば、実行時のアドレスが変わらないのでデバッグが容易。 | |
| 323 そういうオプション? いや、get_segment をそういうようにする? | |
| 324 | |
| 325 task_list 上に固定アドレス task かどうかの選択を入れれば良いのか。 | |
| 326 | |
| 327 とりあえず、task_list を get_segment するところから書くのが良さそう。 | |
| 328 | |
| 329 task_list のaddress を SPE にどうやって教えるかと言う問題がある。 | |
| 330 mail かな。 | |
| 331 | |
| 332 tag 使う? argv で渡すってあり? envp で送れるのではないか? | |
| 333 envp はダメだが、argv では渡せるらしい。 | |
| 334 | |
| 335 まず、ppe と spe の task_list を作る API の設計と実装をするべきらしい。 | |
| 336 | |
| 337 Task 側のは無視 (おぉ?!) SPE 側の SchedRegister も不要。 | |
| 338 | |
| 339 get_segment だけでできる? | |
| 340 | |
| 341 PPE側で、 | |
| 342 | |
| 343 TaskRegister(Task ID, 0 file, entry symbol); // PPE fixed task | |
| 344 SpeTaskRegister(Task ID, object file, entry symbol); // SPE dynamic task | |
| 345 SpeTaskRegister(Task ID, 0, entry symbol); // SPE fixed task | |
| 346 | |
| 347 を指定することになる。 PPE 側は自動的に登録される ( -cpu 0 があるから ) | |
| 348 task_list と spu_task_list が同時に初期化される | |
| 349 | |
| 350 object file は、.a でも良い。(良いの?) embed しても良い。 | |
| 351 | |
| 352 と言うことは、今までのように run を使い回しっ手のいうは許されないってこと? | |
| 353 その方が良いでしょう。変更大きいけど。 | |
| 354 | |
| 355 SPE側に固定する Task はどうするの? | |
| 356 | |
| 966 | 357 2010-8-7 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 358 | |
| 1052 | 359 get_segmentのinlineは、その場に static に置いて、default のものを置いておく。 |
| 360 size のcheckはしない。 | |
| 361 | |
| 362 MemList は廃止。QueueInfo に。 | |
| 363 | |
| 364 Data 領域は、2^n 管理で、move/compaction を行なう。(が、今は書かない) | |
| 365 | |
| 366 とりあえず、SPUのobject管理だが... | |
| 966 | 367 |
| 368 2010-8-6 Shinji KONO <kono@ie.u-ryukyu.ac.jp> | |
| 369 | |
| 1052 | 370 Bulk, Simple, basic は一つにするべきだよな。many_task は、sort と言う名前に変えるべき。 |
| 966 | 371 |
|
940
e01b551f25d6
unknown dead lock still...
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
932
diff
changeset
|
372 2010-7-31 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
e01b551f25d6
unknown dead lock still...
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
932
diff
changeset
|
373 |
| 1052 | 374 なんと、simple task を SchedTaskManager 経由で作ると、 |
| 375 PPE task しか作れなくなっていたらしい。それは遅いよ。 | |
| 376 SchedTaskManagerのtask managerがFifoManagerだったのが | |
| 377 原因。CellTaskManager を使う時には、FifoManagerは消せる? | |
| 378 | |
| 379 その代わり、dead lock が起きる。待ち先のtaskが消滅する場合が | |
| 380 あるらしい。 | |
| 381 | |
| 382 やっぱり、既に終了した task に対して wait for してしまうのが | |
| 383 まずいらしい。自分で HTask をfree してやれば良いわけだが.. | |
|
941
fc6cfaae6de7
add no_auto_free flag on HTask
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
940
diff
changeset
|
384 |
| 924 | 385 2010-7-30 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 386 | |
| 1052 | 387 TASK_LIST_MAIL でない方が高速なみたい |
| 388 sort (many_task) が、とっても遅くなっている | |
| 924 | 389 |
|
918
e66a08b5cd83
add loadelf in tmp/old.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
893
diff
changeset
|
390 2010-7-24 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
e66a08b5cd83
add loadelf in tmp/old.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
893
diff
changeset
|
391 |
| 1052 | 392 やっぱり、load module のlinkの解決はやらないといけないので、 |
| 393 無理に、SchedTaskのAPI全部を virtual にする必要はないらしい。 | |
| 394 spu-gcc spe/ChainCal.o -Wl,-R,spe-main -o tmp.o | |
| 395 と言う形で、link してやれば良い。(ただし、必要なものが参照されている場合) | |
|
918
e66a08b5cd83
add loadelf in tmp/old.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
893
diff
changeset
|
396 |
|
893
2faa1f62d925
fix SimpleTask alignment
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
888
diff
changeset
|
397 2010-7-16 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
2faa1f62d925
fix SimpleTask alignment
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
888
diff
changeset
|
398 |
| 1052 | 399 SimpleTask のsizeを16の倍数に。そうしないと、Taskのaligmentが16に |
| 400 ならないので、gcc -O9 で破綻する。 | |
|
893
2faa1f62d925
fix SimpleTask alignment
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
888
diff
changeset
|
401 |
|
888
b6c45005a3bc
call savedTask->write() in TaskArray finish.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
833
diff
changeset
|
402 2010-7-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
b6c45005a3bc
call savedTask->write() in TaskArray finish.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
833
diff
changeset
|
403 |
| 1052 | 404 SchedTaskArray::exec の run の値が最適化で、おかしくなるのは、gcc のbugらしい。 |
| 405 SimpleTask の finish mail が返るのが早すぎる。write を呼ぶのが正しい。 | |
| 406 cur_index++ してしまうと、task1/task2 のcur_indexが同じになってしまう。 | |
|
888
b6c45005a3bc
call savedTask->write() in TaskArray finish.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
833
diff
changeset
|
407 |
| 830 | 408 2010-5-25 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 409 | |
| 1052 | 410 PPE側のpost_funcやtaskを実行している時にもSPEからのメールは読んでしまう |
| 411 のが望ましい。読んで、とりあえずfifoに入れておく。その場で処理しても良いが、 | |
| 412 check_task_list_finishとかが再帰的に呼びされるのがやっかい。 | |
| 413 | |
| 414 Task 実行ループは Scheduler にpoling routineを登録するのが良さそう。 | |
| 415 post_func は、SchedTask 経由で poling すれば良い。 | |
|
833
577bde5d0cec
poling (may recurse..)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
830
diff
changeset
|
416 |
| 806 | 417 2010-5-22 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 418 | |
| 1052 | 419 CpuThread を作るなら、create_task は、manager にメールで教えないとだめ。 |
| 420 CpuManager みたいなものを用意しないとダメか。 | |
| 421 | |
| 422 HTask から、waitfor/create_task とかは、TaskManager を呼んでいる。 | |
| 423 そのたびに CAS (Check and set) するのはばかげているよな〜 | |
| 424 TaskManager にメールで送る方が良いのではないか。 | |
| 425 | |
| 426 wait_for する Task が既に終了していると、存在しないTaskあるいは、 | |
| 427 別な Task を wait_for する場合がある。いわゆるゾンビだけど、これは | |
| 428 どうしよう? 生きているかどうかを識別するように id を付けるか? | |
| 429 | |
| 430 どうも、TaskManager.{h,cc} は要らないっぽい。TMmain に渡されるのも | |
| 431 SchedTask である方が自然。 | |
| 432 | |
| 433 TaskListInfo は循環リストなので、SPU/PPU scheduler に渡す前に、 | |
| 434 getLast()->next = 0 する必要がある。freeAll() する前に、直さないと | |
| 435 だめ。getList() みたいなものを用意しても良いが... | |
| 436 | |
| 437 Scheduler のconnector(DMA) / Memory 関連は Scheduler.{h,cc} から | |
| 438 追い出すべき。connector/memory とかを SchedTask に持たせれば良い。 | |
| 439 そうすると、API追加でScheduelr.{h,cc} / TaskManagerImple とかを修正する | |
| 440 必要がなくなる。 | |
| 816 | 441 |
| 796 | 442 2010-5-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 443 | |
| 1052 | 444 speTaskList_bg は追放するべきだと思われる。(done) |
| 445 | |
| 446 PPE task はTaskList をすべて実行するまで戻って来ない。 | |
| 447 なので、spe のmail checkが疎かになっている。 | |
| 448 PPE task の実行途中で SPEのmail checkを行なうべき。 | |
| 449 | |
| 450 Fifo/Cell TaskManagerImpl は統一できるのではないか? (done) | |
| 451 | |
| 452 SchedTask は今は各Taskのselfを返しているがTaskListにするべき | |
| 453 spe からのメールはTaskListが空になった時で良い。早めに、 | |
| 454 | |
| 455 PPE Taskを早めに起動する義理はある? あるかも知れない。Quick Reply Property。 | |
| 456 | |
| 457 TaskList もDataSegement化するべきだと思われる。(done) | |
| 458 | |
| 459 Scheduler::task_list もDataSegment化して、メインメモリ上に置く。 | |
| 796 | 460 |
| 789 | 461 2010-4-28 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 462 | |
| 1052 | 463 SchedTaskBase のみにインスタンス変数を書かせて、 |
| 464 SchedTask*.h には method のみを書かせる。 | |
| 465 そうすると、デバッグが楽だし、object のallocateも楽。(done) | |
| 466 | |
| 467 HTask(list) -> TaskList(array) -> SchedTask | |
| 468 | |
| 469 というcopyだが、SchedTask で最初から作る方が良いのかも。 | |
| 470 それを DataSegment で共有する。 | |
| 471 | |
| 472 SimpleTask のMailを、 | |
| 473 if (mail_is_not_full) send_mail() ; | |
| 474 else if (queue is not full) enqueuue() ; | |
| 475 else wait_mail(); | |
| 476 ってな感じに出来ないの? | |
| 477 | |
| 478 Multi thread にすると、PPEのmail loop が暴走する可能性がある。 | |
| 479 このあたりなんか方法があるはずだが... | |
| 789 | 480 |
|
786
043c98537bc5
fix early free of TaskArray, add SchedTaskArrayNop stage.
yutaka@localhost.localdomain
parents:
721
diff
changeset
|
481 2010-4-24 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
043c98537bc5
fix early free of TaskArray, add SchedTaskArrayNop stage.
yutaka@localhost.localdomain
parents:
721
diff
changeset
|
482 |
| 1052 | 483 write T3 T2 T1 TL TA0 TA1 |
| 484 exec T2 T1 TL TA0 TA1 TA2 | |
| 485 read T1 TL TA TA1 TA2 T2 | |
| 486 next T1 TL TA TA1 TA2* T2 | |
| 487 | |
| 488 *のところで終了mailが出てTaskArrayのデータがfreeされてしまうので、よくない | |
| 489 そうならないように、一段TAN(SchedTaskArrayNop)を挟む。 | |
| 490 | |
| 491 write T3 T2 T1 TL TA0 TA1 TA2 TAN% | |
| 492 exec T2 T1 TL TA0 TA1 TA2 TAN T2 | |
| 493 read T1 TL TA TA1 TA2 TAN T2 T3 | |
| 494 next T1 TL TA TA1 TA2 TAN T2 T3 | |
| 495 | |
| 496 %のところで終了mailを送る。T2のreadのところで、TaskArrayのデータはreadbuff上にあるので | |
| 497 破壊されてしまう。なので、savedTask->task->self の値はTANにコピーして持っていく必要がある | |
|
786
043c98537bc5
fix early free of TaskArray, add SchedTaskArrayNop stage.
yutaka@localhost.localdomain
parents:
721
diff
changeset
|
498 |
| 718 | 499 2009-12-19 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 500 | |
| 1052 | 501 そうか、TaskList->next は、SPE 側で自分で呼び出しているわけね。 |
| 502 と言うことは、schdule(list) が終るまでは、mail check に戻って | |
| 503 こない... それだと、ちょっとまずいね。 | |
| 504 | |
| 505 となると、TaskList のfree(clear)のtimingは? schdule から抜けた | |
| 506 時と言うことになるわけだけど。 | |
| 507 | |
| 508 waitQueue は、実は不要。しかし、終了条件、dead lock detection には | |
| 509 必要らしい。 | |
| 721 | 510 |
|
717
dfb3518d8694
TaskList load timing...
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
708
diff
changeset
|
511 2009-12-16 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
dfb3518d8694
TaskList load timing...
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
708
diff
changeset
|
512 |
| 1052 | 513 CellTaskManagerのTaskList_bg は変だよ。TaskList 自体が |
| 514 queue なんだから、トップ二つを特別扱いしているだけでしょう。 | |
| 515 | |
| 516 TaskList をread()しているのと同時にnext()されてしまうので、 | |
| 517 next()の中で、TaskList の中身に触るのは良くない。SchedTask | |
| 518 は微妙に大丈夫らしい。TLのdma waitは、write になっていた。 | |
| 519 | |
| 520 TaskArray/TaskArray1 は、TAの中身をnext()で判断しているので、 | |
| 521 これはただしくない。TaskListLoad を間にはさむ手もあるが... | |
| 522 | |
| 523 write T3 T2 T1 TL TA0 ! TL の dma wait | |
| 524 exec T2 T1 TL! TA0 TA1 | |
| 525 read T1 TL* TA TA1 TA2 * TL の dma start | |
| 526 next T1 TL% TA TA1 TA2 % TAの作成判断 | |
| 527 | |
| 528 TaskListLoad をはさむ、安全だけど遅い方法 | |
| 529 | |
| 530 write T3 T2 T1 TLL TL | |
| 531 exec T2 T1 TLL! TL TA0 | |
| 532 read T1 TLL*TL TA0 TA1 | |
| 533 next T1 TLL TL% TA0 TA1 | |
| 534 | |
| 535 なんだけど、pointer の下位ビットで送ると、前者で実行できる。 | |
| 536 next で、TaskList のloadを始めてしまうという手もあるな... | |
| 537 | |
| 538 write T3 T2 T1 TL TA0 ! TL の dma wait | |
| 539 exec T2 T1 TL TA0 TA1 | |
| 540 read T1 TL! TA TA1 TA2 * TL の dma start | |
| 541 next T1* TL% TA TA1 TA2 | |
| 542 | |
| 543 こっっちかな... | |
|
717
dfb3518d8694
TaskList load timing...
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
708
diff
changeset
|
544 |
| 708 | 545 2009-12-15 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 546 | |
| 1052 | 547 SimpleTask の実装が出来たので、TaskArray からは、 |
| 548 PPU側に詳細な情報を返せる。と言うことは、SPU側から | |
| 549 PPU Task を投入出来る。実装すればだけど。 | |
| 550 | |
| 551 Task 側から書き出し情報を設定するAPIが必要。 | |
| 552 マニュアルも書くか。 | |
| 553 | |
| 554 Down cast をすべてなくしたい。Sched*.cc からは取れました。 | |
| 555 | |
| 556 まだ、いらないものが結構あるらしい... | |
| 708 | 557 |
| 703 | 558 2009-12-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 559 | |
| 1052 | 560 ようやっと動きました。SIMPLE_TASK でないのとの互換性 |
| 561 を維持するべきか? 頑張れば出来ると思うけど... | |
| 562 | |
| 563 方法は二つ。TaskList に無理矢理 Task を詰め込むか、 | |
| 564 今までのHTaskを、TaskArray に読み変えるか。前者は変更が | |
| 565 多い。後者は、wait_for が微妙。 | |
| 566 | |
| 567 前者で実装しました。そのうち落すかも。エラーチェックと、 | |
| 568 エラー処理関数が必要。コメントを書かないと。 | |
| 708 | 569 |
| 695 | 570 2009-12-12 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 571 | |
| 1052 | 572 SchedTask::next で、TaskArray を認識して、そこで、 |
| 573 SchedTaskArrayLoad を作る。次のSchedTask を用意して、 | |
| 574 SchedTaskArrayLoad にsavedSchedTaskとして引き渡す。 | |
| 575 | |
| 576 SchedTaskArrayLoad::read は、TaskArray をload する。 | |
| 577 SchedTaskArrayLoad::next は、SchedTaskArray を返す。 | |
| 578 この時に、saveedSchedTask を引き継ぐ。 | |
| 579 write/exec は何もしない。(これで、pipe line を空ける) | |
| 580 | |
| 581 SchedTaskArray::read は、List DMA をload する。 | |
| 582 SchedTaskArrayLoad::next は、TaskArray 上のTaskを返す。 | |
| 583 exec/write は、List DMA 対応で動作する。 | |
| 584 もうない場合には、SchedTaskArrayLoad から伝えられた | |
| 585 saveされた SchedTask を返す。mail も送る。 | |
| 695 | 586 |
| 690 | 587 2009-12-7 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 588 | |
| 1052 | 589 pipeline stageは、loop local だから、instance 変数である必 |
| 590 要はない。途中で中断することはない。これを一時変数にして、 | |
| 591 再帰的にpipeline stage を呼び出せば良いらしい。 | |
| 592 | |
| 593 pipeline stage のtask1に引数で new SchedTaskList を渡すと、 | |
| 594 run()でtask1 = new SchedNop() するよりループ二回ぐらい高速 | |
| 595 になるらしい。が、おそらく、ほとんど影響はない。 | |
| 596 | |
| 597 pipelineで既に走っている次のTaskのreadを停める必要があるら | |
| 598 しい。前もってNopを入れて置く方法もあるが、TaskListの境界が | |
| 599 問題になる。停めないとパイプラインバッファを新たに取る必要 | |
| 600 があり連鎖的にはまる。 | |
| 601 | |
| 602 writeしている奴もいるしな。スケジューラは一段しかネストしな | |
| 603 いから新しくバッファ取るか? いや、やっぱり許されないか。い | |
| 604 や、取るか。うーん、悩ましい。どうせ、Task list は確保しな | |
| 605 いとだめだから… 再帰しないで、もとのスケジューラで動かした | |
| 606 い | |
| 607 | |
| 608 そのためには、既に Pipeline に入っているTaskが邪魔か。２つTask | |
| 609 を投入して、間に TaskList read が入ってもなんとかなるように | |
| 610 工夫するのが良いっぽい | |
| 611 | |
| 612 なんか、Renew Task の道を歩んでいる気もするが... | |
| 693 | 613 |
| 683 | 614 2009-12-6 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 615 | |
| 1052 | 616 やっぱり、Graphical なprofileが欲しいかな。どのDMA/Taskに時間がかかっている |
| 617 かが見えるようなものが。profile で、メインメモリにlogを書き出すようなもの | |
| 618 が必要。deubg 用のデータ書き出しツールがいるな。 | |
| 619 | |
| 620 log header | |
| 621 command(16) cpu-id(16) event(32) time(64) | |
| 622 struct debug_log { | |
| 623 uint16 command; | |
| 624 uint16 cpu-id; | |
| 625 uint32 event; | |
| 626 uint32 time; | |
| 627 } | |
| 628 ぐらい? get_segment 使うべきか。連続領域に使える get_segement があると | |
| 629 良いわけね。write とも言うが。 | |
| 630 | |
| 631 sort で、memcpy しているのは変。read/write buffer をflipしてやると | |
| 632 良い。両方とも握っているんだから問題ない。ただし、read/write buffer | |
| 633 の大きさは等しい必要がある。SchedTask->flip_read_write_buffer(); か? | |
| 634 sort ちゃんとは動いているんだよ。 | |
| 635 | |
| 636 word_count_test の稼働率が10%なのはひどい。word_count の方だと偏りが | |
| 637 あって、一部が50%になるが10%ぐらい。DMA待ちではなくて、メール待ちに | |
| 638 なっている。PPUネックになっているっぽい。 | |
| 639 | |
| 640 TaskArray は、SchedTask を拡張して処理する。next で、次のTaskを | |
| 641 用意する感じか。inData/outData の処理も。 | |
| 684 | 642 |
| 673 | 643 2009-12-5 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 644 | |
| 1052 | 645 なんかなぁ。一つの機能を付け加えようとすると、 |
| 646 | |
| 647 TaskManager/Cell/CellTaskManagerImpl.cc | |
| 648 TaskManager/Cell/CellTaskManagerImpl.h TaskManager/Cell/spe/CellDmaManager.cc | |
| 649 TaskManager/Cell/spe/CellDmaManager.h TaskManager/Cell/spe/ShowTime.cc TaskManager/Cell/spe/ShowTime.h | |
| 650 TaskManager/Cell/spe/SpeTaskManagerImpl.cc TaskManager/Cell/spe/SpeTaskManagerImpl.h | |
| 651 TaskManager/Cell/spe/main.cc TaskManager/Fifo/FifoTaskManagerImpl.cc | |
| 652 TaskManager/Fifo/FifoTaskManagerImpl.h TaskManager/Makefile.cell TaskManager/kernel/ppe/TaskManager.h | |
| 653 TaskManager/kernel/ppe/TaskManagerImpl.h TaskManager/kernel/schedule/DmaManager.h | |
| 654 TaskManager/kernel/schedule/SchedTask.cc TaskManager/kernel/schedule/SchedTask.h | |
| 655 TaskManager/kernel/schedule/Scheduler.h TaskManager/kernel/sys_task/SysTasks.h | |
| 656 example/word_count_test/main.cc | |
| 657 | |
| 658 こんなにファイルをいじらないと出来ない。それって、全然、ダメじゃん。 | |
| 659 | |
| 660 なんでかなぁ。 | |
| 673 | 661 SchedTask -> Scheduler -> Connector |
| 662 TaskManagerImpl -> {CellTaskManager,FifoTaskManager/SpeTaskManager} | |
| 1052 | 663 を全部、いじる羽目になる。 |
| 664 SchedTask から system call するより、Task を定義して、 | |
| 665 それを呼び出すって方がましかも。 | |
| 673 | 666 |
| 667 | |
| 659 | 668 2009-11-23 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 1052 | 669 list.bound は廃止。list element から計算可能。 |
| 659 | 670 |
|
640
ecf056ddd21a
SimpeTask on Cell worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
638
diff
changeset
|
671 2009-11-20 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
ecf056ddd21a
SimpeTask on Cell worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
638
diff
changeset
|
672 |
| 1052 | 673 mail_sendQueue の実装がだめ。こういう実装をすると、queue の |
| 674 正しさを関数の中に閉じ込められない。なんか、無限リストにな | |
| 675 っているらしい。参照が、渡り歩いているどこかの場所でダメに | |
| 676 なっているらしい。 | |
| 677 | |
| 678 実際、mail_sendQueue は、free list に置き換わってしまう。 | |
| 679 これまで、これがおかしくならなかった理由は不明。 | |
| 680 | |
| 681 connector に外から手を入れないで、ちゃんとfunction callするべし。 | |
| 682 | |
| 683 わかりました。 | |
| 684 if (list) { | |
| 685 ... | |
| 686 mainScheduler->send_mailList(in_mail_list); | |
| 687 } | |
| 688 out_mail_list = mainScheduler->recv_mailList(); | |
| 689 | |
| 690 としてしまったが、recv_mailList() でなく、send_mailList で、 | |
| 691 mail_sendQueue をクリアしていたので、 | |
| 692 } else { | |
| 693 mainScheduler->send_mailList(in_mail_list); | |
| 694 } | |
| 695 とする必要があったらしい。if (list) を入れたせいで、こうなった。 | |
| 696 でも、当然、recv_mailList() で clear するべき。atomicity の意味でも。 | |
| 697 なので、send_mailList() での clear は必要ない。 | |
| 646 | 698 |
|
640
ecf056ddd21a
SimpeTask on Cell worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
638
diff
changeset
|
699 |
| 637 | 700 2009-11-19 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 701 | |
| 1052 | 702 finish_task を全員が待つ設定で、finish_task を終了判定に |
| 703 使っている。それだと、すべてのtaskが、finish_task のwait queue | |
| 704 を*必ず*触りにいってしまう。 | |
| 705 | |
| 706 finish_task への待ちを取り除くと、CellTaskManagerImpl::run() | |
| 707 が、 | |
| 646 | 708 do { |
| 709 ppeMail = ppeManager->schedule(ppeTaskList); | |
| 710 cont: | |
| 711 ppeTaskList = mail_check(ppeMail); | |
| 712 } while (ppeTaskList); | |
| 1052 | 713 とかやっているので、ここで抜けてしまう。 |
| 714 | |
| 715 要するに、SPUの状態を見て、running がなくなるのを調べるべき | |
| 716 なんだが、SpeTheads は「一つしかない」らしい。spe_running | |
| 717 で、走っているものがあるかどうか見るか? | |
| 718 | |
| 719 Cell だと、MainScheduler と FifoScheduler の二種類の | |
| 720 スケジューラがあるのか。 | |
| 646 | 721 |
| 722 MainScheduler --- task list -----> FifoScheduler | |
| 723 MainScheduler <-- finish task ---- FifoScheduler | |
| 724 | |
| 1052 | 725 というわけね。 |
| 637 | 726 |
|
631
30dd8a3deb4a
Cell 64 bit tried, but not yet worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
625
diff
changeset
|
727 2009-11-15 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
30dd8a3deb4a
Cell 64 bit tried, but not yet worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
625
diff
changeset
|
728 |
| 1052 | 729 List DMAって、32bit address を使っているらしい。それは、ちょっと |
| 730 ひどいなぁ。 | |
|
631
30dd8a3deb4a
Cell 64 bit tried, but not yet worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
625
diff
changeset
|
731 |
|
625
94d82f2c842f
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
732 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
94d82f2c842f
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
733 |
| 1052 | 734 やっぱり、TaskList の存在が許せない。あったとしても不定長でしょう。 |
| 735 無駄なコピーが多すぎる。 | |
|
625
94d82f2c842f
64bit mode worked on Mac OS X.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
619
diff
changeset
|
736 |
| 619 | 737 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 738 | |
| 1052 | 739 Scheduler / TaskManger / TaskManagerImpl の区別が不明 |
| 740 HTask は、TaskManagerImpl を持ってる。 | |
| 741 | |
| 742 Scheduler は SchedTask から直接見えないはずだが、SchedTask は、 | |
| 743 Scheduler は知っているが、TaskManager は知らない。これがかなりの | |
| 744 混乱を生んでいる。 | |
| 745 | |
| 746 SPU上では、TaskManager が存在しないのが原因らしいが、allcoate とかは、 | |
| 747 TaskManager が行うはず。なので、SPU上にもTaskManagerがある方が自然。 | |
| 748 | |
| 749 SchedTask が自分自身で scheduling してしまっているので、Scheduler | |
| 750 には、ほとんど仕事がない。なので、大半の処理を scheduler -> manager | |
| 751 経由で行うことになる。 | |
| 619 | 752 |
|
615
184d6d3f0cd9
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
753 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
184d6d3f0cd9
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
754 |
| 1052 | 755 要するに、SPE task 側から addOutData できればよい。 |
| 756 でも、別に、PPE側から計算してもよいはずだけどね。 | |
| 757 そうすれば、renew task は取り外せる。 | |
|
615
184d6d3f0cd9
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
758 |
|
184d6d3f0cd9
remove uncessary Task Name definision
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
567
diff
changeset
|
759 SchedDefineTask1(DrawSpanEnd,draw_span_end); |
| 1052 | 760 で、名前を指定させておいて、さらに、 |
| 761 SchedExternTask(DrawSpanEnd); | |
| 762 SchedRegisterTask(TASK_DRAW_SPAN_END, DrawSpanEnd); | |
| 763 で、新しく名前を要求するのって、なんとかならんの? 読みづらいんだよ。 | |
| 764 DrawSpanEnd を、そのまま使ってもよさそうだけど? | |
| 765 | |
| 766 せっかく、renew task を外したのに、HD crash で失ってしまいました。 | |
| 767 | |
| 768 add_param が順序を持っているのは見づらい。数字で指定する方が合理的。 | |
|
616
350b9b8c985f
First addOutput rendering try failed.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
615
diff
changeset
|
769 |
| 538 | 770 2009-10-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 771 | |
| 1052 | 772 単純な、rbuf, wbuf + write return size の task のAPI |
| 773 List DMA の API | |
| 774 投入 cpu 別の spawn method | |
| 775 Redering 時の内部からの DMA への直接アクセスへの禁止等など | |
| 776 | |
| 777 set_post で登録する関数も、task のrun関数と同じ型にした方が便利そう。 | |
| 778 | |
| 779 SPU側でも配列(TaskList)ではなく、TaskQueue で管理すれば、 | |
| 780 renew task は簡単に実装できる。 | |
| 781 | |
| 782 SchedTask の renew かそうでないかの区別は全部なくす。ex_init とかは、 | |
| 783 なくなるはず。その代わり TaskQueue で管理する。 | |
| 784 | |
| 785 TaskList に inListData/outListData が入っているのは、やはりおかしい。 | |
| 786 もっとコンパクトであるべき。 | |
| 787 | |
| 788 TaskList は、こまめに終了をPPE側へ知らせるのではなく、TaskListの | |
| 789 書き換えで知らせる方が良い。 | |
| 790 | |
| 791 SPUからPPUへ、create task 出来た方が良い。それはTaskList の書き出し | |
| 792 で行なう。 | |
| 538 | 793 |
| 503 | 794 2009-10-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 795 | |
| 1052 | 796 ようやっと直せました。inListData/outListData は別に転送しないで、 |
| 797 一緒に転送してしまった方が良い。どうせ、いつも転送しているのだから。 | |
| 798 | |
| 799 word_count が fifo の方が高速なのは、どうにかしてください。 | |
| 800 | |
| 801 Renew Task の addInData は、メインメモリからDMAするので正しいらしい。 | |
| 802 直し方を間違えた。 | |
| 803 | |
| 804 Task をmemcpyして、TaskList に入れているが、List DMA に直すべき。 | |
| 805 Simple Task を常に起動して、List DMA task は、その中で、Renew Task | |
| 806 として起動するのが良いのでは? そうすれば、Task Load 自体を Task に | |
| 807 出来る。 | |
| 808 | |
| 809 Renew Task の実行順序が filo になっている。このあたり変なので、 | |
| 810 修正するべきでしょう。Renew用の TaskList を持てば良いんじゃないか? | |
| 811 task->self の ad-hoc な使い方が泣ける。ひどすぎます。 | |
| 503 | 812 |
| 489 | 813 2009-10-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 814 | |
| 1052 | 815 Task 内の create_task は、SchedTask に対してで、 |
| 816 PPE 上では、Manager に対してだよね。だから、出来る | |
| 817 ことがかなり異なる。これは、まずいだろ? | |
| 818 | |
| 819 特に、PPE task に明示的に manager を渡すってのは、 | |
| 820 とっても変。 | |
| 821 | |
| 822 Renew Task の特別扱いが、いろいろ歪めているんだが、 | |
| 823 view.cc で使っているので落せない。 | |
| 489 | 824 |
|
481
f9ffcffb6d09
Double linked list modification done (tested on Mac OS X)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
468
diff
changeset
|
825 2009-10-05 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
f9ffcffb6d09
Double linked list modification done (tested on Mac OS X)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
468
diff
changeset
|
826 |
| 1052 | 827 TaskQueue のfree list の管理はシステムで一つであるべき。 |
| 828 TaskQueue は double linked list が当然らしい。 | |
|
481
f9ffcffb6d09
Double linked list modification done (tested on Mac OS X)
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
468
diff
changeset
|
829 |
|
468
796f72cb21d9
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
830 2009-10-02 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|
796f72cb21d9
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
831 |
| 1052 | 832 DrawSpan で、~DrawSpan() で、allocate したデータを DMA_WAIT |
| 833 して、free しているが、これは、抽象化違反。Task で明示的に | |
| 834 DMAするのは禁止。Task 内で、add_outData 出来れば良い。 | |
| 835 | |
| 836 renew が正しいような気がするが... | |
| 837 | |
| 838 Task 内で大域変数は使えない。なので、smanager からallocateする | |
| 839 必要がある。Task の解放のタイミングではなくて、パイプラインの | |
| 840 タイミングでDMA waitとfreeを行なう必要がある。DrawSpan の場合は、 | |
| 841 add_outData で良いが、内部で allocate/free は行なう必要がある。 | |
| 842 put_segement がパイプライン動作するべきなのか? | |
| 843 | |
| 844 固定のDMA tagが邪魔。 | |
| 845 | |
| 846 DrawSpan は全般的にダメだな〜 | |
| 847 | |
| 848 でも、その変更は大きいので、とりあえず動くようにしたい。 | |
| 849 | |
| 850 memset 0 は、7.7.3 SL1 Data Cache Range Set to Zero コマンド | |
| 851 つかうべき。SPE側でやっても良い。でも、本来は全面埋まるのが | |
| 852 普通なのでどうでも良いけど。 | |
|
468
796f72cb21d9
test_nogl on Mac OS X worked.
Shinji KONO <kono@ie.u-ryukyu.ac.jp>
parents:
400
diff
changeset
|
853 |
| 386 | 854 2009-08-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 855 | |
| 1052 | 856 で、MemList/MemHash が TaskManager 側に移ったので、 |
| 857 これで、code の management を書くことが出来る。 | |
| 858 そうすれば、SPEのメモリの限界をほんと気にする必要がなくなるはず。 | |
| 859 | |
| 860 その前に、get_segment の例題を直さないと。 | |
| 861 | |
| 862 DrawSpanRnew/reboot は使ってないらしい。 | |
| 863 | |
| 864 Tree は、配列にしないでlinkをSPE側からたどるようになっている。 | |
| 865 それは良いのだが、Task 側で dma_wait するような実装は望ましくない。 | |
| 866 この部分も書き直す必要がある。list 構造の SPE上の Iterator を | |
| 867 実装すれば良い。 | |
| 868 | |
| 869 memory 関係のコードが scheduler の下にあるのは面白くない。 | |
| 870 | |
| 871 Scheduler で実装(__scheduler)に移譲している部分は、headerに | |
| 872 移した方が良い。 | |
| 390 | 873 |
| 874 2009-08-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> | |
| 875 | |
| 1052 | 876 うーん、get_segemnt で、dma_wait のtagをなんとかする |
| 877 必要があるらしい。get_tag() でなんとかなるけど、 | |
| 878 他のtag との関係があるかな。 | |
| 879 | |
| 880 完全に見えなくするべきでしょうけど... 今はいい。 | |
| 386 | 881 |
| 381 | 882 2009-08-01 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 883 | |
| 1052 | 884 MemList は動いたので、今度は TileHash を TaskManager 側に移動する |
| 885 必要がある。 | |
| 886 | |
| 887 その後、コードのLRUを書けば、Cerium は一通り出来上がり。 | |
| 888 | |
| 889 TaskManager と Scheduler の関係が一貫してない。複雑すぎる。 | |
| 381 | 890 |
| 891 | |
| 363 | 892 2009-07-24 Kaito TAGANO <tkaito@cr.ie.u-ryukyu.ac.jp> |
| 390 | 893 |
| 363 | 894 長さ別の freeList と単一の HashTable で管理する |
| 895 TileList を廃止 | |
| 896 class MemorySegment { | |
| 897 MemorySegment *next; | |
| 898 MemorySegment *prev; | |
| 899 uint64 size; | |
| 900 uint64 address; | |
| 901 uint64 dummy; | |
| 902 // uint32 data[0]; | |
| 903 } | |
| 904 | |
| 905 class MemList { | |
| 1052 | 906 MemorySegment* first; |
| 363 | 907 MemorySegment* last; |
| 908 | |
| 909 MemList* createMemList(uint32 size, uint32 count); | |
| 910 void addFirst(MemorySegment* e); | |
| 911 void addLast(MemorySegment* e); | |
| 912 MemorySegment* getFirst(); | |
| 913 MemorySegment* getLast(); | |
| 914 boolean remove(MemorySegment* e); | |
| 915 void moveToFirst(MemorySegment* e); // or use(); | |
| 916 } | |
| 917 | |
| 918 サイズ毎に freelist と activelist を持って、これを malloc free | |
| 919 として使う。 | |
| 920 これのテストルーチンを書き終わったら、Tapestry をこれで書き直す | |
| 921 LRU は使うたびに以下を呼び出す | |
| 922 | |
| 923 void use(MemorySegment* e, MemList* active) { | |
| 924 active.remove(e); | |
| 925 active.addFirst(e); | |
| 926 } | |
| 927 | |
| 928 | |
| 354 | 929 2009-07-15 Yusuke KOBAYASHI <koba@cr.ie.u-ryukyu.ac.jp> |
| 930 | |
| 931 PPU からMainMemory にResource を Access する API | |
| 932 長さ別の freeList と単一の HashTable で管理する | |
| 933 | |
| 386 | 934 読みだしAPI。set_rgb に相当。 |
| 935 uint32 segment_id = smanager->get_segment(memaddr addr, *MemList m) | |
| 354 | 936 id は hash値に相当。 |
| 386 | 937 addr で指定された PPU の Address が Hash にあるかどうか調べる。 |
| 938 無ければ dma_load する。そして指定された id を返す。 | |
| 939 | |
| 400 | 940 確保 API。set_rgb に相当。読み出さないで、hash entry だけ確保する。put しかしない部分用 |
| 941 uint32 segment_id = smanager->get_null_segment(memaddr addr, *MemList m) | |
| 942 id は hash値に相当。 | |
| 943 | |
| 386 | 944 書き出しAPI、読みだしていること前提。 |
| 354 | 945 smanager->put_segment(wait_id); |
| 386 | 946 |
| 947 MemorySegment* smanager->wait_segment(uint32 segment_id) | |
| 948 id で指定された PPU の segment の copy の Address を返す。 | |
| 949 必要があれば dma_wait を行う。書き出しも待ち合わせる。 | |
| 354 | 950 |
| 307 | 951 2009-06-8 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 952 | |
| 953 SchedTask/SchedTaskImpl の分離はあんまり意味がなかった。 | |
| 954 SchedTaskBase が既にあるし。 | |
| 955 とりあえず、__list とかは、private にしただけ。 | |
| 956 ScheTaskImple を作っても、継承してprivateにすると、 | |
| 957 warning は出るが、 User Task space の名前空間は結局汚れてしまう。 | |
| 958 | |
| 959 delegate するべきだと思うが、SchedTaskBase でないと、 | |
| 960 動かないらしい。それだと、indirect が増えるので、ちょっといや。 | |
| 961 | |
| 279 | 962 2009-06-4 Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
| 963 | |
| 964 set_symbol は、もういらないよね? | |
| 965 | |
| 966 list dma 中心の実装にして、もっと細かく read/exec/write | |
| 967 した方が良いかも。 | |
| 968 | |
| 969 post で、PPE task を渡せると良い。address は parameterとして送る | |
| 970 | |
| 276 | 971 2009-02-13 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> |
| 972 | |
| 973 * kernel/ppe/Random.cc (reset): fix | |
| 974 urandom -> random とどれも読めなかったら | |
| 975 gettimeofday() での時間から seed を求めるように | |
| 976 | |
| 977 2009-02-12 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 978 | |
| 979 * add: kernel/ppe/Random.cc | |
| 980 乱数生成クラス。 | |
| 981 ゲームだとユーザ使うでしょうきっと。 | |
| 982 一応 /dev/random から seed 取る様にしてます | |
| 983 | |
| 984 2009-02-04 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 985 | |
| 986 * kernel/ppe/TaskManager.cc (TaskManager::allocate): rename | |
| 987 malloc -> allocate | |
| 988 | |
| 989 * kernel/main.cc (main): fix | |
| 990 cerium_main を呼ぶのではなく、TMmain という名前にしました。 | |
| 991 ちょっと SDLmain をパクった感じで。 | |
| 992 まあ TaskManager の main で cerium_* って名前は微妙に変だからね。 | |
| 993 | |
| 994 * kernel/ppe/TaskManager.cc (TaskManager::set_TMend): add | |
| 995 cerium_main があるんだから、cerium_end があってもいいじゃない。 | |
| 996 もっと言うと、TaskManager に main を隠すって流れなんだけど | |
| 997 終了を検知できないのはちとやりづらいかなと。 | |
| 998 たとえば測定とか。Task の post_func とかでもやれないことはないけどね。 | |
| 999 というわけで、ユーザが、プログラム終了時に呼ばれる関数を設定できるように。 | |
| 1000 | |
| 1001 2009-01-20 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1002 | |
| 1003 * Cell/spe/SchedTask.cc (SchedTask::get_cpuid): add | |
| 1004 printf デバッグ時に、どの CPU かって知りたい時があるので。 | |
| 1005 | |
| 1006 PPE = 0 | |
| 1007 SPE = 0〜spu_num-1; | |
| 1008 | |
| 1009 PPE は 0 以外に分かりやすい数字がいいんだけどなー。SPE と被るし。 | |
| 1010 -1 とかはエラーっぽいから好かない。まあいいんだけど。 | |
| 1011 | |
| 1012 User Task では以下の様に使用します | |
| 1013 | |
| 1014 int cpuid = smanager->get_cpuid(); | |
| 1015 | |
| 1016 | |
| 1017 * Cell/SpeThreads.cc (SpeThreads::spe_thread_run): fix | |
| 1018 SPE_EXIT が出る時は正常終了だけど、これだと | |
| 1019 エラーでたようなメッセージに見えてしまう(俺がそう見えてしまった)ので | |
| 1020 ここは表示しなくてもいいかな。 | |
| 1021 | |
| 1022 * kernel/ppe/MailManager.cc (MailManager::destroy): fix | |
| 1023 無限ループになってた。この for() 間違ってるかな。 | |
| 1024 なんか TaskQueueInfo.cc とかでも、結局 while() に直してるし。 | |
| 1025 | |
| 1026 * kernel/ppe/TaskManager.cc (TaskManager::~TaskManager): add | |
| 1027 kernel/main.ccで | |
| 1028 | |
| 1029 delete manager; | |
| 1030 | |
| 1031 としているのに、TaskManagerImpl::~TaskManagerImpl が呼び出されず | |
| 1032 どうしてかなと思ったら、そもそも ~TaskManager が無かった。あほか | |
| 1033 | |
| 1034 2009-01-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1035 | |
| 1036 * all : fix | |
| 1037 Scheduler::curIndex_taskList を削除し、 | |
| 1038 SchedTask に持たせる様に変更。(SchedTask::__cur_index) | |
| 1039 それに伴い、SchedTask::__init__() も cur_index を入れる様に変更 | |
| 1040 | |
| 1041 2008-12-24 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1042 | |
| 1043 * kernel/schedule/SchedTask.cc (SchedTask::ex_init_renew) | |
| 1044 (SchedTask::ex_init_normal): add | |
| 1045 (SchedTask::__init__): fix | |
| 1046 | |
| 1047 init でも ex_init を使える様に。 | |
| 1048 あと、コンストラクタで渡していた引数を __init__() に渡す様にした。 | |
| 1049 コンストラクタの引数あると、継承する時にいちいち親クラスのも書かないと | |
| 1050 いけなかった。これ省略できないんだよな。めんどくさい。 | |
| 1051 | |
| 1052 例. | |
| 1053 class Hoge : public SchedTask { | |
| 1054 Hoge(int i) : Task(i) {} | |
| 1055 }; | |
| 1056 | |
| 1057 なので、今までは Scheduler.h に SchedConstructor ってマクロを書いて | |
| 1058 クラス名入れるだけで上の様な形になるようにしていた。 | |
| 1059 でも、例えば | |
| 1060 | |
| 1061 SchedTask -> Hoge -> Fuge っていうように Fuge ってタスクを | |
| 1062 作りたいとき、上のままだと SchedTask に引数渡してしまうのでだめ。 | |
| 1063 もうめんどくさいってことで、コンストラクタ全てデフォルトにして、 | |
| 1064 __init__() の引数に渡す様にしました。 | |
| 1065 | |
| 1066 (SchedTask::__set_renewFlag): add | |
| 1067 | |
| 1068 ここで、PPEで生成されたか(normal)、SPE で生成されたか(renew) の | |
| 1069 判定を行い、ex_xxx の設定もする | |
| 1070 | |
| 1071 (SchedTask::get_inputSize, SchedTask::get_outputSize): add | |
| 1072 | |
| 1073 アドレスだけじゃなく、そのサイズも取れた方がいいだろう | |
| 1074 | |
| 1075 | |
| 1076 2008-12-23 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1077 | |
| 1078 * Cell/spe/SchedTask.cc (SchedTask::get_outputAddr) | |
| 1079 (SchedTask::get_inputAddr): add | |
| 1080 | |
| 1081 in/out のデータだけじゃなく、そのアドレスも取れた方がいいだろう | |
| 1082 | |
| 1083 2008-12-22 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1084 | |
| 1085 * Cell/spe/SchedTask.cc (SchedTask::__init__, SchedTask::read) | |
| 1086 (SchedTask::exec, SchedTask::write): fix | |
| 1087 (SchedTask::ex_read_normal, SchedTask::ex_read_renew) | |
| 1088 (SchedTask::ex_exec_normal, SchedTask::ex_exec_renew) | |
| 1089 (SchedTask::ex_write_normal, SchedTask::ex_write_renew): add | |
| 1090 | |
| 1091 SPE 内で生成されたタスクは、PPE で生成されたものと違い | |
| 1092 | |
| 1093 - add->inData | |
| 1094 : PPE から DMA or SPE 内のものをそのまま使う | |
| 1095 - PPE にタスクが終了したことを知らせる | |
| 1096 : 生成されたタスクを待つ必要があるなら、その時点では送らない | |
| 1097 | |
| 1098 とか、まあいろいろ処理が違うわけです。 | |
| 1099 そして、タスク内生成タスクの判断をする | |
| 1100 | |
| 1101 __flag_renewTask ? 0 = PPE で生成 : 1 = SPE で生成 | |
| 1102 | |
| 1103 という変数がある。これでいくつか処理を分けてるんだけど、 | |
| 1104 今までは | |
| 1105 | |
| 1106 if (__flag_renewTask) { | |
| 1107 } else { | |
| 1108 } | |
| 1109 | |
| 1110 ってやってた。これではいかんという事で、 | |
| 1111 __init__() 内で、関数ポインタに、 | |
| 1112 | |
| 1113 ex_xxxx_normal: PPE で生成されたタスクに対する処理 | |
| 1114 ex_xxxx_renew: SPE で生成されたタスクに対する処理 | |
| 1115 | |
| 1116 と入れて、if 文無しでやってみた。 | |
| 1117 今は ex_write_xxx しか書いてないが、これからread/exec でも | |
| 1118 出てくると思うので、作っておいた | |
| 1119 | |
| 1120 | |
| 1121 2008-12-19 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1122 | |
| 1123 * Cell/spe/CellDmaManager.cc (CellDmaManager::dma_wait) | |
| 1124 (CellDmaManager::mail_write, CellDmaManager::mail_read): fix | |
| 1125 writech、readch の関数を、wrap (って言い方でおk？)された関数に変更。 | |
| 1126 最適化掛かってるっぽいし、長いよりはわかりやすいし。そのための wrap。 | |
| 1127 | |
| 1128 例: | |
| 1129 - before | |
| 1130 spu_readch(SPU_RdInMspu_readch(SPU_RdInMbox); | |
| 1131 - after | |
| 1132 spu_read_in_mbox(void); | |
| 1133 | |
| 1134 2008-11-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1135 | |
| 1136 * add: Task 内での API | |
| 1137 Task 外での API は、今まで通り manager->create_task とかですが | |
| 1138 タスク内でも、「オブジェクト->関数」の呼び出しがいいんじゃないか | |
| 1139 って話になったので、付け加えました。今のところ、SchedTask.h の | |
| 1140 内部クラスとして | |
| 1141 | |
| 1142 STaskManager | |
| 1143 | |
| 1144 ってのを加えて、ユーザはそのインスタンスである | |
| 1145 | |
| 1146 smanager | |
| 1147 | |
| 1148 からAPIにアクセスします。 | |
| 1149 今までは __scheduler->dma_load とかいろいろやってたんですが | |
| 1150 これからは全て smanager にしました。 | |
| 1151 というわけで、ここに使える API 一覧。いずれゲーム班 wikiの方にも。 | |
| 1152 | |
| 1153 - get_input, get_output, get_param | |
| 1154 - create_task, wait_task | |
| 1155 - global_alloc, global_get, global_free | |
| 1156 - mainMem_alloc, mainMem_wait, mainMem_get | |
| 1157 - dma_load, dma_store, dma_wait | |
| 1158 - allocate | |
| 1159 | |
| 1160 使い方は追々描きますが、 | |
| 1161 今のところ上に変更しなくてもそのままの記述で動くはずです。 | |
| 1162 いずれは全て移行してもらうことになりますがきっと。 | |
| 1163 | |
| 1164 | |
| 1165 * kernel/schedule/SchedTask.cc: | |
| 1166 いろいろ関数が増えてますが、ラッパーです。 | |
| 1167 | |
| 1168 2008-11-01 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1169 | |
| 1170 * add: kernel/main.cc | |
| 1171 main loop をユーザに書かせるのはめんどくさいので、 | |
| 1172 ライブラリ側で main() を書く事にしました。 | |
| 1173 ユーザ側では main() の代わりに cerium_main() を | |
| 1174 書かせるようにしています。引数は main() のをそのまま渡す感じで。 | |
| 1175 | |
| 1176 Cerium 標準のオプションとして、-cpu は付けました。 | |
| 1177 ゲームフレームワークってことで、-width とか -height は | |
| 1178 標準でつけてもいいかなって話なので、これは後日実装。 | |
| 1179 標準オプションで受け取った値にアクセスする方法も考えないと。 | |
| 1180 manager->cpu とか manager->width とかは安易か？ | |
| 1181 | |
| 1182 * add: Cell/PpeScheduler.cc | |
| 1183 MainScheduler をそのまま使うと、 | |
| 1184 PPE のタスクで mainMem_alloc で確保した領域がアライメント | |
| 1185 取れていないため、SPE で使うと余裕でバスエラー。 | |
| 1186 | |
| 1187 Scheduler->allocate で poxis_memalign で使えるように。 | |
| 1188 | |
| 1189 * move: kernel/schedule/FifoDmaManager.cc, MainScheduler.cc | |
| 1190 kernel というよりは Fifo バージョン用なので Fifo/ に移動。 | |
| 1191 | |
| 1192 | |
| 1193 2008-10-21 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1194 | |
| 1195 * kernel/ppe/TaskManagerImpl.cc (TaskManagerImpl::systask_init): fix | |
| 1196 下に述べてる SysTask_Finish を regist する部分 | |
| 1197 | |
| 1198 (TaskManagerImpl::spawn_task): | |
| 1199 | |
| 1200 SysTask_Finish に対して、タスクが spawn されるたびに | |
| 1201 wait_for を掛けて、待つようにしている。 | |
| 1202 | |
| 1203 * add: kernel/systask/ | |
| 1204 久々の更新乙 | |
| 1205 | |
| 1206 プログラム動かすとき、タスクが SPE だけで、 | |
| 1207 PPE で待ってるタスクが無いとそのままプログラムが素通りするってことで | |
| 1208 今まではユーザに、全てのタスクを待たせるタスクってのを書かせてた。 | |
| 1209 まあもちろんめんどくさいので、いい加減追加した。 | |
| 1210 | |
| 1211 system task っつーことで、spawn された全てのタスクを待つ | |
| 1212 SysTask_Finish を作った。これでいちいち task_finish とか作らなくておk | |
| 1213 | |
| 1214 2008-08-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1215 | |
| 1216 * thinking: add_update() ? | |
| 1217 現在、タスクは input/output があるわけですよ。 | |
| 1218 で、例えば | |
| 1219 | |
| 1220 - 入力データ : PolygoPpack | |
| 1221 - 出力データ : SpanPack | |
| 1222 | |
| 1223 ってなわけですが、別のタスクで | |
| 1224 | |
| 1225 - 入力データ : SceneGraphPack (更新前) | |
| 1226 - 出力データ : SceneGraphPack (更新後) | |
| 1227 | |
| 1228 ってのがある。つまり Update なわけだ。 | |
| 1229 今のところ、同じアドレスを add_inData, add_outData に設定して | |
| 1230 タスク内で memcpy(wbuf, rbuf, sizeof(SceneGraphPack) とかしてる。 | |
| 1231 まあそれはそれでいいのかわるいのか。 | |
| 1232 | |
| 1233 in/out だけじゃなくて update も必要？ | |
| 1234 | |
| 1235 2008-08-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1236 | |
| 1237 * add: ../include/TaskManager/base.h | |
| 1238 通常の new/delete では、RTTI とか 例外処理とかで | |
| 1239 -fno-exceptions や -fno-rtti をコンパイルオプションにしても | |
| 1240 効かなかったんだけど、operator new/delete をオーバーライドして | |
| 1241 中身を普通の malloc/free にすると、上の処理が無くなるので | |
| 1242 オプションが効くようになる。結果コードサイズも減ると。 | |
| 1243 SPE の場合、70〜80KBは減りました。使わない手は無い。 | |
| 1244 つーことで、一応動いてる。。。といいたけど動いてないorz | |
| 1245 最適化 (-O2 とか -O9) をかけると止まる。SPE 上でね。 | |
| 1246 FIFO バージョンだと問題ない。SPEだとだめだ。 | |
| 1247 今わかってる、止まる場所は Scheduler::run() 内の | |
| 1248 | |
| 1249 task3->write(); | |
| 1250 | |
| 1251 だ。task1~3までのnewは(多分)できているんだけど | |
| 1252 そこを呼び出すと SPE 自体が終了してしまう。謎だ | |
| 1253 | |
| 1254 一応、俺作の new/delete は base.h に定義してあって、 | |
| 1255 通常の API との切り替えは、base.h にある | |
| 1256 BASE_NEW_DELETE を切り替えるだけでおk。 | |
| 1257 全てのファイルではなく、現在は SPE で使いそうなところだけやってます。 | |
| 1258 いずれは全部やったほうがいいかな〜 | |
| 1259 | |
| 1260 ライブラリ側の最適化はアウトだけど、ユーザ側では問題ないです。 | |
| 1261 なので、今は | |
| 1262 | |
| 1263 ライブラリ側(libspemanager.a)は最適化無し(-O0) | |
| 1264 ユーザ側(SchedTaskを継承したやつね)は最適化しても無問題 (-O9) | |
| 1265 | |
| 1266 でっす。ここらへん完璧なれば、だいぶ楽になる。 | |
| 1267 つーかもう C++ やめ(ry | |
| 1268 | |
| 1269 | |
| 1270 2008-08-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1271 | |
| 1272 * change: mainMem_set -> mainMem_wait | |
| 1273 allocate を待つんだから、なんとなく wait かな。 | |
| 1274 あと、ユーザも使えるので、wait の方がわかりやすいと思ったり。 | |
| 1275 | |
| 1276 2008-08-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1277 | |
| 1278 * add: mainMem_alloc, mainMem_set, mainMem_get | |
| 1279 SPE から メインメモリの領域に対して allocate できないと | |
| 1280 SceneGraphの生成やら、結構クリティカルな処理を | |
| 1281 全部 PPE でやらないといけなくなるってことで実装しました。 | |
| 1282 | |
| 1283 流れとして | |
| 1284 | |
| 1285 1 タスク中に、mainMem(id,size) を実行する事で、 | |
| 1286 メインメモリに対して allocate のコマンドを発行。 | |
| 1287 | |
| 1288 1.1 Scheduler から PPE に対して | |
| 1289 - commmand (MY_SPE_COMMAND_MALLOC) | |
| 1290 - id (PPEから戻ってくるコマンドに必要) | |
| 1291 - size | |
| 1292 を mailbox で送る | |
| 1293 | |
| 1294 1.2 確保した領域はそのタスク内では取得できない(NULL が来ます) | |
| 1295 正確には、返事の mail をここでは read してないから | |
| 1296 | |
| 1297 2. PPE では、受信した mail が MY_SPE_COMMAND_MALLOC だったら | |
| 1298 次に来る mail が id と size であるとして read を行い、 | |
| 1299 size を元に allocate する。allocate が完了したら | |
| 1300 - id | |
| 1301 - allocate された領域のアドレス | |
| 1302 を SPE に mail で送る | |
| 1303 | |
| 1304 3. SPE Scheduler では、SchedTaskList::read で、 | |
| 1305 一つ前の TaskList 中で実行された mainMem_alloc の数だけ | |
| 1306 PPE からのメールを待つ。mainMem_set() の処理です。 | |
| 1307 | |
| 1308 4. create_task されたタスク内で mainMem_get(id) とすると | |
| 1309 allocate したメインメモリ領域のアドレスが得られる。 | |
| 1310 | |
| 1311 こんな感じ。結構ださい実装なので、もうちょいスマートにいきたいよね。 | |
| 1312 例題は Game_project/student/master/gongo/MainMemMalloc にあります。 | |
| 1313 README にもおんなじこと書いてます。 | |
| 1314 | |
| 1315 * memo: The number of available entries of Inbound/Outbound Mailbox | |
| 1316 Outbound (SPE -> PPE) のmailboxデータキュー保持数は | |
| 1317 | |
| 1318 /* SPE プログラム中 */ | |
| 1319 #include <spu_mfcio.h> | |
| 1320 spu_stat_out_mbox(void); | |
| 1321 | |
| 1322 で調べる事が出来る。 | |
| 1323 | |
| 1324 --- 記述例 --- | |
| 1325 printf("Available capacity of SPU Outbound Mailbox\n"); | |
| 1326 printf(" %d\n", spu_stat_out_mbox()); | |
| 1327 | |
| 1328 --- 実行結果 -- | |
| 1329 Available capacity of SPU Outbound Mailbox | |
| 1330 1 | |
| 1331 | |
| 1332 Inbound (PPE -> SPE) の mailbox データキュー保持数は | |
| 1333 | |
| 1334 /* PPE プログラム中 */ | |
| 1335 #include <libspe2.h> | |
| 1336 spe_in_mbox_status(spe_context_ptr_t); | |
| 1337 | |
| 1338 で調べられます。 | |
| 1339 | |
| 1340 --- 記述例 --- | |
| 1341 printf("the number of available entries = %d\n", | |
| 1052 | 1342 spe_in_mbox_status(spe_ctx)); |
| 276 | 1343 |
| 1344 --- 実行結果 --- | |
| 1345 the number of available entries = 4 | |
| 1346 | |
| 1347 Outbound が少ないなー。 | |
| 1348 In/Out 共に、キューが MAX の場合、減るまで wait 掛かるんだよな。 | |
| 1349 それがどこまで影響あるかは実際にやらないと、ってことか。 | |
| 1350 | |
| 1351 * fix: ファイル名の変更 (*.cpp -> *.cc) | |
| 1352 前々から先生に直せ言われてたので。 | |
| 1353 | |
| 1354 cvs のファイル名を変える方法は簡単に二つ(てかこれだけ？) | |
| 1355 | |
| 1356 1. cvs rm hoge.cpp; cvs add hoge.cc | |
| 1357 2. リポジトリを直接変更 mv hoge.cpp,v hoge.cc,v | |
| 1358 | |
| 1359 めんどくさかったので 2 でやりました。 | |
| 1360 Attic (削除されたファイルがあるリポジトリディレクトリ？)にも | |
| 1361 同じ処理を行えば、tag で update かけてもちゃんと反映されました。 | |
| 1362 | |
| 1363 2008-07-22 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1364 | |
| 1365 * tag: open-campus-2008 | |
| 1366 次やる事は、Cell/spe 以下のコードサイズを減らすために | |
| 1367 new/delete を消して malloc/free で統一する事。 | |
| 1368 placement_new ってのを使えば、コンストラクタは呼べて | |
| 1369 new ほどサイズ圧迫しないからこれにしようかな。 | |
| 1370 逆の placement_delete ってのは自分で小細工しないと行けないらしい。 | |
| 1371 まあ、これが旨く行けば 80KB ほど減るから。やるべきだろう。 | |
| 1372 | |
| 1373 * Cell/spe/Scheduler.cpp (Scheduler::dma_load): アホなミスその2 | |
| 1374 自分で __scheduler->dma_store をやってもデータが送れない。 | |
| 1375 そんな馬鹿な。つーことでいろいろ調べてもわからない。 | |
| 1376 アドレスやサイズが違うのかと調べても違う。 | |
| 1377 こうなったらっつーことでライブラリに printf 加えてみたら表示されない | |
| 1378 あれ、おかしいな。たしかに Connector::dma_store に加えたはz・・ | |
| 1379 | |
| 1380 Scheduler::dma_store(void *buf, uint32 addr, uint32 size, uint32 mask) | |
| 1381 { | |
| 1382 <<< | |
| 1383 connector->dma_load(buf, addr, size, mask); | |
| 1384 ======== | |
| 1385 connector->dma_store(buf, addr, size, mask); | |
| 1386 >>> | |
| 1387 } | |
| 1388 | |
| 1389 なぜ store から load を呼んでるのか不思議だった。 | |
| 1390 Scheduler::dma_load をコピペして dma_store にした後、 | |
| 1391 中の connector->dma_load を変えなかったってオチだな。 | |
| 1392 下のミスと合わせて5,6時間費やしたよHAHAHA | |
| 1393 | |
| 1394 * Cell/spe/SchedTask.cpp (SchedTask::exec): アホなミスその1 | |
| 1395 Test/test_render で、 | |
| 1396 SpanPack のデータが時々壊れてる感じがする。 | |
| 1397 送る前までは正常だから生成に問題は無いはず。 | |
| 1398 つーことでいろいろ調べたがわからず。 | |
| 1399 printf デバッグすると動く不思議 | |
| 1400 なんだ、printf で遅くなったらできるってことは | |
| 1401 DMA が完了する前に SchedTask::run にきてんのか？ | |
| 1402 いやいや、そんなばかな。だってちゃんと wait し・・・ | |
| 1403 | |
| 1404 <<< | |
| 1405 ============ | |
| 1406 __scheduler->dma_wait(DMA_READ); | |
| 1407 >>> | |
| 1408 | |
| 1409 はいはい wait し忘れ wait し忘れ | |
| 1410 | |
| 1411 2008-07-16 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1412 | |
| 1413 * memo: if 文消した成果2 ＆ memcpy するかしないかか | |
| 1414 Renew Task では、inListData,outListData は新たに allocate して | |
| 1415 使っているので、SchedTask にそって実行する場合、 | |
| 1416 | |
| 1417 __scheduler->dma_load(__inListData, (uint32)__task->inData, | |
| 1052 | 1418 sizeof(ListData), DMA_READ_IN_LIST); |
| 276 | 1419 __scheduler->dma_load(__outListData, (uint32)__task->outData, |
| 1052 | 1420 sizeof(ListData), DMA_READ_OUT_LIST); |
| 276 | 1421 |
| 1422 の代わりに | |
| 1423 | |
| 1052 | 1424 memcpy(__inListData, __task->inData, sizeof(ListData)); |
| 276 | 1425 memcpy(__outListData, __task->outData, sizeof(ListData)); |
| 1426 free(__task->inData); | |
| 1427 free(__task->outData); | |
| 1428 | |
| 1429 もしくは | |
| 1430 | |
| 1431 __inListData = __task->inData; | |
| 1432 __outListData = __task->outData; | |
| 1433 (__task->inData と __task->outData は Destructor で free する) | |
| 1434 | |
| 1435 とやっています。 | |
| 1436 memcpy が重いのはわかるんですが、下の方法では | |
| 1437 Destructor で if 文使って free() しているわけです(このタスクが Renew か否か)。 | |
| 1438 ですので、どっちが早いか試してみた。 | |
| 1439 | |
| 1440 /** | |
| 1441 * memcpy() して、すぐ free() する version | |
| 1442 */ | |
| 1443 void | |
| 1444 test_cpy(int flag, int *src) | |
| 1445 { | |
| 1446 if (flag) { | |
| 1052 | 1447 memcpy(data, src, sizeof(int)*length); |
| 1448 free(src); | |
| 276 | 1449 } |
| 1450 } | |
| 1451 | |
| 1452 /** | |
| 1453 * 参照で扱って、最後に free() する version | |
| 1454 */ | |
| 1455 void | |
| 1456 test_nocpy(int flag, int *src) | |
| 1457 { | |
| 1458 if (flag) { | |
| 1052 | 1459 data = src; |
| 276 | 1460 } |
| 1461 | |
| 1462 // この部分を SchedTask::~SchedTask() と | |
| 1463 // 思ってください | |
| 1464 if (flag) { | |
| 1052 | 1465 free(data); |
| 276 | 1466 } |
| 1467 } | |
| 1468 | |
| 1469 | |
| 1470 これらの関数を10000回ループしました。 | |
| 1471 src の allocate は関数の外でやっており、その部分は実行時間に含まれてません | |
| 1472 flag は 1 or 0 の繰り返しです。 | |
| 1473 | |
| 1474 - 実行結果 (1) | |
| 1052 | 1475 :no copy |
| 276 | 1476 SPE time by SPU Decrementer: 0.035500 |
| 1477 :copy | |
| 1478 SPE time by SPU Decrementer: 0.057500 | |
| 1479 | |
| 1480 memcpy しないほうが速いらしいです。 | |
| 1481 ためしに、flag を ずっと 1 にしてみました。 | |
| 1482 | |
| 1483 - 実行結果 (2) | |
| 1484 :no copy | |
| 1485 SPE time by SPU Decrementer: 0.055250 | |
| 1486 :copy | |
| 1487 SPE time by SPU Decrementer: 0.053389 | |
| 1488 | |
| 1489 今度は copy するほうが早いという不思議。 | |
| 1490 でもまあ、ずっと 1 ってことはないと思いますし、 | |
| 1491 むしろ flag == 1 になるほうが少ないと思うので、 | |
| 1492 no_copy version でやったほうがいいかな。 | |
| 1493 | |
| 1494 おまけで、実行結果 (1) の環境で、test_nocpy を変えてみた | |
| 1495 | |
| 1496 void | |
| 1497 test_nocpy(int flag, int *src) | |
| 1498 { | |
| 1499 if (flag) { | |
| 1052 | 1500 data = src; |
| 276 | 1501 } |
| 1502 | |
| 1503 free((void*)(flag*(int)data)); | |
| 1504 } | |
| 1505 | |
| 1506 キャストしまくりですが、単純に free(flag*data) だと | |
| 1507 「invalid operands of types 'int' and 'int*' to binary 'operator*'」って | |
| 1508 出るので、キャストで逃げました。 | |
| 1509 で、実行結果なんですが | |
| 1510 | |
| 1511 - 実行結果 (3) | |
| 1512 :no copy | |
| 1513 SPE time by SPU Decrementer: 0.040375 | |
| 1514 :copy | |
| 1515 SPE time by SPU Decrementer: 0.059500 | |
| 1516 | |
| 1517 遅くなってーら。キャストが悪いのか。乗算が重いのか。 | |
| 1518 branch が無い？ spe の if 文と対決しても遅いのかー。 | |
| 1519 例題が間違ってる可能性もあるが・・・ if 文は使っていくかなー | |
| 1520 | |
| 1521 | |
| 1522 2008-07-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1523 | |
| 1524 * fix: TaskGroup->group | |
| 1525 今まで slist っていう、ライブラリの単方向リスト構造体？を | |
| 1526 使ってたんだけど、まあいろいろあって、TaskQueue を使うようにしました。 | |
| 1527 最初からこれにするつもりではあったけどね。 | |
| 1528 RenewTask や static_alloc とかの実装を優先したので | |
| 1529 ライブラリを使いました。といっても、書いてみると | |
| 1530 それほと記述量無いので最初から行っても良かったかなーと思ったり。 | |
| 1531 | |
| 1532 そんなわけで動いてます。つーか、やめてよかったよ slist。 | |
| 1533 slist を使ったやつと使ってない奴のファイルサイズがやばい | |
| 1534 | |
| 1535 -rwxr-xr-x 1 gongo gongo 120672 2008-07-10 14:29 spe-main* | |
| 1536 -rwxr-xr-x 1 gongo gongo 180368 2008-07-10 13:40 spe-main.bak* | |
| 1537 | |
| 1538 .bak が slist を使ってる、上のやつが使ってないversionです。 | |
| 1539 まさか 60k も違ってくるとは思わなかった。 | |
| 1540 SPE LS の容量が 256k と考えると、かなりの痛手だったよ。アブねえ。 | |
| 1541 インラインとか最適化掛けまくってて、コード量が増えてるからかなー。 | |
| 1542 | |
| 1543 「SPU C/C++ 言語拡張」とかで、C++ のライブラリがSPUでも使えるよ〜 | |
| 1544 って書いてたから入れてみたんだけど。罠だったか。 | |
| 1545 おそらく SPU に移植した側の人も「サイズが増えるのを覚悟で使え」って | |
| 1546 ことだったんだろう。なかったら文句言う人も居そうだし。 | |
| 1547 | |
| 1548 2008-07-09 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1549 | |
| 1550 * fix: TaskGroup での task の扱い | |
| 1551 下にもかいているけど (直したいところ (1)) | |
| 1552 TaskGroup->group が持つ要素は int で持ってて、 | |
| 1553 それらは、同じく TaskGroup が持つ cur_id をインクリメントしていって、 | |
| 1554 それを要素としていました。つまり、TaskGroup->group は、厳密にいえば | |
| 1555 「どの Task があるか」ではなく、「いくつのタスクがあるか」を | |
| 1556 あらわしているだけでした。slist を使う意味もなかったわけです。 | |
| 1557 | |
| 1558 そこで、SchedTask が持つ、RenewTaskList の解放のタイミングを | |
| 1559 RenewTaskList の一番最後のタスクが delete されるときにしました。 | |
| 1560 これによって、アドレスが被ることがなくなったので | |
| 1561 TaskGroup->group の要素を TaskPtr にできました。 | |
| 1562 この方が、TaskGroup の意味的にもしっくりくるのでよかばってん。 | |
| 1563 | |
| 1564 * memo: if 文消した成果 | |
| 1565 | |
| 1566 #ifdef FREE_TEST | |
| 1567 free((ListDataPtr)(__flag_renewTask*(int)(__inListData))); | |
| 1568 free((ListDataPtr)(__flag_renewTask*(int)(__outListData))); | |
| 1569 free((TaskListPtr)(__flag_renewTask*(int)(__list))); | |
| 1570 #else | |
| 1571 if (__flag_renewTask) { | |
| 1052 | 1572 free(__inListData); |
| 1573 free(__outListData); | |
| 1574 free(__list); | |
| 276 | 1575 } |
| 1052 | 1576 #endif |
| 276 | 1577 |
| 1578 こんな感じで、いくつかか if 文を消してみた。 | |
| 1579 そして、PPE側の main.cc で gettimeofday で計測してみた (各10回) | |
| 1580 | |
| 1581 | |
| 1582 - if 文消した場合 | |
| 1583 time: 1.222000 | |
| 1584 time: 1.230000 | |
| 1585 time: 1.241000 | |
| 1586 time: 1.230000 | |
| 1587 time: 1.223000 | |
| 1588 time: 1.257000 | |
| 1589 time: 1.219000 | |
| 1590 time: 1.228000 | |
| 1591 time: 1.220000 | |
| 1592 time: 1.229000 | |
| 1593 avarage: 1.2299 | |
| 1594 | |
| 1595 - if 文消してない場合 | |
| 1596 time: 1.225000 | |
| 1597 time: 1.215000 | |
| 1598 time: 1.229000 | |
| 1599 time: 1.218000 | |
| 1600 time: 1.223000 | |
| 1601 time: 1.214000 | |
| 1602 time: 1.225000 | |
| 1603 time: 1.215000 | |
| 1604 time: 1.224000 | |
| 1605 time: 1.219000 | |
| 1606 avarage: 1.2207 | |
| 1607 | |
| 1608 あまり変わらな(ryむしｒ(ry | |
| 1609 使い方がまずいのか、もっとと回数を増やせば変わってくるのかね。。。 | |
| 1610 PPE でなく、 SPE のほうで計測すべきなのかなーとか思ったり思わなかったり。 | |
| 1611 | |
| 1612 | |
| 1613 2008-07-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1614 | |
| 1615 * add: Renew Task の wait | |
| 1616 Renew Task は今まで「生成されたやつ全部待つ」だったのを | |
| 1617 | |
| 1618 void SchedTask::wait_task(TaskPtr task); | |
| 1619 | |
| 1620 ってのを作って、任意のタスクに wait 掛けれるようにしました。 | |
| 1621 名前が思いつかなかったお。。。 | |
| 1622 動作確認済み・・・だと思います。例題・・・誰か例題を！(俺が | |
| 1623 | |
| 1624 | |
| 1625 * fix: SchedTask の変数名 | |
| 1626 ユーザが継承して使う SchedTask クラスなんですが、 | |
| 1627 今まで変数は list, task などを使ってました。 | |
| 1628 が、これは一般に使われやすい変数名です。 | |
| 1629 その証拠に、俺も例題書いている時に task って名前が被ってました。 | |
| 1630 | |
| 1631 run(r, w) | |
| 1632 { | |
| 1633 ... | |
| 1634 | |
| 1635 //TaskPtr task; <= 宣言してないのにエラーにならない | |
| 1636 task = create_task(TASK_EXEC); | |
| 1637 } | |
| 1638 | |
| 1639 ってコードを書いてたせいで、Scheduler が使用する task を | |
| 1640 上書きしたせいでバグってました。ってことがありました。 | |
| 1641 上のように、宣言してないのに普通に通ってるのを気づきませんでした。 | |
| 1642 今のところ変数名は __task とか __list にしてあります。 | |
| 1643 private にしてもいいんだけどさ。 | |
| 1644 | |
| 1645 | |
| 1646 2008-07-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1647 | |
| 1648 * fix: if 文を無くしてみた | |
| 1649 下の方に 「if () が多い」って書きましたが、いろいろ小細工を。 | |
| 1650 SchedTask をやってみました。例えば | |
| 1651 | |
| 1652 if (cmd != 0) { | |
| 1653 delete taskGroup; | |
| 1654 scheduler->mail_write(cmd); | |
| 1655 } | |
| 1656 | |
| 1657 ってのがありました。cmd ってのは taskGroup->status で | |
| 1658 もし cmd が 0 でなければ、taskGroup はすでに空っぽで | |
| 1659 待つべきタスクはすべて終了したので、taskGroup を delete し、 | |
| 1660 mailbox で cmd を PPE に送ります(cmd にはすでに送るべきコマンドがある) | |
| 1661 でまあ、これくらいなら | |
| 1662 | |
| 1663 delete (int*)((cmd != 0)*(int)(taskGroup)); | |
| 1664 scheduler->mail_write(cmd); | |
| 1665 | |
| 1666 ぐらいに直せました。 | |
| 1667 delete や free では NULL を渡しても何もしない(?)って動作なので | |
| 1668 これでも問題ない。つまり、cmd == 0 なら、taskGroup を | |
| 1669 解放する必要は無いので NULL が delete に渡されるわけです | |
| 1670 int* でキャストしてるのは、そのまま 0 を渡すと、 | |
| 1671 「int型を delete するのはできない」的なエラーがでるからです。 | |
| 1672 。。。だったら int* じゃなくて TaskGroupPtr じゃね？とか思った今。 | |
| 1673 | |
| 1674 あと、PPE 側で 「mail == 0 なら NOP」 的な処理を入れました。 | |
| 1675 これによって、cmd が 0 かその他で if を書く必要がなくなりました。 | |
| 1676 問題があるとすれば、 SPE -> PPE の mailbox の queue の長さ。 | |
| 1677 NOP コマンドを送って、queue の制限に引っかかって | |
| 1678 mail_write が止まるんじゃないかなーとか少し心配です。 | |
| 1679 ここらへんは optimize の時間に考える事かな。 | |
| 1680 どうせ PPE では mail しか読んでないし、 | |
| 1681 そこまで queue が埋まる事は無いと思いたい。 | |
| 1682 | |
| 1683 | |
| 1684 | |
| 1685 あとはこんな感じかな | |
| 1686 | |
| 1687 #if 1 // fix | |
| 1688 free((void*)(flag_renewTask*(int)(list))); | |
| 1689 #else | |
| 1690 if (flag_renewTask) { | |
| 1052 | 1691 free(list); |
| 276 | 1692 } |
| 1693 #endif | |
| 1694 | |
| 1695 動いてるのは確認したし、gdb で x/20i とかしたら | |
| 1696 branch 命令が減ってるのは確認した。 | |
| 1697 まあ -O9 とかで最適化掛けるとどっちも同じになるけどな。 | |
| 1698 | |
| 1699 | |
| 1700 * add (API): static_alloc, static_get, static_free | |
| 1701 SchedTask 自身だけが持つ領域ではなく、 | |
| 1702 SPE 上に複数のタスクが共有したい領域を作る | |
| 1703 これは task::run() 内で使用する。 | |
| 1704 | |
| 1705 - void* static_alloc(int id, int size); | |
| 1706 @param [id] 領域ID。現在は 0〜31 まで使用可能 (Scheduler.h で定義) | |
| 1707 @param [size] 領域のサイズ | |
| 1708 @return allocate した領域のポインタ。下の static_get の返り値と同じ | |
| 1709 | |
| 1710 - void* static_get(int id); | |
| 1711 @param [id] static_alloc で作った領域 ID。 | |
| 1712 @return 領域のポインタ | |
| 1713 | |
| 1714 - void static_free(int id); | |
| 1715 @param [id] 解放したい領域の ID | |
| 1716 | |
| 1717 こんな感じかなー。 | |
| 1718 static_free はさすがにユーザに任せるだろう。 | |
| 1719 static_free し忘れると SPE には致命的なので、ここはよく伝える必要有 | |
| 1720 | |
| 1721 例題は | |
| 1722 cvs: firefly:Game_project/student/master/gongo/Static | |
| 1723 | |
| 1724 まあ Renew と大体同じですけどね。 | |
| 1725 int 型配列 data を共有にして、各タスクでインクリメントしてる | |
| 1726 | |
| 1727 * TODO: TaskGroup の扱い | |
| 1728 通常の Task では、task->self には | |
| 1729 自分が終了した時に PPE に送るコマンド(自分自身)になりますが、 | |
| 1730 タスク中に生成されたタスク(もう何度も書くのめんどいんで Renew で)では | |
| 1731 task->self は、task を待っている TaskGroup を表します。 | |
| 1732 | |
| 1733 self という名前で意味が違うのでこういうことはやめたいんだが。。。 | |
| 1734 といいながらやめないのが(ry | |
| 1735 | |
| 1736 * memo: | |
| 1737 下の 直したいところ (1) ってやつがよくわからんので、 | |
| 1738 現在の状況だけ | |
| 1739 | |
| 1740 scheduler->add_groupTask() をするたびに | |
| 1741 | |
| 1742 group.insert_front(cur_id++); | |
| 1743 | |
| 1744 されます。 | |
| 1745 そして、scheduler->remove_groupTask() されると | |
| 1746 | |
| 1747 group.remove(--cur_id); | |
| 1748 | |
| 1749 されます。要するに、どのタスクでも | |
| 1750 cur_id だけが insert/remove されます。 | |
| 1751 「どのタスクがあるか」ではなく「どれだけのタスクがあるか」ですね。 | |
| 1752 実際にはしっかりと TaskPtr で管理したかったんですが、 | |
| 1753 下にも書いたアドレスが被る云々の問題でそれもできず。 | |
| 1754 やり方はあると思うんですが。 | |
| 1755 | |
| 1756 うーん、うまく説明できないな。 | |
| 1757 | |
| 1758 * tag: v20080707 | |
| 1759 タスク内タスク生成を作りました。 | |
| 1760 | |
| 1761 [TODO] | |
| 1762 SPE 上で領域を共有する API の | |
| 1763 | |
| 1764 - static_alloc | |
| 1765 - static_get | |
| 1766 - static_free | |
| 1767 | |
| 1768 を速攻で実装しよう。。 | |
| 1769 | |
| 1770 * add: タスク内タスク生成 | |
| 1771 一応できたんですが、直したい。。。 | |
| 1772 仕様としては | |
| 1773 | |
| 1774 - 現在のタスク(T1) の中でタスクを生成したとする (Tc = T2, T3, ...) | |
| 1775 - 本来、T1 が終了次第、T1 が終わった事を PPE に伝えるが、 | |
| 1776 ここでは、Tc が全て終わってから、T1 の終了を PPE に伝える | |
| 1777 - Tc 内で再びタスクが生成されても(Tcc)、Tcc が終わってから T1 を(ry | |
| 1778 | |
| 1779 現在は、生成したタスクすべてに対して wait_for をかけてる感じ。 | |
| 1780 しかし、例えば Frame Buffer に書き込む時は待つ必要ない(はず)なので | |
| 1781 タスク毎に wait_for を選べるようにした方がいいだろう。 | |
| 1782 | |
| 1783 __ 例題 | |
| 1784 cvs firefly:Game_project/student/master/gongo/Renew | |
| 1785 | |
| 1786 にあります。 | |
| 1787 もうちょいちゃんとした例題が欲しいところです。 | |
| 1788 | |
| 1789 | |
| 1790 __ 直したいところ (1) | |
| 1791 | |
| 1792 現在、Tc を管理する構造体として、TaskGroup を使ってます | |
| 1793 | |
| 1794 class TaskGroup { | |
| 1795 unsigned int command; // T1 が PPE に送るコマンド | |
| 1796 __gnu_cxx::slist<int> group; // Tc がある Linked List | |
| 1797 | |
| 1798 // function は省略 | |
| 1799 }; | |
| 1800 | |
| 1801 slist じゃなくて、TaskQueue みたいに自分で作っても良かったんだけど。 | |
| 1802 group.empty() == true になったら、command を PPE に送るって感じです。 | |
| 1803 | |
| 1804 で、slist が持つデータが TaskPtr じゃなくて int の理由。 | |
| 1805 まあいろいろあるんだけど(何)、アドレスが重複してしまうことです。 | |
| 1806 最初は、create_task で得られた TaskPtr をキーとして使うつもりだったけど | |
| 1807 その TaskPtr は TaskList から取った物で (&list->takss[index] みたいな) | |
| 1808 なんでそれじゃだめなのか。buff_taskList[2] (Scheduler.cpp 参照) を | |
| 1809 使うと、交互に使用するのでアドレスは被る。 | |
| 1810 新たに allocate すれば問題は無いが (t1とする)、SPE の LS の問題で | |
| 1811 使わなくなった TaskList は free していかないといけない。 | |
| 1812 で、free -> 再び allocate したとき (t2とする)、t1 と t2 の | |
| 1813 アドレスが被ることがあった。当然 TaskPtr も被ると。 | |
| 1814 だから、アドレスではなく、TaskGorup が持つ | |
| 1815 unsigned int cur_id を使う事にしました。 | |
| 1816 | |
| 1817 なんかここまで自分で書いてて、 | |
| 1818 なんで出来ないのかまだわからんくなってきた。 | |
| 1819 | |
| 1820 ので試しに戻してみたら ＊ で ＊ き ＊ ま ＊ し ＊ た ＊ | |
| 1821 わけわからん。まあ勘違いだったのか、いろいろ別のところを直してるうちに | |
| 1822 知らず知らずミスってたところも治ってたのか。まあいいか。 | |
| 1823 | |
| 1824 と思っていろいろ試したらまた動かなくなった。。もうだめぽ | |
| 1825 とりあえず、また unsigned int に戻しました。 | |
| 1826 今のところ、0 <= cur_id <= 0xffff (65535) の範囲のキーを使うように。 | |
| 1827 | |
| 1828 | |
| 1829 __ 直したいところ (2) | |
| 1830 if 文が多い。 | |
| 1831 今は、「通常の Task」「タスク内で生成されたタスク」で挙動が違います。 | |
| 1832 例えば | |
| 1833 | |
| 1834 - SPE で allocate されたデータを使うので、通常 DMA を使うところは | |
| 1835 アドレス参照や memcpy を使う | |
| 1836 - TaskGroup を、上記の Tc や Tcc へ引き継がせるところ | |
| 1837 | |
| 1838 なので、flag_renewTask とかいう変数で、ほぼ if 文 で書いてます。 | |
| 1839 SPE でこの書き方はかなりまずい気がします。良い書き方はないものか。。。 | |
| 1840 「通常の(ry」「タスク内(ry」で新たにインスタンスを作るってのも | |
| 1841 考えはしましたが (SchedTask = 通常、SchedRenewTask = タスク内(ry とか) | |
| 1842 これだと ユーザー側も この二つを選んでやることになります。 | |
| 1843 「このタスクは SchedRenewTask 、このタスクは通常」とかやるのは | |
| 1844 かなりめんどくさいと思う。だからライブラリ側で分けるべきか。。。 | |
| 1845 多重継承とかってこんなとき役に立つん？ | |
| 1846 | |
| 1847 | |
| 1848 2008-07-03 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1849 | |
| 1850 * TODO: | |
| 1851 - add_param で渡せるパラメータの数を増やす。15もあればいいんじゃね？ | |
| 1852 - 今の実装では、 | |
| 1853 | |
| 1854 1. PPE でタスク(T1)が生成される | |
| 1855 2. SPE で T1 が実行される | |
| 1856 3. T1 が終わった事を PPE に mailbox で送る | |
| 1857 送る情報は T1 自身。(PPE で生成された時のアドレス) | |
| 1858 | |
| 1859 なわけです。しかし、もし T1 から新たにタスクが生成された時はどうするか | |
| 1860 仮に T1 から T2, T3, T4 が作られたとする。 | |
| 1861 このとき、 | |
| 1862 | |
| 1863 1. T1 が終わった時点で、T1 から終了コマンドを送る | |
| 1864 2. T1 だけでなく、T1 内で作られた T2, T3, T4 が終わってから | |
| 1865 終了コマンドを送る | |
| 1866 | |
| 1867 の二つが考えられる。 | |
| 1868 PPE 側では T1 しか認識していないため、この判定は SPE 内でやることになる | |
| 1869 必要な処理かと言われると微妙だが、欲しくなるのは間違いない。 | |
| 1870 つーことで今これを実装中です。 | |
| 1871 | |
| 1872 | |
| 1873 * tag: v20080703 | |
| 1874 - タスクに 32 bits パラメータを渡す add_param を実装(現在は3個まで) | |
| 1875 - SPE 内部でタスク生成ができるようになった | |
| 1876 | |
| 1877 * add (API): SPE内部での create_task | |
| 1878 今まで、SPE ではタスクを生成する事は出来ず、 | |
| 1879 PPE から送られてくるタスクを実行するだけでした。 | |
| 1880 それだと不便だってことで SPE 内部でもできるようにしました。 | |
| 1881 方法はPPEでやるのと同じく | |
| 1882 | |
| 1883 task = create_task(TASK_EXEC); | |
| 1884 task->add_inData(buff, sizeof(Buff)); | |
| 1885 task->add_param(data); | |
| 1886 | |
| 1887 みたいな感じでいいです。 | |
| 1888 spawn() や wait_for() は実装していません。 | |
| 1889 SPE 内部で生成するタスク同士で依存関係作るのが | |
| 1890 結構めんどくさいからです。spawn() も、しなくても勝手に実行します。 | |
| 1891 PPE とそろえる意味で作ってもいいんだけどね。 | |
| 1892 そのためには SPE にも TaskManager が必要になってくるなー。 | |
| 1893 | |
| 1894 | |
| 1895 2008-06-24 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1896 | |
| 1897 * add (API): add_param, get_param | |
| 1898 DMA で送れないけど、必要になってくる 4 バイトの情報があるとして | |
| 1899 それは今までは | |
| 1900 | |
| 1901 add_inData(param, 0); | |
| 1902 | |
| 1903 とかして、「サイズ == 0 なら 32 bit のデータ」としていたけど | |
| 1904 それは余りにも変なので(関数の意味的にもおかしい)ので、 | |
| 1905 | |
| 1906 add_param(parameter); | |
| 1907 | |
| 1908 ってのを追加しました。タスク側では | |
| 1909 | |
| 1910 get_param(index); | |
| 1911 | |
| 1912 とかします。index は、add_param を呼び出した順番で決まります | |
| 1913 | |
| 1914 add_param(x); | |
| 1915 add_param(y); | |
| 1916 add_param(z); | |
| 1917 | |
| 1918 とあるとき、タスク側では | |
| 1919 | |
| 1920 int x = get_param(0); | |
| 1921 int z = get_param(2); | |
| 1922 | |
| 1923 とします。 | |
| 1924 今のところ parameter は 3つしか送れないことになってますが | |
| 1925 後ほど、上限をあげます。15くらいあれば余裕だと思うんだがどうだい？ | |
| 1926 今は、SPE でのタスクの生成のルーチンを書くために、最低限な部分だけ | |
| 1927 ってことで 3 つにしてます。それが出来次第、これもやります。 | |
| 1928 | |
| 1929 | |
| 1930 2008-06-12 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1931 | |
| 1932 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_runTaskList): | |
| 1933 アホなミス(ry | |
| 1934 | |
| 1935 「list が持つ TASK_MAX_SIZE を超えると、次の list へ next を」っていう | |
| 1936 前回直したところがまたミスっててだな。 | |
| 1937 簡単に言うと | |
| 1938 | |
| 1939 TaskPtr task = &list[list->length++]; | |
| 1940 [task の初期化] | |
| 1941 | |
| 1942 if (list->length > TASK_MAX_SIZE) { | |
| 1943 [newList 生成] | |
| 1944 newList = append(newList, topList[speid]); | |
| 1945 topList[speid] = newList; | |
| 1946 } | |
| 1947 | |
| 1948 ってやってたわけ。これだと、toplist[speid] に | |
| 1949 length = 0 の list が来る可能性があると。 | |
| 1950 で、spe に TaskList を送る条件は | |
| 1951 | |
| 1952 1. taskList[speid]->length >= 1 | |
| 1953 2. speid が次の TaskList を待っている状態 | |
| 1954 | |
| 1955 で、1 の条件に触れてしまい、TaskList が送られなくなって | |
| 1956 プログラムが終了しないと。アホですね〜 | |
| 1957 上の if 文を &list[list->length++]; の前に持って行くだけでおk。 | |
| 1958 | |
| 1959 2008-06-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 1960 | |
| 1961 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_runTaskList): | |
| 1962 アホなミスしてました。 | |
| 1963 list が持つ TASK_MAX_SIZE を超えると、次の list へ | |
| 1964 next を繋げるはずなんだけど、speTaskList_bg[speid] とか読む時に | |
| 1965 ちゃんと繋げられてなかったというかなんというか。 | |
| 1966 簡単に言うと、タスク多くなると落ち(ry | |
| 1967 | |
| 1968 * add (API): set_post | |
| 1969 | |
| 1052 | 1970 create_task(id, 0); |
| 276 | 1971 |
| 1972 とかわざわざ 0 付けるのもアレなので、もうそれように | |
| 1973 | |
| 1974 task->set_post(func) | |
| 1975 | |
| 1976 を追加しました。func は void (*func)(void) です。 | |
| 1977 せっかくだから、引数に void* とか付けてもいいんじゃないかと。 | |
| 1978 | |
| 1979 | |
| 1980 * fix (API): ListDMA API | |
| 1981 タスク側で、ListDMA で指定したデータの取り方 | |
| 1982 | |
| 1983 run(rbuf, wbuf) として | |
| 1984 | |
| 1985 // index は add_inData や add_outData で指定した(順番-1) | |
| 1986 get_input(rbuf, index); | |
| 1987 get_input(wbuf, index); | |
| 1988 | |
| 1989 返り値は void* なので、malloc っぽくキャストしてください。 | |
| 1990 あと、4バイト以下のデータを送りたい場合、main で | |
| 1991 | |
| 1992 add_inData(data, 0) | |
| 1993 | |
| 1994 と、アドレスは送りたいデータを則値で、サイズは 0 で指定するとおk。 | |
| 1995 get_input で int なりなんなりでキャストすればいいじゃない！ | |
| 1996 例題は | |
| 1997 | |
| 1998 Game_project/student/master/gongo/arr_cal | |
| 1999 | |
| 2000 で複数データ扱ってたり4バイト送ってたりしてます。 | |
| 2001 | |
| 2002 | |
| 2003 * tag: v20080610 | |
| 2004 前回との違いは | |
| 2005 | |
| 2006 - ListDMA の導入 | |
| 2007 - 凡ミスfix | |
| 2008 | |
| 2009 とかかな。何気にここには ListDMA の API 書いてなかったな。 | |
| 2010 | |
| 2011 - task->add_inData(addr, size); // input | |
| 2012 - task->add_outData(addr, size); // output | |
| 2013 | |
| 2014 これで Input/Output のデータ領域を指定可能。複数できます。 | |
| 2015 詳しくはいずれドキュメントに書く予定だが、 | |
| 2016 | |
| 2017 - addr は 16 バイトアライメントに取れてないと行けない | |
| 2018 - size は 16 バイト倍数 | |
| 2019 | |
| 2020 ってのが最低条件。 | |
| 2021 16 バイト未満のデータを送りたいとき(整数を2,3個とか)は考え中。 | |
| 2022 addr に直接渡すって手法はできるとわかってるので、それでもいいかな。 | |
| 2023 まあいろいろ問題はありますが、少しはできたんじゃないかな。 | |
| 2024 | |
| 2025 次からは SPE 内でのタスク生成(再起動？)を書く予定 | |
| 2026 | |
| 2027 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_runTaskList): | |
| 2028 if (speid > machineNum) { | |
| 2029 speid %= MAX_USE_SPE_NUM; | |
| 2030 } | |
| 2031 | |
| 2032 から | |
| 2033 | |
| 2034 if (speid >= machineNum) { | |
| 2035 speid %= machineNum; | |
| 2036 } | |
| 2037 | |
| 2038 に。なんという凡ミス | |
| 2039 | |
| 2040 * Cell/spe/CellDmaManager.cpp (CellDmaManager::dma_loadList): fix | |
| 2041 ListData が持つ ListElement は | |
| 2042 | |
| 2043 class ListElement { | |
| 2044 public: | |
| 2045 int size; | |
| 2046 unsigned int addr; | |
| 2047 }; | |
| 2048 | |
| 2049 というデータ構造なわけだが、これは、spu_mfcio.h が持っていて | |
| 2050 且つ List DMA で使用される | |
| 2051 | |
| 2052 typedef struct mfc_list_element { | |
| 2053 uint64_t notify : 1; /** Stall-and-notify bit */ | |
| 2054 uint64_t reserved : 16; | |
| 2055 uint64_t size : 15; /** Transfer size */ | |
| 2056 uint64_t eal : 32; /** Lower word of effective address */ | |
| 2057 } mfc_list_element_t; | |
| 2058 | |
| 2059 と同じである。notify と reserved は 0 となる (ストールは今は | |
| 2060 考えていない)ので、結局は uint が 2 つの 8 バイト のデータ構造であれば | |
| 2061 そのまま mfc_getl とか mfc_putl に遅れるわけである。 | |
| 2062 今までは mfc_list_element_t 構造体に for 文でいちいち代入してたが | |
| 2063 まあそれはなくなったっつーことで。dma_storeList もね。 | |
| 2064 | |
| 2065 | |
| 2066 2008-05-30 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2067 | |
| 2068 * change (API): TaskManager Memory Allocate | |
| 2069 manager->cerium_malloc(&buff, DEFAULT_ALIGNMENT, sizeof(Data)) | |
| 2070 | |
| 2071 から | |
| 2072 | |
| 2073 buff = (Data*)manager->malloc(sizeof(Data)); | |
| 2074 | |
| 2075 に変更しました。 | |
| 2076 alignment の指定は全て TaskManager に埋め込んであります。 | |
| 2077 記述は TaskManager.h に書いてあります。 | |
| 2078 | |
| 2079 void* TaskManager::malloc(int size) { | |
| 2080 return m_impl->allocate(DEFAULT_ALIGNMENT, size); | |
| 2081 } | |
| 2082 | |
| 2083 2008-05-29 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2084 | |
| 2085 * thinking: List DMA (4) | |
| 2086 Cell 版でも動いたのを確認。今、Cell 版で List DMA が動く条件は | |
| 2087 | |
| 2088 1. List の各要素の転送サイズが 16 バイト倍数でなければならない | |
| 2089 2. List の各要素の転送するデータのアドレスのアライメントを保証(16or128 | |
| 2090 | |
| 2091 2に関しては Cell の仕様なんでまあいいんだけど、 | |
| 2092 1は、ドキュメント見る分には | |
| 2093 | |
| 2094 - Cell Broadband Engine アーキテクチャ version 1.01 より | |
| 2095 - 7.5.3 get list | |
| 2096 > リスト・サイズ・パラメータは、このDMAコマンドの場合は | |
| 2097 > 8バイトの倍数でなければならず、また、リスト・アドレス・パラメータは、 | |
| 2098 > ローカルストレージの8バイト境界にアラインされなければなりません。 | |
| 2099 | |
| 2100 って書いてるんだよな。int が 10 個の配列(40バイト) を送っても | |
| 2101 見事に弾かれたんだよな。おのれバスエラーめ！ | |
| 2102 とりあえず、上の条件を満たせば行けました。 | |
| 2103 送るデータのアロケートは | |
| 2104 | |
| 2105 TaskManager::cerium_allocate(void **buff, int align, int size); | |
| 2106 | |
| 2107 ってのを作りました。使い方は別項目で。だいたい posix_memalign 準拠。 | |
| 2108 | |
| 2109 動くのはいいんだけど、これだとユーザに全部任せる事になります。 | |
| 2110 特に、配列をアロケートした後、その途中の部分をリストに入れたい時。 | |
| 2111 その配列の要素のサイズが16倍数じゃないとそこでエラーがでると。 | |
| 2112 それをユーザに全部任せるのは、まあいけないこともないけどさ。。。 | |
| 2113 | |
| 2114 | |
| 2115 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::mail_check): fix | |
| 2116 CellTaskManager は FifoTaskManager のオブジェクトを | |
| 2117 ppeManager という変数で持っていて、作業を別々に行っているわけで。 | |
| 2118 だけど両方のオブジェクトがもつ waitTaskQueue は同じじゃないと | |
| 2119 ならないので、最初は TaskQueuePtr * とかで渡して | |
| 2120 共有してたわけだけど、よくよく考えると、 | |
| 2121 | |
| 2122 - waitTaskQueue に task が append される時 | |
| 2123 CellTaskManager->append_waitTask() | |
| 2124 | |
| 2125 - waitTaskQueue から task が remove されるとき(依存満たした時とか) | |
| 2126 FifoTaskManagerImpl->mail_check() 及び | |
| 2127 CellTaskManagerImpl->mail_check() です。 | |
| 2128 | |
| 2129 つまり、waitTaskQueue が共有されるのは mail_check だけなので、 | |
| 2130 CellTaskManagerImpl の mail_check で | |
| 2131 | |
| 2132 ppeManager->mail_check(mail_list, &waitTaskQueue) | |
| 2133 | |
| 2134 として、ここで waitTaskQueue を参照渡ししてます。 | |
| 2135 ppeManager->mail_check で waitTaskQueue の整理が終わって | |
| 2136 戻ってくる事には waitTaskQueue が更新されていると。 | |
| 2137 | |
| 2138 なんか文章がおかしいですね。気になる人は俺に直でお願いします。 | |
| 2139 要するに、ppe と spe のそれぞれの TaskManagerImpl で | |
| 2140 waitTaskQueue の共有が上手くいったというわけです。 | |
| 2141 | |
| 2142 | |
| 2143 2008-05-24 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2144 | |
| 2145 * thinking: List DMA (3) | |
| 2146 現在実装中。Fifo 版では動いている模様。 | |
| 2147 問題は Cell だよなー。考えないと行けない事がいくつか | |
| 2148 | |
| 2149 - Input/Output データはアライメントされている？ | |
| 2150 アライメントされていなくても、こっちでアドレスずらして | |
| 2151 DMAしてずらして run() に渡して〜とかもできるんだけど | |
| 2152 かなりめんどくさい。それに、In ならともかく、 | |
| 2153 Out は変な領域に書き込みそうなので無理そう。 | |
| 2154 これはもうユーザが、送るデータはすべて | |
| 2155 Cerium_malloc 的なものを通したものだけ、っていう | |
| 2156 制約にした方がいいかもしれない。てかそうなんだっけ。 | |
| 2157 | |
| 2158 - 配列中のデータの指定 | |
| 2159 上の項目と少し関連があるんだが、例えば | |
| 2160 | |
| 2161 int data[100]; // アライメントは取れてるとする | |
| 2162 | |
| 2163 ってのがあって、そのなかの data[0]〜data[49]、 | |
| 2164 data[50] 〜 最後まで送りたいとする。 | |
| 2165 最初のやつは &data[0] のアドレスは 16 bytes アライメントだけど、 | |
| 2166 &data[50] では、sizeof(int)*50 = おそらく 200 ずれて | |
| 2167 16 bytes アライメントではなくなると。これだと DMA できない。 | |
| 2168 ユーザがそこまで考えて、例えば data[32] から送る、とかでもいいけど。 | |
| 2169 ライブラリ側で、少しは融通効くようにすべきかな。 | |
| 2170 やるなら、アドレスずらして取って来て、ユーザが見るデータは | |
| 2171 そのずらした分戻してから見せるって感じ。変な説明だが。 | |
| 2172 | |
| 2173 うーん。今はとりあえず全てアライメント大丈夫な方向でやってみるか。 | |
| 2174 | |
| 2175 | |
| 2176 2008-05-23 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2177 | |
| 2178 * Cell/SpeThreads.cpp (SpeThreads::init): スレッドの生成 | |
| 2179 今まで作られてたスレッドは | |
| 2180 | |
| 2181 - spe_context_run を実行するだけのスレッド (spe_thread_run) | |
| 2182 - 上のスレッドを呼び出し、終了を待つスレッド (frontend_thread_run) | |
| 2183 | |
| 2184 ２番目に何の意味があるのかということだが、 | |
| 2185 SPE 毎にスレッドを立ち上げておいて、 | |
| 2186 それぞれのSPEからのメールは、その担当するスレッドが見る、 | |
| 2187 って構想で作っていました。だけど、今は mailbox の扱いは | |
| 2188 Cell/CellTaskManagerImpl::mail_check で行っているため | |
| 2189 わざわざ２番目のスレッドを作る必要がなくなりました。 | |
| 2190 つーことで、frontend_thread_run ではなく、 | |
| 2191 最初から spe_thread_run を起動すればおkとなりました。 | |
| 2192 | |
| 2193 * Cell/SpeThreads.cpp (SpeThreads::get_mail): if 文排除 | |
| 2194 今までは | |
| 2195 | |
| 2196 if (spe_out_mbox_read(spe_ctx[speid], &ret, 1) < 0) { | |
| 1052 | 2197 return ret; |
| 276 | 2198 else |
| 1052 | 2199 return -1; |
| 276 | 2200 |
| 2201 とやっていた。これは | |
| 2202 | |
| 2203 - データを読めたらそれ(ret)を返す | |
| 2204 - データが無かったら -1 を返す | |
| 2205 | |
| 2206 ってことだったんだが、よくよく考えると、spe_out_mbox_read() は | |
| 2207 データがなかった場合 ret の値を変えないので、最初に | |
| 2208 | |
| 2209 unsigned int ret = (unsigned int)-1; | |
| 2210 | |
| 2211 としておけば、最終的に if 文無しの | |
| 2212 | |
| 2213 spe_out_mbox_read(spe_ctx[speid], &ret, 1); | |
| 2214 return ret; | |
| 2215 | |
| 2216 だけで済むわけだ。 | |
| 2217 | |
| 2218 2008-05-22 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2219 | |
| 2220 * thinking: List DMA (2) | |
| 2221 MFC List DMA read の場合は(少なくともPPEでcreate_taskする時は) | |
| 2222 read size が決まっているので無問題。 | |
| 2223 しかし、MFC List DMA write の場合。同じタスクでも | |
| 2224 違うサイズを出力するということはありえるので問題。 | |
| 2225 今までも、write の場合は task->run() の返す値が write size として | |
| 2226 使う事にしていた。List DMA write の場合は、おそらく | |
| 2227 | |
| 2228 - task->run() 内で write 用の List DMA 構造体を作って Scheduler に | |
| 2229 渡して、task->write() でやってもらう | |
| 2230 | |
| 2231 って感じ？ でも(上の手法に限らず)、write のサイズが決まってないと | |
| 2232 write 用バッファを生成しておく事ができないので | |
| 2233 書き込めない or あらかじめ多めに取っておくってことが必要になる。 | |
| 2234 後者は SPE には痛手(昔は強制16KB確保とかやってたな)なので微妙。 | |
| 2235 前者は論外だろう。 | |
| 2236 | |
| 2237 うーん、どうすっかな。Single DMA write の頃からこれは問題であって。 | |
| 2238 最悪、ユーザが「write のサイズが変動しないようなタスクにする」とか？ | |
| 2239 | |
| 2240 * thinking: List DMA | |
| 2241 | |
| 2242 構想としては以下のような考え。 | |
| 2243 | |
| 2244 class Task { | |
| 2245 int cmd; | |
| 2246 DataListDMA *rlist; | |
| 2247 DataListDMA *wlist; | |
| 2248 }; | |
| 2249 | |
| 2250 class DataListDMA { | |
| 2251 int length; // リストの数 | |
| 2252 unsigned int addr[128]; // アドレス | |
| 2253 int size[128]; // そのアドレスから取得するデータのサイズ | |
| 2254 }; | |
| 2255 | |
| 2256 128 という数字は、一つのタスクが持てるリストの合計サイズを | |
| 2257 1KB (= 1024B) にしようってことで 4*128+4*128 = 1024 としました。 | |
| 2258 ListDMA を使う流れとしては | |
| 2259 | |
| 2260 1. Scheduler から cmd にそった Task を生成する | |
| 2261 2. Task のコンストラクタ(もしくは Task を生成する implement 内 )で | |
| 2262 task->rlist, task->wlist を DMA read しておく (ここは通常のDMA) | |
| 2263 3. task->read() で MFC List DMA で List を読む | |
| 2264 | |
| 2265 DataListDMA->length に関しては、Task の中に入れるのも有りかと思う。 | |
| 2266 その場合は、2 の DMA read で、わざわざ 1KB 全部読む必要は無くなる。 | |
| 2267 | |
| 2268 | |
| 2269 * tag: v20080522 | |
| 2270 - PPE 側のタスクも SPE と同じく、クラスオブジェクトとして登録 | |
| 2271 - PPE、SPE 側の TaskManagerImpl を整理。見やすくなったと思われ | |
| 2272 | |
| 2273 こんなところかなー。 | |
| 2274 テストプログラムは | |
| 2275 | |
| 2276 Game_project/student/master/gongo/hello | |
| 2277 | |
| 2278 にあります。DMA の例題まだだったぜHAHAHA | |
| 2279 ここからは List DMA の処理を入れて行きたいと思います。 | |
| 2280 | |
| 2281 現在の simple_render のバージョンは | |
| 2282 PPE のタスクが関数ベースだった頃のなのでそのままでは動きません。 | |
| 2283 List DMA ができるか、気晴らしに描き直すと思います。 | |
| 2284 | |
| 2285 * Task 定義について | |
| 2286 PPE も C++ のクラスオブジェクトとしてタスクを定義するようにしました。 | |
| 2287 ちゃんとした API を考えたら改めて書きます。 | |
| 2288 | |
| 2289 * メールチェックから次のタスクリスト生成までの流れの変更 | |
| 2290 今までの FifoTaskManagerImpl の mail_check では | |
| 2291 | |
| 2292 1. mail_check | |
| 2293 1.1 check_task_finish | |
| 2294 1.1.1 notify_wait_taskQueue | |
| 2295 1.1.1.1 append_activeTask (依存満たしたタスクを) | |
| 2296 1.2 get_runTaskList | |
| 2297 | |
| 2298 と、全て mail_check の中で終わってたんですが、これを | |
| 2299 | |
| 2300 1. mail_check | |
| 2301 1.1 check_task_finish | |
| 2302 1.1.1 notify_task_finish | |
| 2303 2. wakeup_waitTask (つまり append_activeTask) | |
| 2304 3. get_runTaskList | |
| 2305 | |
| 2306 というように分割しました。 | |
| 2307 おかげで CellTaskManagerImpl の mail_check もすっきり。 | |
| 2308 | |
| 2309 2008-05-13 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2310 | |
| 2311 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::set_task): | |
| 2312 // set_task って名前やめね？ | |
| 2313 | |
| 2314 どの SPE に振るかって判定を少し変更。 | |
| 2315 cur_anySpeid の宣言場所のコメントにもあるけど、 | |
| 2316 これはインクリメントじゃなくて乱数の方が | |
| 2317 より SPE_ANY っぽいのか。むしろ「仕事してない方に割り振る」ってのが | |
| 2318 SPE_ANY の役目な気がするな。ウーム。。。 | |
| 2319 | |
| 2320 2008-05-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2321 | |
| 2322 * Cell/CellTaskManagerImpl.cpp (CellTaskManagerImpl::mail_check): | |
| 2323 PPE には実行するタスクが一つも無い時の動作がおかしかった。 | |
| 2324 要するに、 | |
| 2325 | |
| 2326 PPE で実行するタスクは全て SPE で実行中のタスク待ち | |
| 2327 | |
| 2328 って時。。。よけいわからなくなったな。 | |
| 2329 まあなんだ、今まで 必ずタスクが PPE and SPE にあったんだけど | |
| 2330 PPE or SPE ってか、どっちか片方でしか動いてない状況だと | |
| 2331 終了判定というか、それがおかしかったっぽい。 | |
| 2332 | |
| 2333 Hello World でのタスクは | |
| 2334 | |
| 2335 1. "Hello World!!" と表示するタスク (2.) を発行するタスク | |
| 2336 2. 表示するタスク | |
| 2337 3. 2 が全て終わったら実行される、最後のタスク(番兵的な | |
| 2338 | |
| 2339 この時、(2) が SPE だけで実行されてると、 | |
| 2340 (2) の終了を待つ (3) の判定？というか、それがおかしい | |
| 2341 | |
| 2342 | |
| 2343 もう眠くてわけわからん。 | |
| 2344 一応動いたんだけど、やはり描き直します。 | |
| 2345 気持ち悪いほどやっつけな書き方してるので。これはきもい。。。 | |
| 2346 | |
| 2347 2008-03-09 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2348 | |
| 2349 * memo: pthread_cond_wait | |
| 2350 この ChangeLog に書くものでもないが、まあメモ。 | |
| 2351 | |
| 2352 セマフォの P 動作は、基本的に | |
| 2353 | |
| 2354 --------------------- | |
| 1052 | 2355 pthread_mutex_lock(&sem->mutex); |
| 276 | 2356 |
| 2357 while(sem->value == 0) { // 資源が無い | |
| 2358 // 条件付き変数に自分を登録して、ロックを解放して、他の | |
| 2359 // プロセスが資源を解放してくれるのを待つ | |
| 2360 pthread_cond_wait(&sem->cond,&sem->mutex); | |
| 2361 } | |
| 2362 // 自分の分の資源があったので、それを確保する */ | |
| 2363 sem->value--; | |
| 2364 // ロックを解放する | |
| 2365 pthread_mutex_unlock(&sem->mutex); | |
| 2366 ---------------------- | |
| 2367 | |
| 2368 こんな感じ。でコメントにもあるように、 | |
| 2369 pthread_cond_wait では、wait の前に unlock する。 | |
| 2370 これがよくわかってなくて、「while の外で lock してるのに | |
| 2371 「なんで他のプロセスが lock できるんだろう。」と。 | |
| 2372 man 見ろよと思った。てか先生のページのコメントに書いてるよ！ | |
| 2373 | |
| 2374 | |
| 2375 2008-03-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2376 | |
| 2377 * memo: mailbox read の blocking/non-blocking | |
| 2378 spe_out_mbox_read は non-blocking API なので、 | |
| 2379 これをぐるぐる回すと busy-wait になるので、 | |
| 2380 今の所 ppe 側の Scheduler がトップに戻る？時にメール確認する。 | |
| 2381 で、spe_out_intr_mbox_read は blocking API 。 | |
| 2382 spe_out_mbox_read との記述の違いは、予め | |
| 2383 spe_event_handler_register で SPE_EVENT_OUT_INTR_MBOX を | |
| 2384 登録しておく。spe 側では、 | |
| 2385 | |
| 2386 spu_writech(SPU_WrOutMbox, data) | |
| 2387 | |
| 2388 じゃなくて | |
| 2389 | |
| 2390 spu_writech(SPU_WrOutIntrMbox, data) | |
| 2391 | |
| 2392 を使う必要がある。 | |
| 2393 両者の mailbox read の速度を調べてみたけど、そんなに違いは感じない。 | |
| 2394 まあベンチマークの取り方がへぼいせいかもしれないけど。 | |
| 2395 ってことで、こっちの intr の方がいいんじゃないかと思う。 | |
| 2396 これと セマフォを組み合わせて mail の処理は簡単になると思う。 | |
| 2397 セマフォの処理が重いって話もあるが、どうなんだろうね。 | |
| 2398 | |
| 2399 * Test/simple_render/task/create_span.cpp (half_triangle): fix | |
| 2400 画面外の span を描画しようとして落ちるので、それの修正。 | |
| 2401 polygon->span の時点で外してるけど、span を外すより | |
| 2402 Polygon の時点で修正するべきかな？ | |
| 2403 | |
| 2404 * kernel/ppe/TaskManagerImpl.cpp (TaskManagerImpl::set_task): fix | |
| 2405 返す TaskList が、mainTaskList の最後尾になってた。 | |
| 2406 ってことで、TaskList のトップである bufferManager->mainTaskList を。 | |
| 2407 | |
| 2408 * kernel/ppe/BufferManager.cpp (BufferManager::clear_taskList): fix | |
| 2409 mainTaskList->length はクリアしてるのに、 | |
| 2410 mainTaskList->next をクリアし忘れてた。 | |
| 2411 だから空の TaskList が送られてたのか・・・ちくしょう！ | |
| 2412 | |
| 2413 2008-03-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2414 | |
| 2415 * bug-fix (Test/simple_render): y座標の移動方向 | |
| 2416 (1) で、書き込む時に | |
| 2417 | |
| 2418 y = height - y | |
| 2419 | |
| 2420 としていた。千秋に聞いてみると、 | |
| 2421 | |
| 2422 「ポリゴンの y を増やす(+)と、画面上に進むようにした」 | |
| 2423 | |
| 2424 だそうです。なるほどねー。ってことで(2)でもやったら上に進んだよ。 | |
| 2425 | |
| 2426 しかし、ゲーム的には上が + の方がわかりやすいかもしれんが、 | |
| 2427 プログラミング的には、framebuffer ベースでやるので、 | |
| 2428 下にいくと y++ ってほうが作りやすいかなーと思いつつ。どっちがいいかね | |
| 2429 | |
| 2430 * bug (Test/simple_render): y座標の移動方向 | |
| 2431 Viewer::run_draw で、従来の、SpanPack をそのまま描画する方法(1)と、 | |
| 2432 SPE に渡すように、8分割したものとして描画する方法(2)で、 | |
| 2433 それぞれの y に +0.5 とかしたら、移動する方向が違う。 | |
| 2434 (1)では上、(2)では下へ行く。 | |
| 2435 送られてくる span には違いが見られず、 | |
| 2436 x 方向や 回転は問題ないので、おそらく draw 時の y の計算のバグだろう。 | |
| 2437 | |
| 2438 1: polygon.cpp Polygon::draw(SPANPACK); | |
| 2439 2: task/span_pack_draw.cpp run(); | |
| 2440 | |
| 2441 * Test/simple_render/spe/SpuDraw.cpp: ↓の続きの解決 | |
| 2442 render_y &= ~7 | |
| 2443 | |
| 2444 これでおkでした。先生ありがとうございます。 | |
| 2445 今はマクロとして | |
| 2446 | |
| 2447 #define YTOP(y) (y & ~7) | |
| 2448 | |
| 2449 ってやってますわ。 | |
| 2450 | |
| 2451 2008-03-05 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2452 | |
| 2453 * memo: MFC List DMA の element の最大値 | |
| 2454 「Cell Broadband Engine Architecture Version 1.02」 より | |
| 2455 | |
| 2456 P.55 | |
| 2457 The maximum number of elements is 2048. | |
| 2458 Each element describes a transfer of up to 16 KB. | |
| 2459 | |
| 2460 ってことらしいです。一度の転送での制限は普通のDMAと変わらず16KB。 | |
| 2461 mfc_list_element_t は 2048 個まで設定できるってことか。 | |
| 2462 テクスチャのロードで、分割しないなら MFC List DMA を使うことになるが、 | |
| 2463 2048 個もあれば充分？ | |
| 2464 | |
| 2465 | |
| 2466 * Test/simple_render/spe/SpuDraw.cpp: ↓の続き | |
| 2467 と思ったけど、やっぱりずれるなあ。うーむ。 | |
| 2468 とりあえず今は | |
| 2469 | |
| 2470 if (render_y < 0) { | |
| 2471 int tmpy = render_y%8; | |
| 2472 render_y -= tmpy + (tmpy != 0)*8; | |
| 2473 } else { | |
| 2474 render_y -= (render_y%8); | |
| 2475 } | |
| 2476 render_y += 1080/2; | |
| 2477 | |
| 2478 で落ち着くことに。うーむ。 | |
| 2479 もっと良い計算を考えるよりは span の生成時で | |
| 2480 いろいろやるほうがいいのかなー | |
| 2481 | |
| 2482 2008-03-04 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2483 | |
| 2484 * Test/simple_render/spe/SpuDraw.cpp: ↓の続き | |
| 2485 よくよく考えてだな。。。マイナスが気になるなら | |
| 2486 | |
| 2487 if (render_y < 0) { | |
| 2488 int tmpy = render_y%8; | |
| 2489 render_y -= tmpy + (tmpy != 0)*8; | |
| 2490 } else { | |
| 2491 render_y -= (render_y%8); | |
| 2492 } | |
| 2493 render_y += 1080/2; | |
| 2494 | |
| 2495 じゃなくて | |
| 2496 | |
| 2497 render_y += 1080/2; | |
| 2498 render_y -= (render_y%8); | |
| 2499 | |
| 2500 これでよくね？ってか元々そのための 1080/2 だった気が。。。 | |
| 2501 | |
| 2502 * Test/simple_render/spe/SpuDraw.cpp: render_y の計算の修正 | |
| 2503 sp->span[0].y (SpanPack に格納されてる最初の Span の y 座標) から | |
| 2504 この SpanPack が描画する範囲の一番上の y 座標を調べる。 | |
| 2505 | |
| 2506 どういうことかっていうと、例えば SpanPack に入ってる Span が持つ | |
| 2507 y 座標が 1 ~ 8 の時 | |
| 2508 | |
| 2509 1 ----- | |
| 2510 -- | |
| 2511 -------- | |
| 2512 ---- | |
| 2513 --------- | |
| 2514 8 -- | |
| 2515 | |
| 2516 '-' は描画していると思ってください。 | |
| 2517 この場合は、y = 1 がこの SpanPack の一番上、基準となる 座標ってこと。 | |
| 2518 framebuffer に書き込むとき、y = 1 から順々に書いて行きます。 | |
| 2519 | |
| 2520 で、sp->span[0].y ってのが、その基準となる y である保証が無いので、 | |
| 2521 sp->span[i].y 、つまりどの y からでも、基準となる y を求める | |
| 2522 必要がある。その計算をミスってました。 | |
| 2523 | |
| 2524 1 ////////// | |
| 1052 | 2525 <- なぜか書き込まれていない |
| 276 | 2526 ////////// |
| 2527 ////////// | |
| 2528 | |
| 2529 みたいに、歯抜けした部分があったので、いろいろ調べてみたら | |
| 2530 この render_y がずれてるってことが判明しました。 | |
| 2531 今までは | |
| 2532 | |
| 2533 render_y = sp->span[0].y; | |
| 2534 render_y += 1080/2; | |
| 2535 render_y = (render_y/8)*8; | |
| 2536 | |
| 2537 ってことしてたんだけど、これだと sp->span[0].y が マイナスのとき | |
| 2538 ずれることが判明。なので | |
| 2539 | |
| 2540 if (render_y < 0) { | |
| 2541 int tmpy = render_y%8; | |
| 2542 render_y -= tmpy + (tmpy != 0)*8; | |
| 2543 } else { | |
| 2544 render_y -= (render_y%8); | |
| 2545 } | |
| 2546 render_y += 1080/2; | |
| 2547 | |
| 2548 こうするとできました。。。が、直したい。 | |
| 2549 もう少し奇麗に描けると思うんだけどなー。if 文ぐらいは外したい | |
| 2550 | |
| 2551 2008-03-03 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2552 | |
| 2553 * memo: 最適化の結果 | |
| 2554 ppe/spe ともに最適化なしの場合 | |
| 2555 263.444 FPS | |
| 2556 | |
| 2557 ppe だけ -O9 で最適化 | |
| 2558 317.425 FPS | |
| 2559 | |
| 2560 spe だけ -O9 で最適化 | |
| 2561 812.539 FPS | |
| 2562 | |
| 2563 ppe/spe ともに -O9 で最適化 | |
| 2564 1610.58 FPS (吹いた | |
| 2565 | |
| 2566 | |
| 2567 最初、ダブル最適化の画像を見た時の | |
| 2568 あまりの早さにびびった。 | |
| 2569 逆に「こ、これはバグか！？」と思った | |
| 2570 | |
| 2571 | |
| 2572 2008-02-28 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2573 | |
| 2574 * kernel/ppe/BufferManager.cpp: remove_taskQueue_all() | |
| 2575 taskQueue の create と free が釣り合って無くて、 | |
| 2576 queue が足りなくなる -> extend_pool -> 足りなく(ry | |
| 2577 ってのを繰り返してメモリ的なセグメンテーションフォルとが出て | |
| 2578 なんでかなと思ったら、task->wait_me を消去してなかった。 | |
| 2579 task->wait_i は notify(ry で削除されるんだけど、 | |
| 2580 task->wait_me は、notify(ry に渡した後ほったらかしだった。 | |
| 2581 ってことで、wait_me を全消しする関数を作りましたとさ。 | |
| 2582 気持ち速度が増した気がする。気ね。 | |
| 2583 | |
| 2584 | |
| 2585 2008-02-17 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2586 | |
| 2587 * Todo: 悩んでる所 | |
| 2588 | |
| 2589 | |
| 2590 * fix: kernel/ppe/HTask.cpp | |
| 2591 今まで、manager->create_task で生成したタスクは | |
| 2592 | |
| 2593 - dependency の設定 | |
| 2594 manager->set_task_depend(master, slave) // slave は master を待つ | |
| 2595 | |
| 2596 - 実行キューへの追加 | |
| 2597 manager->spawn_task(master); | |
| 2598 manager->spawn_task(slave); | |
| 2599 | |
| 2600 と、manager を介してやっていました。 | |
| 2601 まあそれでもいいんだけど、特に dependency の所は | |
| 2602 どっちがどっちを待つのかってのは、API見るだけじゃわからない。 | |
| 2603 そこで、Task (HTask のこと) に、上二つに対応するような | |
| 2604 | |
| 2605 void set_depend(HTaskPtr) と void spawn(void) を追加しました。 | |
| 2606 | |
| 2607 - Usage | |
| 2608 slave->set_depend(master); // slave は master を待つ | |
| 2609 slave->spawn(); // slave をキューへ追加 | |
| 2610 | |
| 2611 結局は、それぞれの関数の中では、上の set_task_depend とかを | |
| 2612 呼んでるんだけど、ユーザ側からするとこの方がわかりやすいと思います。 | |
| 2613 | |
| 2614 2008-02-16 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2615 | |
| 2616 * tag: beta3 | |
| 2617 ダブルバッファリングを追加し、まあなんとか動いてるんじゃない？って | |
| 2618 ところまでですが、所詮 Fifo バージョンなので、 | |
| 2619 そろそろ Cell を書き上げて、並列にちゃんと動いてるか確かめないとね | |
| 2620 | |
| 2621 * add: kernel/ppe/DmaBuffer.cpp | |
| 2622 ダブルバッファリング用に作ったんだけど、 | |
| 2623 せっかくなので、DMA は、このオブジェクト(が持つ二つの領域)でしか | |
| 2624 行えないようにする。ってのでどうでしょう。って話を先生としました。 | |
| 2625 並列処理だし、ダブルバッファリングがデフォでいいでしょう。 | |
| 2626 というか、したくなければ swap_buffer とかしなければおk。 | |
| 2627 | |
| 2628 -Usage | |
| 2629 DmaBuffer *buffer = manager->allocate(sizeof(SceneGraphPack)); | |
| 2630 | |
| 2631 今までと違い、create_task の in_addr と out_addr には | |
| 2632 DmaBuffer をいれてください。ユーザが自分で malloc/new したやつは | |
| 2633 エラーを出すようにしてる(seg faultだけどね！) | |
| 2634 汚いソースだが、実際に使ってる様子は Test/simple_render の | |
| 2635 viewer.cpp で使ってます。sgp_buff と pp_buff ってやつね。 | |
| 2636 | |
| 2637 もうすこしユーザに優しいAPIを作りたい・・・ | |
| 2638 | |
| 2639 2008-02-11 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2640 | |
| 2641 * add: Test/simple_render | |
| 2642 chiaki の DataPack を使った Cube の表示プログラム。 | |
| 2643 簡単に DataPack を TaskManager の scheduler (SpeManager) に渡して | |
| 2644 処理してコピーして、を繰り返してるだけなんだけど | |
| 2645 まあ動いてる気がするのでいいんじゃないでしょうか。 | |
| 2646 | |
| 2647 | |
| 2648 2008-02-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2649 | |
| 2650 * tag: beta1 | |
| 2651 この状況だと、できることよりもできないことを書くべき？違うか。 | |
| 2652 | |
| 2653 - task (親) 中で task (子) を生成することはできない | |
| 2654 正確には「生成はできる」だけど、その 子task が | |
| 2655 親task に依存している別の task を無視して動くので | |
| 2656 ちゃんとした結果にならないと。 | |
| 2657 8日の Todo にも書いてあるけど、今の実装では | |
| 2658 task が task を生成することを想定してない感じなので。 | |
| 2659 完全に spe 用にのみ狙いを絞った実装であって | |
| 2660 OS って言えない実装であるからして、書き直すの？ | |
| 2661 全ての関数を task しようとするとこうなる訳で、 | |
| 2662 ある部分だけやるってのはまあできるんだろうけど、うーん。 | |
| 2663 | |
| 2664 - chiaki の simple_render が動かない | |
| 2665 (追記) 解決しました | |
| 2666 単に read/write buffer のサイズが足りないだけだった。アホスwww | |
| 2667 まあ辱めの為の下は残しておこう | |
| 2668 | |
| 2669 まだ cvs に commit してないけど、chiaki が書いた、 | |
| 2670 DataPack 対応の simple_render に TasKManager を組み込んでみた。 | |
| 2671 といっても、OSっぽく書いたんじゃなく、今は | |
| 2672 update_sgp と create_pp だけを task 化してみた。 | |
| 2673 でまあ動いてるような気はするけど、ものすっごい malloc 系の warning が。 | |
| 2674 時々長く動くよねみたいな感じになってしまっている。 | |
| 2675 TaskManager が悪いのか、simple_render が悪いのか。 | |
| 2676 この TaskManager、ある部分での malloc 系の問題に敏感だなあ。 | |
| 2677 まあそうでなかったらバグの探しようも無いし、良いっちゃー良いんだが。 | |
| 2678 | |
| 2679 | |
| 2680 2008-02-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2681 | |
| 2682 * add: kernel/ppe/SymTable.cpp | |
| 2683 今まで func[] = {add, sum, ...} | |
| 2684 とかやってかっこわるい言われまくってたので | |
| 2685 話し合いの通り Symbol Table みたいなものを作ることに | |
| 2686 | |
| 2687 // 疑似コードね | |
| 2688 struct sym_table { | |
| 2689 char *sym; // シンボル | |
| 2690 void *address; // シンボルが示すアドレス | |
| 2691 } sym_table[] = {{"Sum", &Sum} , {"Draw", &draw}}; | |
| 2692 | |
| 2693 int fd = get_fd("Sum"); | |
| 2694 void *addr = get_address(fd); | |
| 2695 | |
| 2696 table には "Sum" と "Draw" っていう二つのシンボルが登録されている。 | |
| 2697 例えば、ユーザ(カーネル？)が "Sum" ってシンボルにアクセスしたい場合、 | |
| 2698 まずは get_fd で "Sum" に対する、file descripter を返す。 | |
| 2699 ユーザは、その fd に従って get_address を取得することが出来る。 | |
| 2700 TaskManager 的な使い方をするなら | |
| 2701 | |
| 2702 // 俺は今、Draw 関数を使うタスクを生成したい | |
| 2703 int fd = manager->open("Draw"); | |
| 2704 manager->create_task(fd, size, in, out, func); | |
| 2705 manager->open では get_fd と同じ使い方です。 | |
| 2706 | |
| 2707 まだ改良の余地ありそうですが、今は動いてるってことで。 | |
| 2708 | |
| 2709 | |
| 2710 - 補足 | |
| 2711 なぜ file descripter と表すか | |
| 2712 | |
| 2713 OS の昨日として、 fopen とかと同じ使い方もできるじゃない！ | |
| 2714 | |
| 2715 | |
| 2716 * Todo: task が task を生成する際の処理 | |
| 2717 今まで、 task が行う作業は、演算のみを行うような | |
| 2718 単純な実装に決め打ちされているわけです。 | |
| 2719 しかし、OS なんかだと、タスク中から別のタスクを生成するとか | |
| 2720 ありありだと思われる。てか今のテストプログラムでなった。 | |
| 2721 | |
| 2722 Test/Sum にあるプログラムで使われるタスク | |
| 2723 | |
| 2724 - init2 // 貧相な名前ですまない | |
| 2725 演算する数値とかバッファの初期化 | |
| 2726 | |
| 2727 - sum1 | |
| 2728 ある範囲の整数 (i から i+16 とか) の総和 | |
| 2729 | |
| 2730 - sum2 | |
| 2731 sum1 で求められた、複数の範囲の総和を一つにまとめる | |
| 2732 (ex. 複数の sum1 が 1->16, 17->32, 33->48 の総和を計算し、 | |
| 2733 sum2 で 上の3つの総和を計算する | |
| 2734 要は 1->48 の総和を分割するっていうプログラムね | |
| 2735 | |
| 2736 - finish | |
| 2737 sum2 で求まった値を表示 | |
| 2738 | |
| 2739 この Sum というプログラム、というか OS と言おう。SumOS ね。 | |
| 2740 SumOS は最初に TaskManager (所謂 kernel) を起動し、 | |
| 2741 init を起動する。init では、予め決められたタスクである | |
| 2742 init2 と finish の二つのタスクを create して登録する。 | |
| 2743 init2 と finish には依存関係がある (init2 が終わったら finish) | |
| 2744 init2 の中で、sum1 と sum2 というタスクが作られる。 | |
| 2745 sum1 と sum2 にも依存関係はある (sum1 が終わったら sum2) | |
| 2746 | |
| 2747 今の実装だと、タスクが終了して初めて次のタスクへ行く。 | |
| 2748 まあ当たり前なんだけど、例えばそのタスクの中で | |
| 2749 新たにタスクが作られた場合、そのタスクが終了するまでは | |
| 2750 実行されなくなってしまう。 | |
| 2751 でまあ、今は、manager->create_task される度に | |
| 2752 manager->run とかして、無理やり起動してる訳さ。 | |
| 2753 何が無理矢理かっていうと、scheduler の役目をしている | |
| 2754 SpeManager (これも名前変えないと) を2度呼び出してる訳。 | |
| 2755 つまり、タスク中でタスクを作る度に、SpeManager オブジェクトを | |
| 2756 new してるわけさ。いいのか？いや、動いてるけどね？ | |
| 2757 | |
| 2758 ちなみに、Cell version だと spe が勝手に取っていってくれるから | |
| 2759 大丈夫かなと思いつつ、もし spe を1つしか使わない設定だったら微妙。 | |
| 2760 | |
| 2761 要するに、タスク中でタスクが作られる場合の処理を考えないとね。 | |
| 2762 | |
| 2763 2008-02-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2764 | |
| 2765 * memo: プログラミングの姿勢 | |
| 2766 scheduler とか、task の管理をする部分は | |
| 2767 kernel programing のつもりで、 | |
| 2768 example とか、task に割り当てる処理を決めたりする部分は | |
| 2769 user programing のつもりで。 | |
| 2770 | |
| 2771 それぞれ違った視点で見る必要がある | |
| 2772 | |
| 2773 * memo: OS というもの | |
| 2774 OS 起動の流れ | |
| 2775 | |
| 2776 - PC の電源を入れる | |
| 2777 - BIOS が立ち上がる (OpenFirmWare, EFI, BIOS) | |
| 2778 - 起動デバイスをチェック (優先度とか種類とか) | |
| 2779 - 起動デバイスから Boot loader を起動 | |
| 2780 + BIOS によって、認識できるファイルシステムが違う(だっけ？) | |
| 2781 + ファイルシステムのどこに Boot Loader があるか知っている | |
| 2782 + grub, grub2, lilo, kboot などがある | |
| 2783 - Boot Loader が kernel を起動 | |
| 2784 + ネットワークブートの場合、TCP/IP や | |
| 2785 ネットワークデバイス(イーサとか？)のドライバを持ってる必要がある | |
| 2786 - kernel は、最初に scheduler を起動する | |
| 2787 - scheduler の初期化 (init を呼ぶ？) | |
| 2788 - init では、事前？に設定されているスクリプトとかを呼ぶ | |
| 2789 + linux とかだと /etc/rc にあるやつを init が呼ぶ | |
| 2790 - login form が起動 | |
| 2791 | |
| 2792 補足 こっからユーザ | |
| 2793 - login する | |
| 2794 - shell を呼ぶ | |
| 2795 + login shell かどうか確かめる | |
| 2796 - ユーザに設定されてる起動スクリプト？を実行 | |
| 2797 - 晴れてログイン | |
| 2798 | |
| 2799 2008-02-06 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp> | |
| 2800 | |
| 2801 * kernel/spe/*.cpp: new と placement new | |
| 2802 現在、spe kernel のタスクは、切り替わる毎に | |
| 2803 new/delete を繰り返しています。今はこれでいいんだけど、 | |
| 2804 速度的にも、いずれは直さないといけないと思うわけで。 | |
| 2805 で、予め allocate された領域を利用した placement new を使えば | |
| 2806 new よりもそれなりに早くなるっぽい。 | |
| 2807 例題として、与えられた回数分 new/delete を繰り返すプログラムと、 | |
| 2808 同じ回数分、placement new したときの速度の比較 | |
| 2809 | |
| 2810 for (int i = 0; i < num; i++) { | |
| 2811 | |
| 2812 < task = new Task; | |
| 2813 < task->init(i); | |
| 2814 < task->printID(); | |
| 2815 < delete task; | |
| 2816 --- | |
| 2817 > task = new(buff) Task; // buff = malloc(BUFF_SIZE); | |
| 2818 > task->init(id); | |
| 2819 > task->printID(id); | |
| 2820 } | |
| 2821 | |
| 2822 placement new では、delete の必要は無い。 | |
| 2823 その中で新たに allocate してるなら必要かもしれないが。 | |
| 2824 速度比較は以下。no_new が placement new で、ln_new が new/delete 。 | |
| 2825 | |
| 2826 % ./a.out 10 // 10 回 | |
| 2827 no_new: time: 0.012135(msec) | |
| 2828 ln_new: time: 0.003572(msec) | |
| 2829 | |
| 2830 % ./a.out 100 | |
| 2831 no_new: time: 0.022453(msec) | |
| 2832 ln_new: time: 0.018989(msec) | |
| 2833 | |
| 2834 % ./a.out 1000 | |
| 2835 no_new: time: 0.115277(msec) | |
| 2836 ln_new: time: 0.136335(msec) | |
| 2837 | |
| 2838 % ./a.out 10000 | |
| 2839 no_new: time: 1.056156(msec) | |
| 2840 ln_new: time: 1.322709(msec) | |
| 2841 | |
| 2842 % ./a.out 100000 | |
| 2843 no_new: time: 10.622221(msec) | |
| 2844 ln_new: time: 13.362414(msec) | |
| 2845 | |
| 2846 % ./a.out 1000000 | |
| 2847 no_new: time: 109.436496(msec) | |
| 2848 ln_new: time: 136.956872(msec) | |
| 2849 | |
| 2850 10、100 回だと負けてるが、まあ無視しよう(ぇ | |
| 2851 回数が多くなるにつれて、ほんの少しだが no_new が勝ってる。 | |
| 2852 どうなんだろうね。ちなみに printID を無くすと | |
| 2853 | |
| 2854 % ./a.out 1000000 | |
| 2855 no_new: time: 0.008512(msec) | |
| 2856 ln_new: time: 27.100296(msec) | |
| 2857 | |
| 2858 I/O に左右され過ぎ。まあそんなもんだろうけどさ。 |