2013-10-16 13:02:15 +00:00
|
|
|
// Main binary for DM.
|
|
|
|
// For a high-level overview, please see dm/README.
|
|
|
|
|
|
|
|
#include "GrContext.h"
|
|
|
|
#include "GrContextFactory.h"
|
|
|
|
#include "SkCommandLineFlags.h"
|
|
|
|
#include "SkForceLinking.h"
|
|
|
|
#include "SkGraphics.h"
|
2013-12-02 13:50:38 +00:00
|
|
|
#include "SkString.h"
|
2013-10-16 13:02:15 +00:00
|
|
|
#include "gm.h"
|
|
|
|
|
|
|
|
#include "DMReporter.h"
|
|
|
|
#include "DMTask.h"
|
|
|
|
#include "DMTaskRunner.h"
|
|
|
|
#include "DMCpuTask.h"
|
|
|
|
#include "DMGpuTask.h"
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
#include "DMWriteTask.h"
|
2013-10-16 13:02:15 +00:00
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
using skiagm::GM;
|
|
|
|
using skiagm::GMRegistry;
|
|
|
|
|
|
|
|
DEFINE_int32(cpuThreads, -1, "Threads for CPU work. Default NUM_CPUS.");
|
|
|
|
DEFINE_int32(gpuThreads, 1, "Threads for GPU work.");
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
DEFINE_string2(expectations, r, "",
|
|
|
|
"If a directory, compare generated images against images under this path. "
|
|
|
|
"If a file, compare generated images against JSON expectations at this path.");
|
2013-10-16 13:02:15 +00:00
|
|
|
DEFINE_string(resources, "resources", "Path to resources directory.");
|
|
|
|
DEFINE_string(match, "", "[~][^]substring[$] [...] of GM name to run.\n"
|
|
|
|
"Multiple matches may be separated by spaces.\n"
|
|
|
|
"~ causes a matching GM to always be skipped\n"
|
|
|
|
"^ requires the start of the GM to match\n"
|
|
|
|
"$ requires the end of the GM to match\n"
|
|
|
|
"^ and $ requires an exact match\n"
|
|
|
|
"If a GM does not match any list entry,\n"
|
|
|
|
"it is skipped unless some list entry starts with ~");
|
2014-01-09 19:14:57 +00:00
|
|
|
DEFINE_string(config, "565 8888 gpu",
|
2013-10-16 13:02:15 +00:00
|
|
|
"Options: 565 8888 gpu msaa4 msaa16 gpunull gpudebug angle mesa"); // TODO(mtklein): pdf
|
|
|
|
|
|
|
|
__SK_FORCE_IMAGE_DECODER_LINKING;
|
|
|
|
|
|
|
|
// "FooBar" -> "foobar". Obviously, ASCII only.
|
|
|
|
static SkString lowercase(SkString s) {
|
|
|
|
for (size_t i = 0; i < s.size(); i++) {
|
|
|
|
s[i] = tolower(s[i]);
|
|
|
|
}
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kick_off_tasks(const SkTDArray<GMRegistry::Factory>& gms,
|
|
|
|
const SkTArray<SkString>& configs,
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
const DM::Expectations& expectations,
|
2013-10-16 13:02:15 +00:00
|
|
|
DM::Reporter* reporter,
|
|
|
|
DM::TaskRunner* tasks) {
|
|
|
|
const SkBitmap::Config _565 = SkBitmap::kRGB_565_Config;
|
|
|
|
const SkBitmap::Config _8888 = SkBitmap::kARGB_8888_Config;
|
|
|
|
const GrContextFactory::GLContextType native = GrContextFactory::kNative_GLContextType;
|
|
|
|
const GrContextFactory::GLContextType null = GrContextFactory::kNull_GLContextType;
|
|
|
|
const GrContextFactory::GLContextType debug = GrContextFactory::kDebug_GLContextType;
|
|
|
|
const GrContextFactory::GLContextType angle =
|
|
|
|
#if SK_ANGLE
|
|
|
|
GrContextFactory::kANGLE_GLContextType;
|
|
|
|
#else
|
|
|
|
native;
|
|
|
|
#endif
|
|
|
|
const GrContextFactory::GLContextType mesa =
|
|
|
|
#if SK_MESA
|
|
|
|
GLContextFactory::kMESA_GLContextType;
|
|
|
|
#else
|
|
|
|
native;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
for (int i = 0; i < gms.count(); i++) {
|
|
|
|
#define START(name, type, ...) \
|
|
|
|
if (lowercase(configs[j]).equals(name)) { \
|
|
|
|
tasks->add(SkNEW_ARGS(DM::type, \
|
|
|
|
(name, reporter, tasks, expectations, gms[i], __VA_ARGS__))); \
|
|
|
|
}
|
|
|
|
for (int j = 0; j < configs.count(); j++) {
|
|
|
|
START("565", CpuTask, _565);
|
|
|
|
START("8888", CpuTask, _8888);
|
|
|
|
START("gpu", GpuTask, _8888, native, 0);
|
|
|
|
START("msaa4", GpuTask, _8888, native, 4);
|
|
|
|
START("msaa16", GpuTask, _8888, native, 16);
|
|
|
|
START("gpunull", GpuTask, _8888, null, 0);
|
|
|
|
START("gpudebug", GpuTask, _8888, debug, 0);
|
|
|
|
START("angle", GpuTask, _8888, angle, 0);
|
|
|
|
START("mesa", GpuTask, _8888, mesa, 0);
|
|
|
|
//START("pdf", PdfTask, _8888);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#undef START
|
|
|
|
}
|
|
|
|
|
|
|
|
static void report_failures(const DM::Reporter& reporter) {
|
|
|
|
SkTArray<SkString> failures;
|
|
|
|
reporter.getFailures(&failures);
|
|
|
|
|
|
|
|
if (failures.count() == 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
SkDebugf("Failures:\n");
|
|
|
|
for (int i = 0; i < failures.count(); i++) {
|
|
|
|
SkDebugf(" %s\n", failures[i].c_str());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-16 18:21:03 +00:00
|
|
|
int tool_main(int argc, char** argv);
|
|
|
|
int tool_main(int argc, char** argv) {
|
2013-10-16 13:02:15 +00:00
|
|
|
SkGraphics::Init();
|
|
|
|
|
|
|
|
SkCommandLineFlags::Parse(argc, argv);
|
|
|
|
GM::SetResourcePath(FLAGS_resources[0]);
|
|
|
|
SkTArray<SkString> configs;
|
|
|
|
for (int i = 0; i < FLAGS_config.count(); i++) {
|
2013-12-02 13:50:38 +00:00
|
|
|
SkStrSplit(FLAGS_config[i], ", ", &configs);
|
2013-10-16 13:02:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
SkTDArray<GMRegistry::Factory> gms;
|
|
|
|
for (const GMRegistry* reg = GMRegistry::Head(); reg != NULL; reg = reg->next()) {
|
2013-10-25 15:02:57 +00:00
|
|
|
SkAutoTDelete<GM> gmForName(reg->factory()(NULL));
|
|
|
|
if (!SkCommandLineFlags::ShouldSkip(FLAGS_match, gmForName->shortName())) {
|
|
|
|
*gms.append() = reg->factory();
|
|
|
|
}
|
2013-10-16 13:02:15 +00:00
|
|
|
}
|
|
|
|
SkDebugf("%d GMs x %d configs\n", gms.count(), configs.count());
|
|
|
|
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
SkAutoTDelete<DM::Expectations> expectations(SkNEW(DM::NoExpectations));
|
2013-10-16 13:02:15 +00:00
|
|
|
if (FLAGS_expectations.count() > 0) {
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
const char* path = FLAGS_expectations[0];
|
|
|
|
if (sk_isdir(path)) {
|
|
|
|
expectations.reset(SkNEW_ARGS(DM::WriteTask::Expectations, (path)));
|
|
|
|
} else {
|
|
|
|
expectations.reset(SkNEW_ARGS(DM::JsonExpectations, (path)));
|
|
|
|
}
|
2013-10-16 13:02:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DM::Reporter reporter;
|
|
|
|
DM::TaskRunner tasks(FLAGS_cpuThreads, FLAGS_gpuThreads);
|
|
|
|
kick_off_tasks(gms, configs, *expectations, &reporter, &tasks);
|
|
|
|
tasks.wait();
|
|
|
|
|
|
|
|
reporter.updateStatusLine();
|
|
|
|
SkDebugf("\n");
|
|
|
|
report_failures(reporter);
|
|
|
|
|
|
|
|
SkGraphics::Term();
|
|
|
|
|
|
|
|
return reporter.failed() > 0;
|
|
|
|
}
|
2013-10-16 18:21:03 +00:00
|
|
|
|
|
|
|
#if !defined(SK_BUILD_FOR_IOS) && !defined(SK_BUILD_FOR_NACL)
|
|
|
|
int main(int argc, char** argv) {
|
|
|
|
return tool_main(argc, argv);
|
|
|
|
}
|
|
|
|
#endif
|