I have text_16_AA_FF -> 8888 (forcing RP) faster than head now on my
laptop. I'm feeling confident that we can make this perform well.
After looking at performance a bit more today, it looks like everything
is within what I'd consider comparable in performance, especially on
ARM. On x86-64 it looks like big bulk blits get a little slower and
small mask blits get a little faster.
Quality looks good, and maybe improved for 565.
There are fewer platform-specific differences now in _lowp, and I think
they're few enough now that we could even consider completing the
unification by folding the 8-bit and float code together. Rename
"div255()" to "rebias()", slap on a few coats of paint...
Guarded for Chrome with SK_JUMPER_LEGACY_LOWP.
Change-Id: I36309c07cf736f3cb31952cca66030ad56026318
Reviewed-on: https://skia-review.googlesource.com/45982
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit c576e93d17.
Reason for revert: ASAN failures
Original change's description:
> Switch to the new SkSL lexer.
>
> This completely replaces flex with a new in-house lexical analyzer generator,
> which we have done for performance and memory usage reasons. Flex requires us
> to copy strings every time we need the text of a token, whereas this new lexer
> allows us to handle strings as a (non-null-terminated) pointer and length
> everywhere, eliminating most string copies.
>
> Bug: skia:
> Change-Id: I2add26efc9e20cb699520e82abcf713af3968aca
> Reviewed-on: https://skia-review.googlesource.com/39780
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
TBR=bsalomon@google.com,ethannicholas@google.com
Change-Id: If27b750a5f696d06a6bcffed12fe9f0598e084a6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/44881
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This completely replaces flex with a new in-house lexical analyzer generator,
which we have done for performance and memory usage reasons. Flex requires us
to copy strings every time we need the text of a token, whereas this new lexer
allows us to handle strings as a (non-null-terminated) pointer and length
everywhere, eliminating most string copies.
Bug: skia:
Change-Id: I2add26efc9e20cb699520e82abcf713af3968aca
Reviewed-on: https://skia-review.googlesource.com/39780
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This lets us open & close groups and automates the hierarchy.
Change-Id: Ib6f0850a49b793d824fc25aa16be78e6a1a93d9e
Reviewed-on: https://skia-review.googlesource.com/43280
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: Iecf034feaa009002b5f09c47052c915d22aec0e4
Reviewed-on: https://skia-review.googlesource.com/43040
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: I4086a17eafecccaf0bac34c850c249a5e4efc719
Reviewed-on: https://skia-review.googlesource.com/42524
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: I06e6b63c2742da069f48ff5d7defafc63a485af7
Reviewed-on: https://skia-review.googlesource.com/41842
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bug: skia:
Change-Id: Ic8b25ca2ecf51cfc190ac01bc9282396905a33b3
Reviewed-on: https://skia-review.googlesource.com/40862
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
It turns out that Skia's gn 'system' and 'third_party' templates differ
in the way public defines are declared. This also updates the build to
add libdl when building SkOSLibrary_posix.cpp, since that uses dlsym.
The current build depends on icu bringing in this dependency.
BUG=skia:7008
Change-Id: Ia710a335e1da9580f85f133a5a171f640b36ee75
Reviewed-on: https://skia-review.googlesource.com/41745
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
Change-Id: Ib8f4d6c41356cf0fe2e14b7bff7713d107eaa01f
Reviewed-on: https://skia-review.googlesource.com/40687
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Change-Id: I97a844b2f289d2518f60a64f94d60551c4530dd4
Reviewed-on: https://skia-review.googlesource.com/35742
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit c667dff58d.
Reason for revert: temporary while I fix Android, Google3.
Original change's description:
> Turn on exceptions in test tools.
>
> This allows us to test things that, e.g., throw std::bad_alloc.
>
> Change-Id: I6409159b89f1d93d403b1a1f40539cf2531a8b68
> Reviewed-on: https://skia-review.googlesource.com/34982
> Reviewed-by: Herb Derby <herb@google.com>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,herb@google.com
Change-Id: Iafdc34c5f70f99f7df3cd0bbad65eed0828453a1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/35081
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This allows us to test things that, e.g., throw std::bad_alloc.
Change-Id: I6409159b89f1d93d403b1a1f40539cf2531a8b68
Reviewed-on: https://skia-review.googlesource.com/34982
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I'm betting big on ok bench. This is a forcing function.
Change-Id: I8c359b7d712e16f8f0cbb90591801e0014073288
Reviewed-on: https://skia-review.googlesource.com/33660
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This new source acts like other sources (GMs, SKPs) for benchmarks. It
times multiple samples (controlled by samples=N, default 20), and each
of those samples uses the same strategy as monobench, growing loops
exponentially until it runs for at least 10ms.
When done it prints the fastest and the two slowest samples. In
practice the 100th percentile sample is very different from the
next slowest due to caching, and the fastest is always interesting.
Because these benchmarks run in whatever execution engine ok has
selected, on non-Windows platforms you have some real control over the
interaction between benchmarks. In its default "fork" mode each
benchmark runs independently in its own process, so the 100th
percentiles really stand out. The other modes "thread" and "serial"
work as you'd expect too.
Here's an example where you can see how the different interactions work:
out/ok bench:samples=100 8888 filter:search=text_16_AA fork
[text_16_AA_WT] 2.32µs @0 6.23µs @99 24.3ms @100
[text_16_AA_FF] 2.41µs @0 5.7µs @99 23.3ms @100
[text_16_AA_88] 2.55µs @0 5.6µs @99 24.8ms @100
[text_16_AA_BK] 1.97µs @0 5.44µs @99 23.2ms @100
out/ok bench:samples=100 8888 filter:search=text_16_AA thread
[text_16_AA_FF] 2.45µs @0 23.5µs @99 24.8ms @100
[text_16_AA_WT] 2.52µs @0 17.8µs @99 24.7ms @100
[text_16_AA_88] 2.55µs @0 19.7µs @99 25.1ms @100
[text_16_AA_BK] 1.8µs @0 14.7µs @99 25.1ms @100
out/ok bench:samples=100 8888 filter:search=text_16_AA serial
[text_16_AA_88] 2.35µs @0 3.53µs @99 16.7ms @100
[text_16_AA_FF] 2.09µs @0 2.73µs @99 2.91µs @100
[text_16_AA_BK] 1.75µs @0 2.46µs @99 2.65µs @100
[text_16_AA_WT] 2.1µs @0 3.16µs @99 3.17µs @100
In the first "fork" case all runs are independent and have roughly
the same profile. "thread" looks similar except you can see them
contending at the 99th percentile. In "serial", the first bench
warms up the rest, so their 100th percentiles are all much faster.
Change-Id: I01a9f8c54b540221a9f232b271bb8ef3fda2569c
Reviewed-on: https://skia-review.googlesource.com/33585
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I think we can replace a lot of legacy code with an SkRasterPipeline
backend that works in 8-bit and stays interlaced. Think of this as a
"lowerp" replacement for lowp.
I'm having some trouble getting ARMv8 working.
ARMv7 should be fine, but I want to turn it on separately from x86.
I haven't looked at 32-bit x86 yet, but that's also on the todo list.
Open questions to follow up on:
- is it better to fold every multiply back down to 8-bit
(as seen here), or to allow intermediates to accumulate
in 16-bit and divide by 255 when done/needed?
- is it better pass tightly packed 8-bit vectors between stages (as
seen here), or to keep the 8-bit values unpacked in 16-bit lanes?
- should we make V wider than 1 register?
GMs look good. All diffs invisible and plausibly due to the 15->8 bit
precision drop. A quick bench run showed this running in about 0.75x
the time of the existing lowp backend.
Change-Id: I24aa46ff1d19c0b9b8dc192d5b1821cab0b8843c
Reviewed-on: https://skia-review.googlesource.com/29886
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Add a private API used by Android framework, which writes the clip
into a stencil buffer. This is used by HWUI to clip the WebView.
Bug: 31489986
Change-Id: I94515f1539acd9d069c8aceb3300577feed9c94f
Reviewed-on: https://skia-review.googlesource.com/29521
Commit-Queue: Stan Iliev <stani@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
1) Run python bin/fetch-clang-win
2) Set clang_win = "../bin/clang_win"
3) ???
4) Profit
Most changes here are to pass the right -mfoo flags to Clang
to enable advanced instruction sets, or fixed warning-as-errors.
BUG=skia:2679
Change-Id: Ieed145d35c209131c7c16fdd3ee11a3de4a1a921
Reviewed-on: https://skia-review.googlesource.com/28740
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
bookmaker is a tool that generates documentation
backends from a canonical markup. Documentation for
bookmaker itself is evolving at docs/usingBookmaker.bmh,
which is visible online at skia.org/user/api/bmh_usingBookmaker
Change-Id: Ic76ddf29134895b5c2ebfbc84603e40ff08caf09
Reviewed-on: https://skia-review.googlesource.com/28000
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
The bot was broken in https://skia-review.googlesource.com/c/27800/
Depot Tools' version is just a wrapper which looks for clang-format
under buildtools, which doesn't exist on the bots.
Bug: skia:6893
Change-Id: I32ae6c358735c9971e533064aa50a0e0520dd05a
Reviewed-on: https://skia-review.googlesource.com/28020
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Change-Id: I3e993e271cb5e26816d37c70d9ad62acce3ed84c
Reviewed-on: https://skia-review.googlesource.com/27800
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This makes Engines (task execution strategies: serial, thread, fork)
pluggable just like most of the rest of ok. It removes the thread and
process limits, as I find myself rarely caring about what they are
exactly. Instead of limiting to num-cores, we just allow any number of
concurrent threads, and any number of concurrent child processes subject
to OS limitations.
Change-Id: Icef49d86818fe9a4b7380efb60e73e40bc2e6b73
Reviewed-on: https://skia-review.googlesource.com/27140
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This also updates create_test_font so that it can be built, compiles,
and uses SkFontStyle instead of SkTypeface::Style.
BUG=b/63669723
Change-Id: I6eb0f851853f4721cf8e5052255b5b6750c3257f
Reviewed-on: https://skia-review.googlesource.com/24740
Reviewed-by: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Not yet thread safe (so it forces threading off).
Builds JSON on the fly, so overhead is certainly bad.
Plan to fix all of that, but this at least "works".
There is now one tracing flag: 'trace'.
- 'debugf' installs the SkDebugf tracer.
- 'atrace' installs the Android ATrace tracer.
- Any other value is interpreted as a filename, and
produces a JSON file for chrome://tracing.
All three modes work in DM, nanobench, and Viewer.
Bug: skia:
Change-Id: I3fbc22382b99418a508c670be2770195c0a1c364
Reviewed-on: https://skia-review.googlesource.com/24781
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Debian9-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Bug: skia:
Change-Id: If6f0d0a57463bf99a66d674e65a62ce3931d0116
Reviewed-on: https://skia-review.googlesource.com/24644
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Also adds more trace events to GPU backend.
Change-Id: Ifa5f0cd4b1fd582f0cc30d37d9e6414dc498c75d
Reviewed-on: https://skia-review.googlesource.com/24622
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Also adds the support code to allow our TestContext to create a Metal
backend.
Bug: skia:
Change-Id: Ia850687019d79b897bb16e2c151f4f8526721ad9
Reviewed-on: https://skia-review.googlesource.com/22644
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This is mainly for getting ready to start adding lots of metal backend code.
I've also update the "gpu tools" target to require ARC with involved updating
one IOS file in there.
Bug: skia:
Change-Id: Ied22e8fe7532445cc274efb529e3450654a6614b
Reviewed-on: https://skia-review.googlesource.com/22484
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Remove #defines that lived in gn_to_bp.py and
android_framework_defines.gni. These have been moved into a new file
in Android, SkUserConfigManual.h, in https://googleplex-android-review.git.corp.google.com/#/c/2519600/
Update gn_to_bp.py to include SkUserConfigManual.h, so it will still
result in using the same #defines.
Lately, we've found it difficult to guard changes behind a flag. e.g.
a change to drawing causes a CTS failure in Android, so we have to do
the following:
- put the change behind a flag, and add it to gn_to_bp.py or
android_framework_defines.gni
- generate new images on Android (by running CTS with external/skia
modified to not define the flag)
- create a CL in CTS that uses the new images
- land a CL in Skia that stops defining the flag
- when the Skia change lands, wait for the auto-roller to create a CL
that includes the change, stop the auto-roller, add the topic to the CTS
CL so the two can land at the same time
- land both Android changes (with TreeHugger)
- restart the Android auto-roller
With SkUserConfigManual.h (which lives in Android), the process will
be similar to Chromium:
- land a CL in Android's external/skia that defines a flag e.g.
SK_SUPPORT_LEGACY_FEATURE. Land without TreeHugger because it isn't used
in Skia and does not do anything
- land a change in Skia that changes behavior unless
SK_SUPPORT_LEGACY_FEATURE is defined. This will safely go through the
Android roll and not change any behavior for Android
- create two Android CLs - one in CTS to use the new images, and one in
external/skia to delete SK_SUPPORT_LEGACY_FEATURE. Set them to the same
topic and land them with TreeHugger
In the new process, there is no need to mess with the Android roll.
A downside to the new process is that we cannot test the android
framework defines without checking in to Android. But given how much
we've progressed in automating Android testing, this is fine.
Bug: b/63429612
Change-Id: Idfbaef2f4cae641a75fb6e7bf70428733a441336
Reviewed-on: https://skia-review.googlesource.com/22072
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Also updates SDL to 2.0.5.
Change-Id: I3a3c8f69360fc20a3d543c19dcf82dd3f42f1309
Reviewed-on: https://skia-review.googlesource.com/22204
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Fixes build of Skia lib when GR_TEST_UTILS=0
Makes GR_TEST_UTILS=0 for official builds
Makes "Mini" builder bot exercise building GPU with is_official_build=true
Bug: skia:6786
Change-Id: I6186683a3a216d2e779645bd9e8276a66bcff4d5
Reviewed-on: https://skia-review.googlesource.com/21524
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: Iddeeb91b378bdb61d200070d8faa3610299ab733
Reviewed-on: https://skia-review.googlesource.com/21533
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
I _think_ this makes it so changes to _stages.cpp or _lowp.cpp get
noticed, regenerated, and baked into Skia all in the same Ninja
invocation.
Now you just need to set up the tools we use in GN:
skia_jumper_clang = ...
skia_jumper_objdump = ...
skia_jumper_ccache = ...
Change-Id: I09fb54d965644ff6e5825056fb0be2c7cab2ea92
Reviewed-on: https://skia-review.googlesource.com/21140
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit c070939fd1.
Reason for revert:
This has some knock-on effects in the generation of Android.bp from our GN files. See gn/gn_to_bp.py? We're seeing things like "tmp/tmpsBVycx/gen/" end up in the include search path in Android.bp, which obviously don't exist there...
Original change's description:
> Re-land sksl fragment processor support
>
> This reverts commit ed50200682.
>
> Bug: skia:
> Change-Id: I9caa7454b391450620d6989dc472abb3cf7a2cab
> Reviewed-on: https://skia-review.googlesource.com/20965
> Reviewed-by: Ben Wagner <benjaminwagner@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
TBR=benjaminwagner@google.com,ethannicholas@google.com
Change-Id: I502486b5405923b322429219f4cc396a45a14cea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/20990
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
