skia2/dm
mtklein e2d4eb7072 Hash .pngs instead of SkBitmaps.
This has the nice property of being able to double-check hashes after the fact.

mtklein@mtklein ~/skia (hash-png)> md5sum bad/8888/3x3bitmaprect.png
deede70ab2f34067d461fb4a93332d4c  bad/8888/3x3bitmaprect.png

mtklein@mtklein ~/skia (hash-png)> grep 3x3bitmaprect_8888 bad/dm.json
   "3x3bitmaprect_8888" : "deede70ab2f34067d461fb4a93332d4c",

I have checked that no two premultiplied colors map to the same unpremultiplied
color (math nerds: unpremultiplication is injective), so a change in
premultiplied SkBitmap will always imply a change in the encoded
unpremultiplied .png.  This means, it's safe to hash .pngs; we won't miss
subtle changes.

BUG=skia:
R=jcgregorio@google.com, stephana@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/549203003
2014-09-08 12:42:23 -07:00
..
DM.cpp Let .skps have Expectations (i.e. work with -r) too. 2014-09-08 09:12:28 -07:00
DMCpuGMTask.cpp Remove SkQuadTree. 2014-08-26 14:07:04 -07:00
DMCpuGMTask.h DM: SKP source / PDF backend 2014-06-06 09:28:43 -07:00
DMExpectations.h Start to rework DM JSON handling. 2014-09-08 08:05:18 -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 Test abandoning GL context in dm/nanobench. 2014-07-28 13:48:36 -07:00
DMPDFRasterizeTask.cpp SkData to SkStreamAsset to avoid unneeded copying 2014-08-26 10:38:07 -07:00
DMPDFRasterizeTask.h SkData to SkStreamAsset to avoid unneeded copying 2014-08-26 10:38:07 -07:00
DMPDFTask.cpp Change SkPicture::draw to playback 2014-09-04 08:42:50 -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 Change SkPicture::draw to playback 2014-09-04 08:42:50 -07:00
DMQuiltTask.h Remove SkQuadTree. 2014-08-26 14:07:04 -07:00
DMReporter.cpp Print max RSS in GM and nanobench too. 2014-08-19 15:55:55 -07:00
DMReporter.h DM tweaks 2014-05-29 20:14:48 +00:00
DMSerializeTask.cpp Install a hook to swap between SkPicture backends with a single define. 2014-08-21 13:07:27 -07:00
DMSerializeTask.h Support serialization in SkRecord-backed SkPictures. 2014-06-24 12:28:34 -07:00
DMSKPTask.cpp Let .skps have Expectations (i.e. work with -r) too. 2014-09-08 09:12:28 -07:00
DMSKPTask.h Let .skps have Expectations (i.e. work with -r) too. 2014-09-08 09:12:28 -07:00
DMTask.cpp SkThreadPool ~~> SkTaskGroup 2014-09-03 15:34:37 -07:00
DMTask.h SkThreadPool ~~> SkTaskGroup 2014-09-03 15:34:37 -07:00
DMTaskRunner.cpp SkThreadPool ~~> SkTaskGroup 2014-09-03 15:34:37 -07:00
DMTaskRunner.h SkThreadPool ~~> SkTaskGroup 2014-09-03 15:34:37 -07:00
DMTestTask.cpp SkThreadPool ~~> SkTaskGroup 2014-09-03 15:34:37 -07:00
DMTestTask.h SkThreadPool ~~> SkTaskGroup 2014-09-03 15:34:37 -07:00
DMUtil.cpp Try out scalar picture sizes 2014-08-29 08:03:56 -07:00
DMUtil.h Remove benches from DM. 2014-07-16 14:29:53 -07:00
DMWriteTask.cpp Hash .pngs instead of SkBitmaps. 2014-09-08 12:42:23 -07:00
DMWriteTask.h Start to rework DM JSON handling. 2014-09-08 08:05:18 -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