skia2/dm
Mike Klein 18515cf370 DM: destroy contexts after each GPU task instead of before
This is for consistency with bench/nanobench/GM.  Haven't seen it make a difference.

BUG=skia:

Review URL: https://codereview.chromium.org/397743004
2014-07-15 16:10:02 -04:00
..
DM.cpp Support using OpenGL ES context on desktop 2014-06-30 06:36:31 -07:00
DMBenchTask.cpp Support using OpenGL ES context on desktop 2014-06-30 06:36:31 -07:00
DMBenchTask.h Support using OpenGL ES context on desktop 2014-06-30 06:36:31 -07:00
DMCpuGMTask.cpp Merge Replay and Quilt tasks, adding in all BBH implementations. 2014-07-09 13:10:58 -07:00
DMCpuGMTask.h DM: SKP source / PDF backend 2014-06-06 09:28:43 -07:00
DMExpectations.h In Android framework, make tools depend on jsoncpp 2014-06-18 10:31:40 -07:00
DMExpectationsTask.cpp DM: make GPU tasks multithreaded again. Big refactor. 2014-02-28 20:31:31 +00:00
DMExpectationsTask.h DM: make GPU tasks multithreaded again. Big refactor. 2014-02-28 20:31:31 +00:00
DMGpuGMTask.cpp Support using OpenGL ES context on desktop 2014-06-30 06:36:31 -07:00
DMGpuGMTask.h Support using OpenGL ES context on desktop 2014-06-30 06:36:31 -07:00
DMGpuSupport.h Add --resetGpuContext to both DM and nanobench. 2014-07-15 08:27:06 -07:00
DMPDFRasterizeTask.cpp DM: SKP source / PDF backend 2014-06-06 09:28:43 -07:00
DMPDFRasterizeTask.h DM: SKP source / PDF backend 2014-06-06 09:28:43 -07:00
DMPDFTask.cpp Deprecate SkPicture::clone(). 2014-06-27 12:34:44 -07:00
DMPDFTask.h Deprecate SkPicture::clone(). 2014-06-27 12:34:44 -07:00
DMPipeTask.cpp refactor DM::SetupBitmap 2014-05-15 17:33:31 +00:00
DMPipeTask.h DM: Add --skps. 2014-05-14 17:55:32 +00:00
DMQuiltTask.cpp Merge Replay and Quilt tasks, adding in all BBH implementations. 2014-07-09 13:10:58 -07:00
DMQuiltTask.h Merge Replay and Quilt tasks, adding in all BBH implementations. 2014-07-09 13:10:58 -07:00
DMReporter.cpp DM tweaks 2014-05-29 20:14:48 +00:00
DMReporter.h DM tweaks 2014-05-29 20:14:48 +00:00
DMSerializeTask.cpp Support serialization in SkRecord-backed SkPictures. 2014-06-24 12:28:34 -07:00
DMSerializeTask.h Support serialization in SkRecord-backed SkPictures. 2014-06-24 12:28:34 -07:00
DMSKPTask.cpp Merge Replay and Quilt tasks, adding in all BBH implementations. 2014-07-09 13:10:58 -07:00
DMSKPTask.h Support serialization in SkRecord-backed SkPictures. 2014-06-24 12:28:34 -07:00
DMTask.cpp DM: destroy contexts after each GPU task instead of before 2014-07-15 16:10:02 -04:00
DMTask.h DM tweaks 2014-05-29 20:14:48 +00:00
DMTaskRunner.cpp DM: Push GPU-parent child tasks to the front of the queue. 2014-05-01 17:41:32 +00:00
DMTaskRunner.h DM: Push GPU-parent child tasks to the front of the queue. 2014-05-01 17:41:32 +00:00
DMTestTask.cpp DM: when 32-bit, disable pathops internal threading by default 2014-04-30 14:56:29 +00:00
DMTestTask.h Let DM work without a GPU. 2014-03-26 21:26:15 +00:00
DMUtil.cpp Support serialization in SkRecord-backed SkPictures. 2014-06-24 12:28:34 -07:00
DMUtil.h Support serialization in SkRecord-backed SkPictures. 2014-06-24 12:28:34 -07:00
DMWriteTask.cpp DM: add pdf 2014-06-03 13:57:14 -07:00
DMWriteTask.h DM: add pdf 2014-06-03 13:57:14 -07:00
README DM: add pdf 2014-06-03 13:57:14 -07:00

DM is like GM, but multithreaded.  It doesn't do everything GM does.

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