mtklein@google.com | d36522d | 2013-10-16 13:02:15 +0000 | [diff] [blame] | 1 | DM is like GM, but multithreaded. It doesn't do everything GM does yet. |
| 2 | |
| 3 | Current approximate list of missing features: |
commit-bot@chromium.org | 2d3a789 | 2013-10-28 19:51:26 +0000 | [diff] [blame] | 4 | --config pdf |
mtklein@google.com | d36522d | 2013-10-16 13:02:15 +0000 | [diff] [blame] | 5 | --mismatchPath |
| 6 | --missingExpectationsPath |
mtklein@google.com | d36522d | 2013-10-16 13:02:15 +0000 | [diff] [blame] | 7 | --writePicturePath |
| 8 | |
commit-bot@chromium.org | 2d3a789 | 2013-10-28 19:51:26 +0000 | [diff] [blame] | 9 | --deferred |
mtklein@google.com | d36522d | 2013-10-16 13:02:15 +0000 | [diff] [blame] | 10 | |
| 11 | |
| 12 | DM's design is based around Tasks and a TaskRunner. |
| 13 | |
| 14 | A Task represents an independent unit of work that might fail. We make a task |
| 15 | for each GM/configuration pair we want to run. Tasks can kick off new tasks |
| 16 | themselves. For example, a CpuTask can kick off a ReplayTask to make sure |
| 17 | recording and playing back an SkPicture gives the same result as direct |
| 18 | rendering. |
| 19 | |
| 20 | The TaskRunner runs all tasks on one of two threadpools, whose sizes are |
| 21 | configurable by --cpuThreads and --gpuThreads. Ideally we'd run these on a |
| 22 | single threadpool but it can swamp the GPU if we shove too much work into it at |
| 23 | once. --cpuThreads defaults to the number of cores on the machine. |
| 24 | --gpuThreads defaults to 1, but you may find 2 or 4 runs a little faster. |
| 25 | |
| 26 | So the main flow of DM is: |
| 27 | |
| 28 | for each GM: |
| 29 | for each configuration: |
| 30 | kick off a new task |
| 31 | < tasks run, maybe fail, and maybe kick off new tasks > |
| 32 | wait for all tasks to finish |
| 33 | report failures |
| 34 | |