OLD | NEW |
---|---|
(Empty) | |
1 DM is like GM, but multithreaded. It doesn't do everything GM does yet. | |
2 | |
3 Current approximate list of missing features: | |
4 --mismatchPath | |
5 --missingExpectationsPath | |
6 --writePath | |
7 --writePicturePath | |
8 | |
9 --deferred | |
bsalomon
2013/10/10 21:13:07
We probably want most of these replay features. I'
mtklein
2013/10/10 22:32:19
Roger roger. Will come around and flesh these all
epoger
2013/10/11 21:13:13
Yup, we definitely need those on the bots. Fine w
| |
10 --pdf | |
11 --pipe | |
scroggo
2013/10/11 21:20:48
Pipe is currently only used by deferred, so it mig
mtklein
2013/10/15 18:30:53
Great. I will keep this in mind.
| |
12 --rtree | |
13 --serialize | |
14 --tiledGrid | |
15 --tiledPipe | |
scroggo
2013/10/11 21:20:48
tiledPipe is an experiment that we are not current
mtklein
2013/10/15 18:30:53
Sweet. Gone.
| |
16 | |
17 | |
18 DM's design is based around Tasks and a TaskRunner. | |
19 | |
20 A Task represents an independent unit of work that might fail. We make a task | |
21 for each GM/configuration pair we want to run. Tasks can kick off new tasks | |
22 themselves. For example, a CpuTask can kick off a ReplayTask to make sure | |
23 recording and playing back an SkPicture gives the same result as direct | |
24 rendering. | |
25 | |
26 The TaskRunner runs all tasks on one of two threadpools, whose sizes are | |
27 configurable by --cpuThreads and --gpuThreads. Ideally we'd run these on a | |
28 single threadpool but it can swamp the GPU if we shove too much work into it at | |
29 once. --cpuThreads defaults to the number of cores on the machine. | |
30 --gpuThreads defaults to 1, but you may find 2 or 4 runs a little faster. | |
31 | |
32 So the main flow of DM is: | |
33 | |
34 for each GM: | |
35 for each configuration: | |
36 kick off a new task | |
37 < tasks run, maybe fail, and maybe kick off new tasks > | |
38 wait for all tasks to finish | |
39 report failures | |
40 | |
OLD | NEW |