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 / --pipe |
| 10 --rtree |
| 11 --serialize |
| 12 --tiledGrid |
| 13 |
| 14 |
| 15 DM's design is based around Tasks and a TaskRunner. |
| 16 |
| 17 A Task represents an independent unit of work that might fail. We make a task |
| 18 for each GM/configuration pair we want to run. Tasks can kick off new tasks |
| 19 themselves. For example, a CpuTask can kick off a ReplayTask to make sure |
| 20 recording and playing back an SkPicture gives the same result as direct |
| 21 rendering. |
| 22 |
| 23 The TaskRunner runs all tasks on one of two threadpools, whose sizes are |
| 24 configurable by --cpuThreads and --gpuThreads. Ideally we'd run these on a |
| 25 single threadpool but it can swamp the GPU if we shove too much work into it at |
| 26 once. --cpuThreads defaults to the number of cores on the machine. |
| 27 --gpuThreads defaults to 1, but you may find 2 or 4 runs a little faster. |
| 28 |
| 29 So the main flow of DM is: |
| 30 |
| 31 for each GM: |
| 32 for each configuration: |
| 33 kick off a new task |
| 34 < tasks run, maybe fail, and maybe kick off new tasks > |
| 35 wait for all tasks to finish |
| 36 report failures |
| 37 |
OLD | NEW |