For internal hardware, it tends not to work - they work at one
clock speed, despite advertising others.
Bug: skia:
NOTRY=true
Change-Id: I10bf0fc1ab4d60bfbc2eefcef5b42ceab9e3f435
Reviewed-on: https://skia-review.googlesource.com/76720
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Bug: skia:
NOTRY=true
Change-Id: I1a1755dd03f2e6ebd8d9b2c9235cca8eb34f04ad
Reviewed-on: https://skia-review.googlesource.com/75280
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
This also makes *sure* the CPU frequency we set the
device to actually "takes". Along the way, I learned
if scaling_max_freq is < the frequency we set, the
scaling_max_freq will be used instead, which was
happening to the PixelCs and AndroidOnes.
As a result, this may make those two Test- configs faster.
Bug: skia:
Change-Id: I10c98d37e296a19e1cf67bfe7269bb59cdd912d5
Reviewed-on: https://skia-review.googlesource.com/74360
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: skia:
Change-Id: I994f67c3043306d7fa612feb03f8fbe8d7bf4c91
Reviewed-on: https://skia-review.googlesource.com/73760
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
a.k.a. GM fontpocalypse
Change-Id: If834940574adea29b48f35abec61f0a1c9bd59d3
Reviewed-on: https://skia-review.googlesource.com/69881
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The latest OS is Lollipop, and it was originally released November 2012.
The GPU is not in the top 26 according to UMA stats (I haven't collected
data for lower than 26). We test the same GPU with the
Chromebook_303C12, and bsalomon says "Personally, I'm OK with just
relying on ChromeOS for testing."
No-Try: true
Change-Id: Ib17033153faab9d99613e7d2d069524c9435f65e
Reviewed-on: https://skia-review.googlesource.com/64066
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
The first "sharding" technique we will try is just by test config
(e.g. 8888, gles, etc). Thus, for backwards compatibility,
the default "shard" is All, as in all configs
Bug: skia:
NOTRY=true
Change-Id: Ia02362477a5d97f8f74d688b5f0c4f45fc129375
Reviewed-on: https://skia-review.googlesource.com/59563
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
The newer adb acts more like cp when pulling. We used to
create the dm folder on the host machine before pulling.
This used to be fine,
/device/dm_out/dm.json -> /host/dm/dm.json
However, with the update, adb would do
/device/dm_out/dm.json -> /host/dm/dm_out/dm.json
This breaks the upload step. To make this transition
a smooth one, /usr/bin/adb on the RPI is staying the same
(for a while, at least) and /usr/bin/adb.1.0.35 is being added.
That way we can use the new adb on tests after this commit, but
when we backfill, we don't break because of the unexpected folder.
Bug: skia:
Change-Id: Icbed38594fca0e17af1f8d01d75c42ce03f710b9
Reviewed-on: https://skia-review.googlesource.com/58880
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: skia:
NOTRY=true
Change-Id: I2a774ca2533572eaf284101cd6ea11b816c1441a
Reviewed-on: https://skia-review.googlesource.com/47080
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
