192cbf67b2
Plus: - minor ReplayTask refactoring to share code with SerializeTask - move --replay to ReplayTask and --serialize to SerializeTask like WriteTask - when --writePath is given, write failures for Replay and Serialize tasks - function names have fewer blatant Skia style violations BUG= R=bsalomon@google.com Author: mtklein@google.com Review URL: https://codereview.chromium.org/32613003 git-svn-id: http://skia.googlecode.com/svn/trunk@11890 2bbb7eff-a529-9590-31e7-b0007b416f81
36 lines
1.2 KiB
Plaintext
36 lines
1.2 KiB
Plaintext
DM is like GM, but multithreaded. It doesn't do everything GM does yet.
|
|
|
|
Current approximate list of missing features:
|
|
--mismatchPath
|
|
--missingExpectationsPath
|
|
--writePicturePath
|
|
|
|
--deferred / --pipe
|
|
--rtree
|
|
--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
|
|
|