dm is like gm, but faster and with fewer features.
This is sort of the near-minimal proof-of-concept skeleton.
- It can run existing GMs.
- It supports most configs (just not PDF).
- --replay is the only "fancy" feature it currently supports
Hopefully you will be disturbed by its speed.
BUG=
R=epoger@google.com
Review URL: https://codereview.chromium.org/22839016
git-svn-id: http://skia.googlecode.com/svn/trunk@11802 2bbb7eff-a529-9590-31e7-b0007b416f81
diff --git a/dm/README b/dm/README
new file mode 100644
index 0000000..bce9a7e
--- /dev/null
+++ b/dm/README
@@ -0,0 +1,37 @@
+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 / --pipe
+ --rtree
+ --serialize
+ --tiledGrid
+
+
+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
+