Angle's existing GN files only work in Chrome, so I've written a new one.
This won't work on Windows, but our GN build doesn't work on Windows anyway. So this CL is an attempt to get a ahead of that curve on ANGLE. It looks large but fairly straightforward.
Now working on Linux:
$ gn gen angle --args=skia_use_angle=true
$ ninja -C angle
$ angle/dm --config angle-gl --src gm -w dm-out
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2361983002
Review-Url: https://codereview.chromium.org/2361983002
Uh, so hey, I just noticed that while the CommandBuffer Test bot runs
with --config commandbuffer, the Perf bot just runs as a vanilla GPU bot.
Shouldn't we pass --config commandbuffer?
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2364483002
CQ_INCLUDE_TRYBOTS=master.client.skia:Perf-Mac-Clang-MacMini6.2-GPU-HD4000-x86_64-Debug-CommandBuffer-Trybot
Review-Url: https://codereview.chromium.org/2364483002
(The failing NexusPlayer bot is a demo.)
This should make stack traces more useful, turning this sort of thing
09-20 11:29:39.536 2978 2978 F DEBUG : #00 pc 00970fd0 /data/local/tmp/dm
into something like this
09-20 11:29:39.536 2978 2978 F DEBUG : #00 pc 00970fd0 adjust_bounds_to_granularity(SkIRect*, SkIRect const&, VkExtent2D const&, int, int) at /b/work/skia/out/Build-Ubuntu-Clang-x86-Debug-GN_Android_Vulkan/Debug/../../../src/gpu/vk/GrVkGpu.cpp:1803 /data/local/tmp/dm
Some bots like the S7 already have good enough stack traces, e.g.
09-20 11:35:12.567 936 936 F DEBUG : #00 pc 00000000000bed6c /system/vendor/lib64/hw/vulkan.msm8996.so (_ZN13QglManagedBuf14ConfirmEntriesEv+108)
09-20 11:35:12.567 936 936 F DEBUG : #01 pc 00000000000b098c /system/vendor/lib64/hw/vulkan.msm8996.so (_ZN9QglBltLib6FillHwEPK10QglBltFillPK15QglBltColorFillPK15QglBltDepthFillPjP12QglBltStatusSB_+588)
09-20 11:35:12.567 936 936 F DEBUG : #02 pc 00000000000b23bc /system/vendor/lib64/hw/vulkan.msm8996.so (_ZN9QglBltLib9FillImageEPK10QglBltFillPK15QglBltColorFillPK15QglBltDepthFillPjP12QglBltStatusSB_+348)
09-20 11:35:12.567 936 936 F DEBUG : #03 pc 000000000009bb00 /system/vendor/lib64/hw/vulkan.msm8996.so (_ZN16A5xCommandBuffer22PerformConditionalFillEiiP10QglBltFillPK15QglBltColorFillP15QglBltDepthFillP12QglBltStatusS8_+256)
09-20 11:35:12.567 936 936 F DEBUG : #04 pc 000000000009c0c0 /system/vendor/lib64/hw/vulkan.msm8996.so (_ZN16A5xCommandBuffer23HwWriteSubpassInitClearEP10QglBltFillPK15QglBltColorFillP15QglBltDepthFillP12QglBltStatusS8_+224)
09-20 11:35:12.567 936 936 F DEBUG : #05 pc 0000000000072610 /system/vendor/lib64/hw/vulkan.msm8996.so (_ZN16QglCommandBuffer18WriteSubpassClearsEv+464)
09-20 11:35:12.567 936 936 F DEBUG : #06 pc 0000000000073ae0 /system/vendor/lib64/hw/vulkan.msm8996.so (_ZN16QglCommandBuffer12BeginSubpassEv+32)
09-20 11:35:12.567 936 936 F DEBUG : #07 pc 0000000000063120 /system/vendor/lib64/hw/vulkan.msm8996.so (vkCmdBeginRenderPass+224)
09-20 11:35:12.567 936 936 F DEBUG : #08 pc 0000000000635f60 /data/local/tmp/nanobench (_ZN24GrVkPrimaryCommandBuffer15beginRenderPassEPK7GrVkGpuPK14GrVkRenderPassjPK12VkClearValueRK16GrVkRenderTargetRK7SkIRectb+132)
or
09-20 11:42:24.557 937 937 F DEBUG : backtrace:
09-20 11:42:24.557 937 937 F DEBUG : #00 pc 0000000000069404 /system/lib64/libc.so (tgkill+8)
09-20 11:42:24.557 937 937 F DEBUG : #01 pc 0000000000066b94 /system/lib64/libc.so (pthread_kill+68)
09-20 11:42:24.557 937 937 F DEBUG : #02 pc 0000000000023a28 /system/lib64/libc.so (raise+28)
09-20 11:42:24.557 937 937 F DEBUG : #03 pc 000000000001e358 /system/lib64/libc.so (abort+60)
09-20 11:42:24.557 937 937 F DEBUG : #04 pc 000000000076430c /data/local/tmp/dm (_Z17sk_abort_no_printv+8)
These won't be affected.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2351243002
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2351243002
Android API >= 24 implies Vulkan support, so we can have a more useful default here than 'false'. If for some reason you wanted to turn it off, you can still override skia_use_vulkan.
The defined(ndk_api) guards other users of our GN files (Fuchsia) who may not have an ndk_api argument defined in their BUILDCONFIG.gn.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2347843003
Review-Url: https://codereview.chromium.org/2347843003
These were intended to prevent GN and GYP Android bots from stomping on
each other. Turns out, they don't, even without this... they're writing
most files to completely separate paths:
- GYP puts most data under $EXTERNAL_STORAGE, generally /sdcard
and its binaries (libdm.so, libnanobench.so, libskia.so, skia_launcher)
in /data/local/tmp;
- GN puts everything under /data/local/tmp, and its binaries (dm, nanobench)
don't overlap GYP's.
So clearing /data/local/tmp was essentially just removing GN's data; GYP's
data file caching was never affected and can't conflict with GN's.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2340473002
Review-Url: https://codereview.chromium.org/2340473002
Just to take inventory of which old problems still linger and which are now moot, I've gone out of my way to have this stand alone. All of gn_android_flavor's logic is self contained, without any dependency on the platform_tools scripts.
The tricky bits turn out to be, copying directories containing symlinks---or really any copying involving more than one file---and getting the exit code back from adb shell. Luckily the ADB I've got on my desktop and my Nexus 5x seems to handle this all without the awkward workarounds you see here, so there's hope that One Day Soon the weird parts (basically, anything with inline python) can go away. Once we've got these bots landed green, I'll go see whether the fixes are due to ADB updates, Android updates, or perhaps something else like hardware.
The parts marked TEMPORARY are a nod to the fact that the devices are used by gn_android_flavor and android_flavor both today. It's mostly about not stepping on each other's toes or leaving anything laying around that might confuse each other. The marked parts can go away when bots are either gn_ or non-gn_ but not both.
I have omitted a few steps that may be important, but which are easy independent follow-ups:
- running as root
- locking clocks
- waiting on battery levels
- fancier wait-for-ready than adb wait-for-usb-device
It'd be nice to, e.g., reaffirm that locking clocks helps perf stability, and that we're locking to the best policy. I've tried to keep this CL as trim as possible, leaving any of these vaguely optional steps for later.
As of PS 41 or so, it looks like the trybots are all behaving as expected.
We should expect no new images in Gold. Can we see trybots in Perf yet?
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2320153002
CQ_INCLUDE_TRYBOTS=master.client.skia.android:Perf-Android-Clang-AndroidOne-CPU-MT6582-arm-Debug-GN_Android-Trybot,Perf-Android-Clang-AndroidOne-CPU-MT6582-arm-Release-GN_Android-Trybot,Perf-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Debug-GN_Android-Trybot,Perf-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Release-GN_Android-Trybot,Test-Android-Clang-AndroidOne-CPU-MT6582-arm-Debug-GN_Android-Trybot,Test-Android-Clang-AndroidOne-CPU-MT6582-arm-Release-GN_Android-Trybot,Test-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Debug-GN_Android-Trybot,Test-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Release-GN_Android-Trybot
Review-Url: https://codereview.chromium.org/2320153002
Attempt to take over all *SAN builds.
MSAN has a lot of coordination required between gn/BUILD.gn and gn_flavor.py.
I'd like to follow up to move more of this into gn/BUILD.gn, to make it easier
to use locally.
The compile steps should be much faster now. We no longer build CMake
and Clang for every run, instead using the clang_linux CIPD package. This
removes the need for all the third_party/externals/llvm/... dependencies.
Similarly, since we're using the clang_linux package, we no longer depend
on Chrome's Clang, and thus no longer need to sync chromium on these bots.
Instead of packaging up MSAN libraries and llvm-symbolizer in the compile
output, I have the test / perf bots also depend on the clang_linux package.
These do not vary from build to build.
No more need for the xsan.blacklist -include hack: Clang, GN, and Ninja
all track changes to xsan.blacklist without our help.
This has the incidental effect of upgrading the compiler used by *SAN
bots from Clang 3.8 to Clang 3.9.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2289343002
Review-Url: https://codereview.chromium.org/2289343002
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
I just burned 2 days debugging a confusing interaction between ccache
and the -fsanitize-blacklist argument to Clang. Let's see if we can
live without ccache (swarming affinity + Ninja seems pretty decent).
As a point of reference, the Mac bots have been looking for ccache but
failing to find it. They're proof this will be fine.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2310063003
Review-Url: https://codereview.chromium.org/2310063003
I am hoping this makes it easier to get *SAN bots going.
Today we're generating a libcompiler_rt.a that's using a
relocation type that the ld on the bots doesn't know about.
This lld is will know about anything our Clang generates.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2301273002
Review-Url: https://codereview.chromium.org/2301273002
The remaining suppression (libwebp) is already covered by the
compile-time blacklist, tools/xsan.blacklist.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300193002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Release-TSAN-Trybot,Test-Ubuntu-Clang-Golo-GPU-GT610-x86_64-Release-TSAN-Trybot
Review-Url: https://codereview.chromium.org/2300193002
This ought to support compiles for now.
Am I picking up my CIPD ndk packages right?
The main thing to note is that I'm passing the target_arch directly through
as target_cpu. This means these bots will have a slightly different naming
convention than we've been using, but it'll agree with what you must type
yourself when using GN to build for Android:
- Arm7 -> arm
- Arm64 -> arm64
- Mips -> mipsel
- Mips64 -> mips64el
- x86 -> x86 (unchanged)
- x86_64 -> x64
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2292663002
Review-Url: https://codereview.chromium.org/2292663002
This makes it considerably easier to use ccache with the Android NDK.
You can now just set
compiler_prefix = "ccache"
ndk = "/path/to/ndk"
and we'll use the NDK clang, wrapped with ccache.
The name compiler_prefix is stolen from / compatible with Chrome.
If you have ccache, you can just always leave compiler_prefix="ccache" enabled.
This should make it an unusual thing for humans to have to change cc or cxx.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2281163002
Review-Url: https://codereview.chromium.org/2281163002
Also:
* Pass through a new property 'patch_storage' to DM/Nanobench/Coverage. This will be used by the different frameworks to figure out if it is Rietveld or Gerrit issue.
* Calculate issue and patchset for Gerrit patches similar to Rietveld.
BUG=skia:5627
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2263323002
Review-Url: https://codereview.chromium.org/2263323002
This shouldn't change any behavior except that the stores to dst
will no longer require 8-byte alignment.
Empirically it seems like we can use 4-byte alignment here,
but u8 (i.e. 1-byte alignment) is always safe.
BUG=skia:5637
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2264103002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2264103002
Adding flags to the end of cc or cxx is pretty useful, but these always end up
on the command line before the GN generated flags, thus setting defaults that
GN will override.
For full flexibility we want to be able to add flags after the flags GN has
added, so that custom flags can override _it_.
I've updated the Fast bots with an example here: if we said cc="clang -O3 ...",
that '-O3' would be overriden later by the default Release-mode '-Os'. By
putting it in extra_cflags, we get the last word: our '-O3' overrides the
default '-Os'.
Another good use case is a hypothetical Actually-Shippable-Release mode. Our
Release mode bundles in tons of debug symbols via '-g'. libskia.a is about 10x
larger than it needs to be when built that way, but it helps us debug the bot
failures immensely. To build a libskia.{a,so} that you'd really ship, you can
now set extra_cflags="-g0" to override '-g'. You could set '-march' flags there
too, '-fomit-frame-pointer', etc.
There are lots of flags that won't matter where they end up in the command line.
To keep everything simple I've put them in extra_cflags with the rest. This means
the only time we change 'cc' or 'cxx' in our recipes is to prefix 'ccache'.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2241263003
Review-Url: https://codereview.chromium.org/2241263003
