114c3cd054
Reason for revert: plenty of data Original issue's description: > Sketch DM refactor. > > BUG=skia:3255 > > > I think this supports everything DM used to, but has completely refactored how > it works to fit the design in the bug. > > Configs like "tiles-gpu" are automatically wired up. > > I wouldn't suggest looking at this as a diff. There's just a bunch of deleted > files, a few new files, and one new file that shares a name with a deleted file > (DM.cpp). > > NOTREECHECKS=true > > Committed: https://skia.googlesource.com/skia/+/709d2c3e5062c5b57f91273bfc11a751f5b2bb88 TBR=bsalomon@google.com,mtklein@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia:3255 Review URL: https://codereview.chromium.org/853883004
28 lines
1.1 KiB
Plaintext
28 lines
1.1 KiB
Plaintext
DM (Diamond Master, a.k.a Dungeon master, a.k.a GM 2).
|
|
|
|
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
|
|
|