Bug: skia:
Change-Id: I5b31e0c74be8f650e97c448b1029a2277dfee978
Reviewed-on: https://skia-review.googlesource.com/41844
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This is to set up for allocating additional texture proxies as needed.
Change-Id: Ibc0480c30d8efd6ccf8278f6dbdd3bfa3ee2397d
Reviewed-on: https://skia-review.googlesource.com/41744
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
fa08cae7ca..561ed3aeb0
$ git log fa08cae7c..561ed3aeb --date=short --no-merges --format='%ad %ae %s'
2017-08-31 jmadill D3D: Keep a single dirty bit for uniforms.
2017-08-31 jmadill GLES3: Use more compact entry point style.
Created with:
roll-dep skia/third_party/externals/angle2
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls
CQ_INCLUDE_TRYBOTS=skia.primary:Perf-Win10-MSVC-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-ANGLE,Perf-Win10-MSVC-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-ANGLE,Perf-Win10-MSVC-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-ANGLE,Perf-Win10-MSVC-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-ANGLE,Perf-Win10-MSVC-ShuttleC-GPU-GTX960-x86_64-Debug-ANGLE,Perf-Win10-MSVC-ZBOX-GPU-GTX1070-x86_64-Debug-ANGLE,Test-Win10-MSVC-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-ANGLE,Test-Win10-MSVC-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-ANGLE,Test-Win10-MSVC-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-ANGLE,Test-Win10-MSVC-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-ANGLE,Test-Win10-MSVC-ShuttleC-GPU-GTX960-x86_64-Debug-ANGLE,Test-Win10-MSVC-ZBOX-GPU-GTX1070-x86_64-Debug-ANGLE
TBR=djsollen@google.com
Change-Id: I5438ec7781495b763a2214090d14692a18087439
Reviewed-on: https://skia-review.googlesource.com/41621
Reviewed-by: angle-deps-roller . <angle-deps-roller@chromium.org>
Commit-Queue: angle-deps-roller . <angle-deps-roller@chromium.org>
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>
These are transient, so need to be copied.
Bug: skia:
Change-Id: Id24db0b96f343ecd034dd015da6e19ea61579b56
Reviewed-on: https://skia-review.googlesource.com/41741
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:
Change-Id: I10ddc36f39800e3d86145054b994a6899573a63a
Reviewed-on: https://skia-review.googlesource.com/41501
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Also add new paragraph about using systrace correctly
Docs-Preview: https://skia.org/?cl=41502
Change-Id: I114c14cc2e87a8b72aec46d8c354d3ea877a41ab
Reviewed-on: https://skia-review.googlesource.com/41502
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reimplemnet the original interpolating code. Moving from the
integer blur code to this code is controled by the flag:
SK_LEGACY_SUPPORT_INTEGER_SMALL_RADII
BUG=chromium:759273
Change-Id: I17205d704a0cae68a8a027c6bb235f81b5c62e24
Reviewed-on: https://skia-review.googlesource.com/41082
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Herb Derby <herb@google.com>
Bug: skia:
NOTRY=true
Change-Id: Ib604bad8eda6ba4382b850f7c5f318fb0f114401
Reviewed-on: https://skia-review.googlesource.com/20051
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Change-Id: Iadcae79f7b295a3bedd33b4a93734547665f2a5d
Reviewed-on: https://skia-review.googlesource.com/41380
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
d28758de2d..0abb7a2a26
$ git log d28758de2..0abb7a2a2 --date=short --no-merges --format='%ad %ae %s'
2017-08-28 mradev Update multiview state on program executable change
Created with:
roll-dep skia/third_party/externals/angle2
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls
CQ_INCLUDE_TRYBOTS=skia.primary:Perf-Win10-MSVC-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-ANGLE,Perf-Win10-MSVC-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-ANGLE,Perf-Win10-MSVC-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-ANGLE,Perf-Win10-MSVC-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-ANGLE,Perf-Win10-MSVC-ShuttleC-GPU-GTX960-x86_64-Debug-ANGLE,Perf-Win10-MSVC-ZBOX-GPU-GTX1070-x86_64-Debug-ANGLE,Test-Win10-MSVC-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-ANGLE,Test-Win10-MSVC-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-ANGLE,Test-Win10-MSVC-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-ANGLE,Test-Win10-MSVC-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-ANGLE,Test-Win10-MSVC-ShuttleC-GPU-GTX960-x86_64-Debug-ANGLE,Test-Win10-MSVC-ZBOX-GPU-GTX1070-x86_64-Debug-ANGLE
TBR=djsollen@google.com
Change-Id: I37bd570ff222e8afc50fa6b537e5507459873210
Reviewed-on: https://skia-review.googlesource.com/41260
Commit-Queue: angle-deps-roller . <angle-deps-roller@chromium.org>
Reviewed-by: angle-deps-roller . <angle-deps-roller@chromium.org>
Shouldn't be anything tricky here.
Guarded by SK_JUMPER_LEGACY_X86_8BIT for (Win) layout tests.
Change-Id: I7580c7c18d1721f1301904c049ea2e59e9bda5d9
Reviewed-on: https://skia-review.googlesource.com/40692
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
So that callers could manage the thread pool themselves instead of
relying on SkThreadBMPDevice.
Bug: skia:
Change-Id: Idbeafc9ac5d111370fd1b74f6eab9ac8df179940
Reviewed-on: https://skia-review.googlesource.com/39760
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
Bug: skia:
Change-Id: I35bc08ad72fb94d8e47fe342d314c4496b954226
Reviewed-on: https://skia-review.googlesource.com/40881
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Chrome would like to perform cpu-side preprocessing for gpu draws in parallel.
They do not want to go through a picture (since they have their own display list format).
The general idea is that we add a new SkDeferredDisplayListRecorder class to
perform all of Ganesh's cpu-side preprocessing ahead of time and in parallel.
The SkDDLRecorder operates like SkPictureRecorder. The user can get an SkCanvas
from the SkDDLRecorder and feed it draw operations. Once finished, the user
calls 'detach' to get an SkDeferredDisplayList. All the work up to and
including the 'detach' call can be done in parallel and will not touch
the GPU. To actually get pixels the client must call SkSurface::draw(SkDDL)
on an SkSurface that is "compatible" with the surface characterization
initially given to the SkDDLMaker.
The surface characterization contains the minimum amount of information Ganesh needs
to know about the ultimate destination in order to perform its cpu-side work
(i.e., caps, width, height, config).
Change-Id: I75faa483ab5a6b779c8de56ea56b9d90b990f43a
Reviewed-on: https://skia-review.googlesource.com/30140
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bug: skia:
Change-Id: Icd905ea7e60a05bc3903eb85d111dcf73ce2c4dd
Reviewed-on: https://skia-review.googlesource.com/40690
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I0d4166a4e9ea894f479755f9f7137c5941cf8a22
Reviewed-on: https://skia-review.googlesource.com/41081
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Osman <brianosman@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>
This is portable back to older Android NDK APIs.
Seems to work fine.
Change-Id: I1f121f372d376909011ffd7063b73cbe50402a5f
Reviewed-on: https://skia-review.googlesource.com/40688
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I52659857174848696f360d64552a9690db24ed50
Reviewed-on: https://skia-review.googlesource.com/40883
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This adds a fallback backtracer for use on Android where <execinfo.h>
ins't present, instead using <unwind.h> to unwind and <dlfcn.h> to
lookup function names and addresses.
lockf() wasn't available until NDK API 24, so I've just no-op'd file
locking on older targets. I tried switching from lockf() to flock(),
but flock() didn't see to _do_ anything, neither on Android nor on my
Mac laptop. I think I should be able to use the lower-level fcntl()
APIs to restore file locking uniformly in a follow-up. The upshot is
until then, we'll have interlaced logs and stack traces on Android
devices unless you set ndk_api=24 in GN.
We need to add a couple build flags to make backtraces useful:
* -funwind-tables makes the call to _Unwind_Backtrace() actually
traverse the call stack. This is a small extra binary size cost.
* -rdynamic makes symbols linked into the main executable visible
to dladdr(). We do this on Linux already for the same reason.
Here's an example where I made aaxfermodes call SK_ABORT():
650 ok, 1 crashed
caught signal SIGABRT while running 'aaxfermodes'
0x76ed936288 [unknown]+308
0x76eec014e0 [unknown]+510811706592
0x76ed367b2c tgkill+8
0x76ed364f50 pthread_kill+68
0x76ed31ff5c raise+28
0x76ed318814 abort+56
0x76edebd070 sk_out_of_memory()+12
0x76ed99f664 AAXfermodesGM::draw_pass(SkCanvas*, AAXfermodesGM::DrawingPass)+96
0x76ed99f4e4 AAXfermodesGM::onDraw(SkCanvas*)+36
0x76ed9e8550 skiagm::GM::drawContent(SkCanvas*)+224
0x76ed9e82ac skiagm::GM::draw(SkCanvas*)+288
0x76ed93b10c GMStream::GMSrc::draw(SkCanvas*)+96
0x76ed937b08 SWDst::draw(Src*)+284
0x76ed936ca0 [unknown]+112
0x76ed939b4c ForkEngine::spawn(std::function<Status ()>)+88
0x76ed934d00 main+2200
0x76ed316598 __libc_init+92
0x76ed93434c [unknown]+510791992140
Change-Id: Ica4849d99a3b97f48d778f4c15a7fa36275b8133
Reviewed-on: https://skia-review.googlesource.com/40802
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Re-land of: https://skia-review.googlesource.com/36560
All information needed by the thread is captured by the prepare
callback object, the lambda captures a pointer to that, and does the
mask render. Once it's done, it signals the semaphore (also owned by the
callback). The callback defers the semaphore wait even longer (into the
ASAP upload), so the odds of waiting for the thread are REALLY low.
Also did a bunch of cleanup along the way, and put in some trace markers
so we can monitor how well this is working.
Traces of a GM that includes GPU and SW path rendering (path-reverse):
Original:
https://screenshot.googleplex.com/f5BG3901tQg.png
Threaded, with wait in the callback (notice pre flush callback blocking):
https://screenshot.googleplex.com/htOSZFE2s04.png
Current version, with wait deferred to ASAP upload function:
https://screenshot.googleplex.com/GHjD0U3C34q.png
Bug: skia:
Change-Id: Idb92f385590749f41328a9aec65b2a93f4775079
Reviewed-on: https://skia-review.googlesource.com/40775
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Speculative fix for a memory regression seen in Chromium. Chromium
previously used a WTF::Vector, which has a growth factor of 1.5, as does
SkTArray. Depending on the implementation of std::vector, this may slow
the allocation of memory.
Bug: 758946
Change-Id: I323390027467e32a6c66667c927fae0aba292446
Reviewed-on: https://skia-review.googlesource.com/40777
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
I'm not sure why I wrote this to use a Params struct originally, but we
should have plenty of registers in _8bit to pass everything directly and
avoid the stack. Even once we enable the 8-bit pipeline on 32-bit x86,
we'll have 4 general purpose registers and 4 vector registers to use,
precisely what we're using here.
Change-Id: I3e51ab73186edcdcb8bfaa6cc99d9516db7c032a
Reviewed-on: https://skia-review.googlesource.com/40771
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
