--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
drawPatch now receives as parameter const SkPoint cubics[12]
Adjusted derived classes and serialization.
Ajusted GM's and benches that take into account combinations of optional
parameters, the scale of the patch and 4 different types of patches.
Planning on adding the extra functionality of SkPatch in another CL.
BUG=skia:
R=egdaniel@google.com, reed@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/463493002
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
Reason for revert:
possible test and gm failures
Original issue's description:
> Remove gpu shader optimatization for solid white or trans black colors
>
> Running test on the added bench which draws a grid of all white paths, all blue paths, or alternating checkered white/blue paths.
>
> With optimization in (ms):
> White Blue Checkered
> Linux ~80 ~80 ~160
> N7 ~800 ~1100 ~1500
> Moto-e ~830 ~1100 ~2500
>
> Without optimization in (ms):
> White Blue Checkered
> Linux ~80 ~80 ~80
> N7 ~1100 ~1100 ~1100
> Moto-e ~1100 ~1100 ~1500
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/5f78d2251a440443c9eaa321dad058d7a32bfef7R=bsalomon@google.comTBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/385163004
Running test on the added bench which draws a grid of all white paths, all blue paths, or alternating checkered white/blue paths.
With optimization in (ms):
White Blue Checkered
Linux ~80 ~80 ~160
N7 ~800 ~1100 ~1500
Moto-e ~830 ~1100 ~2500
Without optimization in (ms):
White Blue Checkered
Linux ~80 ~80 ~80
N7 ~1100 ~1100 ~1100
Moto-e ~1100 ~1100 ~1500
BUG=skia:
R=bsalomon@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/375823005
