This skp started causing
Perf-Debian10-EMCC-GCE-CPU-AVX2-wasm-Release-All-Puppeteer_RenderSKP
to timeout.
Change-Id: I248b4be8f2287ecb16969f71f985acd794bd8d11
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/390298
Reviewed-by: Ravi Mistry <rmistry@google.com>
This picks up a new version of the CIPD deps and a new helper for
writing task drivers.
Bug: skia:10812
Change-Id: I8b9b57acd4d8eee9cdea86008da1f3039af0cdc9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/328496
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Also add a skiplist to bypass a skp that is (hopefully temporarily)
timing out.
Change-Id: I912bd901a985ae86adfed13db102a1e7fee5686a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/320060
Reviewed-by: Kevin Lubick <kjlubick@google.com>
For each skp in the corpus, we start a fresh instance of
Chromium (via puppeteer), draw the skp and measure that time.
This process is repeated a fixed amount of repetitions
and the median, the average, and the std deviation is reported
to perf (as well as the individual datapoints as an FYI).
Importantly (and something we'll need to change about
SkottieFrames), we measure the average time between frames
after unlocking the framerate. This ensures we account for
the time needed by the GPU to actually draw (flush() returns
after the GPU has all the instructions, but not necessarily
has been able to draw).
This implementation is very similar to the SkottieFrames
code; a notable deviation is the repetitions are handled
outside of the html, i.e. a new chrome window per run.
I explored using content_shell, but noticed that requires
building Chromium, which our infrastructure is not set up
to do well.
Change-Id: I14fdbdc951604d3fdf06e81a4be7e614d0e53c03
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295079
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
