Skeleton of DM

dm/README

Index: dm/README
diff --git a/dm/README b/dm/README
new file mode 100644
index 0000000000000000000000000000000000000000..cfff9de14533f4ff016af3cb937d7b69fc8450ce
--- /dev/null
+++ b/dm/README
@@ -0,0 +1,40 @@
+DM is like GM, but multithreaded.  It doesn't do everything GM does yet.
+
+Current approximate list of missing features:
+  --mismatchPath
+  --missingExpectationsPath
+  --writePath
+  --writePicturePath
+
+  --deferred

[bsalomon, 2013/10/10 21:13:07]

We probably want most of these replay features. I'm not sure what
--mismatchPath, --missingExpectationsPath do. I doubt we'd miss
--writePicturePath initially (if ever).

[mtklein, 2013/10/10 22:32:19]

Roger roger.  Will come around and flesh these all out once I get a consensus on
the framework.

Looks to me that --mismatchPath and --missingExpecationsPath are pretty handy
when you're looking at this from a bot's perspective.  For now, I'm ignoring
bots as users, but one day something like that may show up here.

[epoger, 2013/10/11 21:13:13]

Yup, we definitely need those on the bots.  Fine with me to focus on non-bot
users first, but we should generally aim to have developers run the same tools
that the bots do.

+  --pdf
+  --pipe

[scroggo, 2013/10/11 21:20:48]

Pipe is currently only used by deferred, so it might be redundant to run it as
well.

[mtklein, 2013/10/15 18:30:53]

Great.  I will keep this in mind.

+  --rtree
+  --serialize
+  --tiledGrid
+  --tiledPipe

[scroggo, 2013/10/11 21:20:48]

tiledPipe is an experiment that we are not currently using/pursuing.

[mtklein, 2013/10/15 18:30:53]

Sweet.  Gone.

+
+
+DM's design is based around Tasks and a TaskRunner.
+
+A Task represents an independent unit of work that might fail.  We make a task
+for each GM/configuration pair we want to run.  Tasks can kick off new tasks
+themselves.  For example, a CpuTask can kick off a ReplayTask to make sure
+recording and playing back an SkPicture gives the same result as direct
+rendering.
+
+The TaskRunner runs all tasks on one of two threadpools, whose sizes are
+configurable by --cpuThreads and --gpuThreads.  Ideally we'd run these on a
+single threadpool but it can swamp the GPU if we shove too much work into it at
+once.  --cpuThreads defaults to the number of cores on the machine.
+--gpuThreads defaults to 1, but you may find 2 or 4 runs a little faster.
+
+So the main flow of DM is:
+
+    for each GM:
+        for each configuration:
+            kick off a new task
+    < tasks run, maybe fail, and maybe kick off new tasks >
+    wait for all tasks to finish
+    report failures
+