Chrome's using a bounding box, so it's a good idea for our
bots to do so too.
When set, we'll create an SkTileGrid to match the
parameters of --clip, and so should always hit its fast
path.
This will impose a small overhead (querying the BBH) on all
SKPs, but make large SKPs render more quickly. E.g. on
GPU desk_pokemonwiki should show about a 30% improvement,
tabl_mozilla about 40%, and one very long page from my
personal suite, askmefast.com, gets 5x faster.
(The performance changes are not the point of the CL, but
something we should be aware of.)
BUG=
R=bsalomon@google.com, mtklein@google.com, robertphillips@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/497493003
--key describes the type of run (describes the line on the chart), --properties
describes the run itself (describes the dot on the chart).
We'll pass --properties gitHash <git hash> build_number <build number> --key
... to nanobench from the bots.
And... delete a whole lot of dead code.
Example: nanobench --properties gitHash foo build_number 1234 --key bar baz
{
"build_number" : "1234",
"gitHash" : "foo",
"key" : {
"bar" : "baz"
},
"results" : {
....
Friends with https://codereview.chromium.org/491943002
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/488213002
Share command flags between dm and unit tests.
Also, allow dm's core to be included by itself and iOSShell.
Command line flags that are the same (or nearly the same) in DM
and in skia_tests have been moved to common_flags. Authors,
please check to see that the shared common flag is correct for
the tool.
For iOS, the 'tool_main' entry point has a wrapper to allow multiple
tools to be statically linked in the iOSShell.
Since SkCommandLineFlags::Parse can only be called once, these calls
are disabled in the IOS build.
Since the iOS app directory is dynamically assigned a name, use '@' to
select it. (This is the same convention chosen by the Mobile Harness
iOS file system utilities.)
Move the heart of dm.gyp into dm.gypi so that it can be included by
itself and iOSShell.gyp.
Add tools/flags/SkCommonFlags.* to define and declare common
command line flags.
Add support for dm to iOSShell.
BUG=skia:
R=scroggo@google.com, mtklein@google.com, jvanverth@google.com, bsalomon@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/389653004
We're moving away from BigQuery for storing results so the output doens't have to conform to BQ requirements, which allows simplifying the format. Also stop parsing the filename for information and pass in buildbot parameters explicitly.
Adds the following flags to nanobench:
--key
--gitHash
BUG=skia:
R=mtklein@google.com, bsalomon@google.com
Author: jcgregorio@google.com
Review URL: https://codereview.chromium.org/392393002
This seems to be ~100x higher resolution than QueryPerformanceCounter. AFAIK, all our Windows perf bots have constant_tsc, so we can be a bit more direct about using rdtsc directly: it'll always tick at the max CPU frequency.
Now, the question remains, what is the max CPU frequency to divide through by? It looks like QueryPerformanceFrequency actually gives the CPU frequency in kHz, suspiciously exactly what we need to divide through to get elapsed milliseconds. That was a freebie.
I did some before/after comparison on slow benchmarks. Timings look the same. Going to land this without review tonight to see what happens on the bots; happy to review carefully tomorrow.
R=mtklein@google.com
TBR=bungeman
BUG=skia:
Review URL: https://codereview.chromium.org/394363003
